Glasswing 프로젝트: 저희가 Mythos를 통해 관찰한 내용

지난 몇 달 동안 저희는 보안 중심의 LLM들을 저희 인프라에서 테스트해 왔습니다. 이들 LLM은 자사 시스템에서 잠재적인 취약점을 식별하는 데 도움을 주어 이를 해결할 수 있게 하고, 최신 모델을 통해 공격자가 무엇을 할 수 있는지도 보여줍니다.

이들 LLM 중 Anthropic의 Mythos Preview만큼 많은 주목을 받은 대형 언어 모델은 없습니다. 몇 주 전, 저희는 Glasswing 프로젝트의 일환으로 Mythos Preview를 사용해달라는 초대를 받았습니다. 저희는 곧바로 50여 개의 자체 리포지토리에 이 모델을 적용하여 어떤 데이터를 찾아내는지, 그리고 어떻게 작동하는지 확인해 보았습니다.

이 게시물에서는 저희가 관찰한 내용, 이 모델이 잘한 점과 잘하지 못한 점, 그리고 이 모델을 대규모로 사용할 수 있도록 주변의 아키텍처와 과정이 어떻게 변화해야 하는지를 공유합니다.

‘Mythos Preview’는 진정한 진전을 이룬 모델이며, 다른 이야기를 하기 전에 이 점을 분명히 밝혀둘 필요가 있습니다. 저희는 한동안 저희 코드에 모델을 적용해 왔는데, 기존의 범용 프런티어 모델로 가능했던 수준에서 오늘날 Mythos Preview가 보여주는 성과로의 도약은 단순히 이전 기술을 개선한 차원을 넘어선 것입니다.

이 모델은 다른 종류의 작업을 수행하는 다른 종류의 도구이므로 이전 모델과 직접 비교하는 것은 어렵습니다. 따라서 Mythos Preview를 범용 프런티어 모델과 비교하려고 하기보다는 이 모델이 실제로 무엇을 수행할 수 있는지 설명하는 것이 더 유용하며, Mythos Preview로 작업해본 결과 다음과 같은 두 가지의 특징이 두드러졌습니다.

• 익스플로잇 체인 구성 - 실제 공격에서는 하나의 버그만을 사용하지 않습니다. 여러 개의 작은 공격 기본 요소를 결합하여 작동 가능한 익스플로잇으로 만듭니다. 예를 들어, 공격에서는 use-after-free 버그를 임의의 읽기 및 쓰기 기본 요소로 변환하고, 제어 흐름을 탈취한 후, 반환 지향 프로그래밍(ROP) 체인을 사용하여 시스템을 완전히 제어할 수 있습니다. Mythos Preview는 이러한 기본 요소 몇 가지를 조합하여 이를 실제 증명으로 결합하는 방법을 추론할 수 있습니다. 그 과정에서 나타나는 추론은 자동 스캐너의 출력물이라기보다 선임 연구원의 작업처럼 보입니다.

• 증명 생성 - 버그를 찾는 것과 그 버그가 익스플로잇 가능한지 증명하는 것은 다른 문제이며, Mythos Preview는 두 가지를 모두 수행할 수 있습니다. Mythos Preview는 의심되는 버그를 유발할 코드를 작성하고, 그 코드를 임시 환경에서 컴파일하고 실행합니다. 그 프로그램이 모델이 예상한 대로 작동하면, 그것이 증명입니다. 예상한 대로 작동하지 않은 경우, 모델은 실패를 파악하고 가설을 조정한 후 다시 시도합니다. 루프는 모델이 발견한 버그만큼 중요합니다. 왜냐하면 작동하는 증명이 없는 채로 의심되는 결함은 추측에 불과하며, Mythos Preview는 이 격차를 스스로 해소하기 때문입니다.

위에서 설명한 내용 중 일부는 Mythos Preview에만 고유한 것은 아닙니다. 저희는 다른 프런티어 모델들을 동일한 하네스를 통해 실행하면서 상당수의 동일한 근본적인 버그를 발견했으며, 그 버그는 경우에 따라서는 추론 측면에서도 저희 예상보다 더 나아갔습니다. 그 버그가 부족했던 부분은 조각들을 하나로 연결하는 지점에서였습니다. 모델은 흥미로운 버그를 식별하고, 그 버그가 중요한 이유를 신중하게 설명한 뒤에 멈춥니다. 이렇게 하면 실제 체인은 미완성으로 남고, 익스플로잇 가능성에 대한 질문이 남게 됩니다. Mythos Preview에서 변경된 사항은 이제 모델이(기존에는 백로그에 숨겨져 있던) 심각도가 낮은 버그들을 연결하여 더 심각한 단일 익스플로잇으로 만들 수 있다는 점입니다. 

Anthropic에서 제공한 Mythos Preview 모델은 Glasswing 프로젝트의 일환으로, 일반적으로 사용 가능한 모델(Opus 4.7 또는 GPT-5.5)에서 사용할 수 있는 추가 안전장치가 없었습니다.

그럼에도 불구하고, 이 모델은 특정 요청에 대해 자연스럽게 거부 반응을 보입니다. 취약점 탐색을 유용하게 만들어준 사이버 기능과 마찬가지로, 이 모델에는 때때로 정당한 보안 연구 요청에 대해 거부 반응을 보이게 만드는 자체적인 안전장치가 존재합니다. 하지만 저희가 발견한 바와 같이, 이러한 자연스러운 거부 반응은 일관되지 않습니다. 동일한 작업이라도 다르게 표현되거나 다른 맥락에서 제공될 경우, 아래 예시에서 볼 수 있듯이 전혀 다른 결과가 나올 수 있습니다.

^{Mythos Preview에서 작동하는 개념 증명을 구축하는 것을 거부하는 예} 

예를 들어, 이 모델은 처음에는 프로젝트에 대한 취약성 연구를 거부한 후, 프로젝트 환경과 무관한 변화가 있자 동일한 코드에 대해 연구를 수행하기로 동의했습니다. 분석 중인 코드에는 변화가 없었습니다. 또 하나의 사례에서는, 이 모델이 코드베이스에서 여러 심각한 메모리 버그를 찾아내어 확인한 후, 시연용 익스플로잇 작성을 거부했습니다. 동일한 요청도 다르게 표현하면 다른 답을 받을 수 있으며, 모델의 확률적 특성 때문에 동일한 요청도 실행할 때마다 결과가 다르게 나타날 수 있습니다. 의미적으로 동등한 작업이라도 모델에 어떻게 그리고 언제 제시되는지에 따라 반대되는 결과를 초래할 수 있습니다.

이 점이 중요한 이유는, 모델의 내재적 거부 메커니즘이나 안전 장치가 실제로 존재하기는 하지만, 그것들만으로는 완벽한 안전 경계를 형성하기에는 일관성이 부족하기 때문입니다. 바로 그런 이유로, 미래에 일반적으로 제공되는 모든 유능한 사이버 프런티어 모델에는 Glasswing 프로젝트와 같은 통제된 연구 환경 밖에서도 적절하게 사용될 수 있도록 이 기본 동작 외에 추가적인 안전장치가 포함되어야 합니다.

보안 취약점을 분류하는 가장 어려운 부분 중 하나는 어떤 버그가 실제이고, 어떤 버그가 익스플로잇 가능하며, 어떤 버그를 지금 바로 수정해야 하는지를 결정하는 것입니다. 이것은 AI 이전 세계에서도 어려운 문제였습니다. AI 취약점 스캐너 및 AI로 생성된 코드 때문에 그 문제가 악화되었으며, Cloudflare에서는 이를 해결하기 위해 여러 사후 검증 단계를 구축했습니다.

다음과 같은 두 가지 요인에 따라 노이즈 비율이 결정됩니다.

• 프로그래밍 언어 - C와 C++는 직접적인 메모리 제어를 제공하여 버그 클래스(버퍼 오버플로, 경계를 벗어난 읽기 및 쓰기)가 발생될 수 있지만, Rust와 같은 메모리 안전 언어는 컴파일 시 이를 제거합니다. 저희는 메모리 비안전 언어로 작성된 프로젝트에서 긍정 오류가 일관되게 더 많이 발생하는 것을 관찰했습니다.

• 모델 편향 - 우수한 인간 연구자는 발견한 내용과 그에 대한 확신 정도를 알려줍니다. 모델은 그렇지 않습니다. 모델에게 버그를 찾으라고 하면 코드에 버그가 있든 없든 찾을 것입니다. 조사 결과는 '아마도', '잠재적으로', '이론상으로는 가능할 수도 있음' 등의 유보된 표현으로 제시되는 경우가 많으며, 이러한 유보된 표현이 확실한 결과보다 훨씬 많습니다. 탐색 도구라면 그런 편향은 합리적일 수 있습니다. 하지만 추측성 발견 하나하나를 기각하는 데 사람의 관심과 토큰이 소모되고, 그 비용이 수천 건의 발견에 걸쳐 누적되는 분류 대기열에서는 그런 편향은 치명적입니다.

Mythos Preview는 특히 여러 취약점을 개별적으로 보고하는 대신 작동 가능한 개념 증명을 위해 조합하여 기본 요소를 연속적으로 활용할 수 있는 능력에서 명백이 개선되었음을 보여줍니다. PoC를 통해 도출된 결과는 바로 실행에 옮길 수 있는 것이며, “이게 정말 사실일까?”라고 의심하는 데 시간을 낭비할 필요가 훨씬 줄어든다는 것을 의미합니다.

저희의 하네스는 의도적으로 과잉 보고하도록 조정되어 있어서 저희가 더 많은 것을 보고 놓치는 것이 적지만, 그와 동시에 더 많은 노이즈가 수반됩니다. 그러나 분류 시점에서 Mythos Preview의 결과물은 눈에 띄게 높은 품질을 보입니다. 유보된 발견이 줄어들고, 재현 단계가 명확하며, 수정 또는 기각 결정을 내리기 위한 작업이 적습니다.

작년에 AI 기반 취약점 연구를 처음 시작했을 때, 저희의 본능은 너무나 당연히도 일반적인 코딩 에이전트를 임의의 리포지토리에 연결하고 취약점을 발견하도록 요청하는 것이었습니다. 이 접근 방식은 모델이 분석 결과를 산출한다는 점에서는 효과가 있지만, 실제 코드베이스를 제대로 다루거나 가치 있는 분석 결과를 도출하는 데는 한계가 있습니다. 그 이유는 크게 두 가지로 볼 수 있습니다.

• 컨텍스트 - 코딩 에이전트는 하나의 집중된 작업 스트림, 즉 기능 구축, 버그 수정, 리팩토링 작성에 최적화되어 있습니다. 코딩 에이전트는 많은 소스 코드를 수집하고, 한 번에 하나의 가설을 세우며, 그 가설에 대해 반복합니다. 그것은 본질적으로 범위가 좁고 병행식으로 진행되는 취약점 연구에는 전혀 맞지 않는 방식입니다. 인간 연구자는 조사할 특정한 한 가지를 선택해서 철저히 조사합니다. 그 한 가지는 복잡한 기능 하나일 수도 있고, 보안 경계를 넘는 전환일 수도 있으며, 명령 주입과 같은 특정 취약성 클래스로, 공격자의 입력이 셸 명령어로 실행되는 경우를 말할 수 있습니다. 그런 다음 코드베이스 전반에서 수천 번에 걸쳐 다른 기능이나 보안 경계나 취약점 유형에 대해서도 같은 작업을 반복합니다. 10만 줄짜리 리포지토리에 대해 단일 에이전트 세션(하위 에이전트를 사용하더라도)을 수행하면 모델의 컨텍스트 창이 가득 차고 압축이 시작되기 전에 표면의 0.1% 정도만 유용하게 처리될 수 있으며, 이로 인해 중요했을 초기 결과를 버리게 될 수도 있습니다.

• 처리량 - 단일 스트림 에이전트는 한 번에 한 가지 작업만 수행하지만, 실제 코드베이스는 여러 구성 요소에 대한 많은 가설을 동시에 필요로 하며, 흥미로운 것이 나타날 때 더 확장할 수 있는 능력이 필요합니다. 단일 에이전트를 더 열심히 작동하게 할 수 있지만, 어느 시점에서는 모델에 의해 제한되는 것이 아니라 상호작용의 형태 자체에 의해 제한되기 시작합니다. 모델을 직접 코딩 에이전트에 사용하는 것은 이미 단서를 가진 연구자가 추가 검토를 하고 싶을 경우의 수동 조사에 적합합니다. 그러나, 높은 커버리지를 달성하기 위한 도구로는 적합하지 않습니다. 그 점을 받아들인 후, 저희는 Mythos Preview가 잘못된 역할을 하도록 만들려는 노력을 멈추고 대신 Mythos Preview를 중심으로 하는 기반을 구축하기 시작했습니다.

이 작업을 대규모로 진행하면서 얻은 네 가지 교훈이 있었는데, 각 교훈은 전체적인 실행을 관리할 수 있는 체계가 필요함을 시사했습니다.

• 범위를 좁히면 더 나은 결과가 나옴 - 모델에게 "이 리포지토리에서 취약점을 찾아라"라고 하면 엉뚱한 결과가 나올 수 있습니다. "이 특정 함수에서 명령 주입 취약점을 찾고, 그 위에 있는 신뢰 경계를 확인하고, 여기 아키텍처 문서와 이 영역에 대한 이전 연구 결과를 보여줘"라고 알려주면 연구자가 실제로 하는 작업에 훨씬 더 가깝게 작동하게 됩니다.

• 적대적 검토는 노이즈를 줄임 - 초기 결과와 대기열 사이에 두 번째 에이전트를 추가하면(이 에이전트는 다른 프롬프트, 다른 모델을 사용하며 자체 결과를 생성할 수 없음) 첫 번째 에이전트가 자체 작업만 확인했을 때 놓칠 수 있는 많은 노이즈를 잡아낼 수 있습니다. 두 에이전트를 의도적으로 반대되는 입장에 놓는 것이 단순히 한 에이전트에게 조심하라고 하는 것보다 훨씬 더 효과적이라는 것이 드러났습니다.

• 에이전트 간에 체인을 분할하면 더 나은 추론이 가능함 - "이 코드에 버그가 있는가?"와 "공격자가 시스템 외부에서 실제로 이 버그에 접근할 수 있는가?"는 서로 다른 질문이며, 각각의 질문이 결합된 질문보다 더 구체적이기 때문에 모델은 각각의 질문에 대해 더 나은 성능을 보입니다.

• 병렬식인 좁은 범위의 작업들이 하나의 포괄적인 에이전트보다 나음 - 하나의 에이전트에게 모든 질문에 대한 답변을 요구하는 것보다, 여러 에이전트가 범위가 좁은 질문에 대해 협력하고 나중에 결과를 중복 제거하는 방식을 사용하면 정확도가 높아집니다.

이들 관찰 각각은 모델의 동작에 관한 것이며, 그 관찰을 종합하면 더 이상 채팅 인터페이스가 아닌 무언가가 설명됩니다. 최종 결과를 달성하는 데 도움이 되는 것은 하네스입니다. 하네스를 제작하는 첫 단계는 간단합니다. 모델에게 도움을 요청할 수 있는데, 저희도 그렇게 했습니다. 저희는 Mythos Preview를 사용하여 기존의 하네스를 발전시키고 조정하여 그 강점에 맞게 개선했습니다. 하네스가 실제로 어떻게 보이는지에 대한 예는 아래에 설명되어 있습니다.

취약점 탐지 하네스의 단계별 구성은 다음과 같습니다. 이 하네스는 런타임 환경, 엣지 데이터 경로, 프로토콜 스택, 제어판, 저희가 의존하는 오픈 소스 프로젝트 전반에 걸쳐 실제 코드를 스캔하는 데 사용되었습니다.

단계	하는 일	이것이 중요한 이유
조사	에이전트는 리포지토리를 상단부터 하단으로 읽어 내려가며, 각 하위 시스템을 담당하는 하위 에이전트에게 작업을 분배하고, 빌드 명령어, 신뢰 경계, 진입점, 예상되는 공격면을 포함하는 아키텍처 문서를 생성합니다. 에이전트는 또한 다음 단계의 작업 대기열을 생성합니다.	모든 하위 에이전트에게 공유된 컨텍스트를 제공합니다. 방황 문제를 줄입니다.
헌팅	각 작업은 범위 힌트와 함께 하나의 공격 클래스로 구성됩니다. 헌터(실제로 버그를 찾아내는 에이전트)가 동시에 실행되며, 보통 한 번에 약 50개가 가동되는데, 각 헌터는 소수의 탐색 하위 에이전트로 분산됩니다. 각 헌터는 작업별 임시 디렉토리에서 개념 증명 코드를 컴파일하고 실행할 수 있는 도구에 액세스할 수 있습니다.	여기에서 대부분의 작업이 이루어집니다. 하나의 방대한 에이전트가 아닌 여러 개의 작은 작업이 병렬로 처리됩니다.
검증	독립적인 에이전트가 코드를 다시 읽고 원래의 결과를 반박하려고 시도합니다. 이는 다른 프롬프트를 사용하며 자체적으로 새로운 결과를 도출할 수 없습니다.	헌터가 자체 작업을 검토할 때 잡지 못할 노이즈를 의미 있는 비율로 잡아냅니다.
갭필	헌터는 자신이 건드렸지만 완전히 샅샅이 뒤지지 않은 지역에 표시를 합니다. 해당 지역은 다시 탐색 대기열에 추가됩니다.	이는 모델이 이미 성공을 거둔 공격 클래스 쪽으로 편향되는 경향을 방지합니다.
중복 제거	동일한 근본 원인을 공유하는 발견 사항은 하나의 기록으로 통합됩니다.	변이 분석은 기능이지, 중복 항목으로 대기열을 부풀리는 방법이 아닙니다.
추적	공유 라이브러리에서 확인된 각 발견 사항에 대해 추적 에이전트는 (소비자 리포지토리당 하나의 인스턴스로) 분산되어 리포지토리 간 심볼 인덱스를 사용하고 공격자가 제어하는 입력이 시스템 외부에서 실제로 버그에 도달하는지 여부를 판단합니다.	'결함이 있음'을 '접근 가능한 취약점이 있음'으로 변경합니다. 이것이 가장 중요한 단계입니다.
피드백	접근 가능한 추적은 실제로 버그가 드러나는 소비자 리포지토리에서 새로운 헌팅 작업이 됩니다.	루프를 닫습니다. 파이프라인은 실행될수록 개선됩니다.
보고	에이전트는 사전 정의된 스키마에 따라 구조화된 보고서를 작성하고, 해당 스키마에 대한 검증 오류를 수정한 후, 보고서를 수집 API에 제출합니다.	출력은 자유형 산문이 아니라 쿼리가 가능한 데이터입니다.

다른 보안 리더들로부터 Mythos Preview에 대한 가장 큰 반응은 속도에 관한 것이었습니다. 더 빠르게 스캔하고, 더 빨리 패치하며, 대응 주기를 압축한다는 것입니다. 저희가 대화한 여러 팀 중 하나 이상이 이제 CVE 릴리스부터 프로덕션 패치까지 2시간 SLA에 따라 운영하고 있습니다. 그러한 본능은 이해할 만합니다. 공격자의 시간대가 짧아지면, 방어자의 시간대도 그에 맞춰 짧아져야 하기 때문입니다. 더 빠르다는 것만으로는 충분하지 않으며, 많은 팀에서 이를 많은 시간과 노력, 비용을 들여가며 이를 어려운 방식으로 배우게 될 것입니다.

패치 속도를 높인다고 해서 패치를 생성하는 파이프라인의 형태가 바뀌지는 않습니다. 회귀 테스트에 하루가 걸린다면, 회귀 테스트를 건너뛰지 않고는 2시간 SLA를 달성할 수 없으며, 회귀 테스트를 건너뛰고 배포하는 버그는 원래 패치하려던 버그보다 더 심각한 경우가 많습니다. 저희는 모델이 자체적으로 패치를 작성하도록 시도했을 때 이와 비슷한 상황을 경험했습니다. 몇몇 패치가 원래 버그를 수정하는 동시에 코드가 의존하는 다른 부분을 조용히 망가뜨리는 것을 목격했기 때문입니다.

더 어려운 문제는 해당 취약점을 둘러싼 아키텍처가 어떤 모습이어야 하는가 하는 점입니다. 핵심 원칙은 버그가 존재하더라도 공격자가 악용하기 어렵게 만들어 취약점이 공개된 시점과 패치된 시점 사이의 시간적 간격이 덜 중요해지도록 하는 것입니다. 이는 애플리케이션 앞에서 버그가 도달하지 못하도록 차단하는 방어 수단을 의미합니다. 이는 코드의 한 부분에서 결함이 발생해도 공격자가 다른 부분에 접근할 수 없도록 애플리케이션을 설계하는 것을 의미합니다. 이는 코드가 실행되고 있는 모든 장소에 동일한 순간에 수정을 배포할 수 있음을 의미하며, 각 팀에서 개별적으로 배포하기를 기다리지 않아도 됩니다. 

저희는 이 주제가 양날의 검과 같음을 인지하고 있습니다. 저희가 자체 코드의 버그를 찾는 데 도움이 되었던 바로 그 기능이 악의적인 사람의 손에 들어가면 인터넷상의 모든 애플리케이션에 대한 공격을 가속화할 것입니다. Cloudflare는 수백만 개의 애플리케이션 앞에 자리 잡고 있으며, 위에서 설명한 아키텍처 원칙은 고객을 위해 당사 제품이 적용하도록 설계된 바로 그 원칙입니다. 앞으로 몇 주 동안 고객에게 그것이 의미하는 바에 대해 더 공유할 것입니다.

귀사 팀에서 유사한 작업을 수행 중이며 의견을 나누고 싶다면 [email protected]으로 연락 주세요.

Mythos Preview와 함께한 당사의 연구는 당사의 코드에 대해 통제된 환경에서 수행되었습니다. 이 작업을 통해 드러난 모든 취약점은 Cloudflare의 정식 취약점 관리 프로세스에 따라 분류되고, 검증되었으며, 필요한 부분은 수정되었습니다.

이 작업은 팀 단위의 노력이었습니다. 이 블로그 게시물의 연구, 엔지니어링, 분석에 기여해주신 Albert Pedersen, Craig Strubhart, Dan Jones, Irtefa Fairuz, Martin Schwarzl, Rohit Chenna Reddy께 감사를 표합니다.