Project Glasswing: Mythos가 우리에게 보여준 것

2026-05-18

9분 읽기

지난 몇 달 동안, 저희는 자체 인프라에서 보안 중심 LLM 여러 종을 시험해 왔습니다. 이러한 LLM은 저희 시스템의 잠재적 취약점을 식별해 수정할 수 있도록 돕고, 동시에 최신 모델을 통해 공격자들이 무엇을 할 수 있게 될지도 보여줍니다.

이들 LLM 가운데 Anthropic의 Mythos Preview만큼 큰 주목을 받은 것은 없었습니다. 몇 주 전, 저희는 Project Glasswing의 일환으로 Mythos Preview를 사용해 보라는 초대를 받았습니다. 저희는 곧 이를 자체 저장소 50개 이상에 적용해 무엇을 찾아내는지, 그리고 어떻게 작동하는지 살펴보았습니다.

이 글에서는 저희가 관찰한 내용, 모델이 잘한 점과 그렇지 못한 점, 그리고 이를 대규모로 활용하기 위해 주변 아키텍처와 프로세스가 어떻게 바뀌어야 하는지를 공유합니다.

Mythos Preview로 달라진 점

Mythos Preview는 분명한 도약입니다. 다른 이야기에 들어가기 전에 이 점은 분명히 말할 가치가 있습니다. 저희는 이미 한동안 코드에 여러 모델을 적용해 왔지만, 이전의 범용 프런티어 모델로 가능했던 것에서 오늘날 Mythos Preview가 해내는 것으로의 도약은 단순한 정교화가 아닙니다.

이는 다른 종류의 작업을 수행하는 다른 종류의 도구이며, 그래서 이전 모델과 깔끔하게 일대일 비교를 하기는 어렵습니다. 따라서 Mythos Preview를 범용 프런티어 모델과 벤치마킹하려 하기보다, 실제로 무엇을 할 수 있는지, 그리고 저희가 Mythos Preview와 함께 작업하면서 특히 두드러지게 본 두 가지 기능을 설명하는 편이 더 유용합니다.

• 익스플로잇 체인 구성 - 실제 공격은 대개 하나의 버그만 사용하지 않습니다. 여러 작은 공격 프리미티브를 연결해 작동하는 익스플로잇을 만듭니다. 예를 들어 use-after-free 버그를 임의 읽기 및 쓰기 프리미티브로 전환하고, 제어 흐름을 탈취한 뒤, return-oriented programming (ROP) 체인을 사용해 시스템 전체를 완전히 장악할 수 있습니다. Mythos Preview는 이러한 프리미티브 여러 개를 받아 어떻게 결합해 작동하는 증명으로 만들 수 있는지 추론할 수 있습니다. 그 과정에서 보여주는 추론은 자동화된 스캐너의 출력이라기보다 숙련된 선임 연구자의 작업처럼 보입니다.

• 증명 생성 - 버그를 찾는 것과 그것이 익스플로잇 가능하다는 것을 증명하는 것은 별개의 일이며, Mythos Preview는 둘 다 할 수 있습니다. 의심되는 버그를 유발할 코드를 작성하고, 그 코드를 임시 환경에서 컴파일한 뒤 실행합니다. 프로그램이 모델이 예상한 대로 동작하면 그것이 증명입니다. 그렇지 않다면 모델은 실패 내용을 읽고, 가설을 조정한 뒤 다시 시도합니다. 이 반복은 발견한 버그만큼이나 중요합니다. 작동하는 증명 없이 의심되는 결함만 있는 상태는 추측에 불과하지만, Mythos Preview는 스스로 그 간극을 메웁니다.

위에서 설명한 일부는 Mythos Preview만의 완전히 고유한 특성은 아닙니다. 같은 하네스로 다른 프런티어 모델을 실행했을 때도, 상당수의 동일한 근본 버그를 찾아냈고, 어떤 경우에는 추론 측면에서도 예상보다 더 멀리 나아갔습니다. 하지만 부족했던 지점은 조각들을 하나로 꿰매는 단계였습니다. 모델은 흥미로운 버그를 식별하고 그것이 왜 중요한지 사려 깊게 설명한 뒤, 실제 체인은 완성하지 않은 채 멈추곤 했으며, 익스플로잇 가능성은 열린 질문으로 남았습니다. Mythos Preview로 달라진 점은 이제 모델이 이러한 낮은 심각도의 버그들(전통적으로는 백로그에 보이지 않게 쌓였을 버그들)을 하나의 더 심각한 익스플로잇으로 연결할 수 있게 되었다는 점입니다.

정당한 취약점 연구에서의 모델 거부

Anthropic이 Project Glasswing의 일환으로 제공한 Mythos Preview 모델에는 일반적으로 제공되는 모델(예: Opus 4.7 또는 GPT-5.5)에 있는 추가 안전장치가 없었습니다.

그럼에도 이 모델은 특정 요청에 대해 스스로 제동을 거는 경향을 보였습니다. 취약점 탐색에 유용했던 사이버 역량과 마찬가지로, 이 모델은 자체적으로 발생한 가드레일을 지니고 있어 때때로 정당한 보안 연구 요청도 거부하게 만듭니다. 그러나 저희가 확인한 바에 따르면 이러한 자생적 거부는 일관적이지 않았습니다. 아래 예시에서 보이듯, 같은 작업이라도 표현 방식이나 제시되는 맥락이 달라지면 완전히 다른 결과가 나올 수 있었습니다.

Mythos Preview가 작동하는 개념 증명 작성에 제동을 거는 예시

예를 들어, 모델은 처음에는 어떤 프로젝트에 대한 취약점 연구를 거부했지만, 프로젝트 환경에 무관한 변경이 가해진 뒤에는 동일한 코드에 대해 같은 연구를 수행하는 데 동의했습니다. 분석 대상 코드 자체에는 아무 변화도 없었습니다. 또 다른 사례에서는 모델이 한 코드베이스에서 여러 심각한 메모리 버그를 찾아 확인한 뒤, 이를 보여주는 익스플로잇 작성은 거부했습니다. 같은 요청도 다르게 표현하면 다른 답을 얻을 수 있었고, 모델의 확률적 특성 때문에 완전히 같은 요청조차 실행마다 다른 결과를 낼 수 있습니다. 의미적으로 동등한 작업이라도 언제, 어떻게 모델에 제시되느냐에 따라 정반대 결과가 나올 수 있습니다.

이 점이 중요한 이유는 모델의 자생적 거부/가드레일이 실제로 존재하더라도, 그것만으로 완전한 안전 경계를 형성할 만큼 일관적이지는 않기 때문입니다. 바로 그렇기 때문에, 앞으로 일반에 널리 제공될 수 있는 강력한 사이버 프런티어 모델은 Project Glasswing 같은 통제된 연구 맥락을 넘어 더 넓은 사용에 적합하도록, 이 기본 동작 위에 추가 안전장치를 반드시 포함해야 합니다.

신호 대 잡음 문제

보안 취약점을 분류하는 일에서 가장 어려운 부분 중 하나는 어떤 버그가 실제인지, 어떤 것이 익스플로잇 가능한지, 그리고 무엇을 지금 당장 고쳐야 하는지 판단하는 것입니다. 이는 AI 이전 시대에도 어려운 문제였습니다. AI 취약점 스캐너와 AI 생성 코드가 이 문제를 더욱 악화시켰고, Cloudflare에서는 이에 대응하기 위해 여러 단계의 후속 검증 절차를 구축했습니다.

잡음 비율은 두 가지 요소가 지배합니다.

• 프로그래밍 언어 - C와 C++는 메모리를 직접 제어할 수 있게 해주며, 그 결과 buffer overflow, out-of-bounds read 및 write 같은 버그 클래스가 생깁니다. 이런 버그는 Rust 같은 메모리 안전 언어에서는 컴파일 시점에 제거됩니다. 저희는 메모리 비안전 언어로 작성된 프로젝트에서 일관되게 더 많은 false positive를 보았습니다.

• 모델 편향 - 훌륭한 인간 연구자는 무엇을 찾았는지와 얼마나 확신하는지를 함께 말합니다. 모델은 그렇지 않습니다. 모델에게 버그를 찾으라고 하면, 코드에 실제 버그가 있든 없든 버그를 찾아냅니다. 결과에는 "possibly", "potentially", "could in theory" 같은 표현이 붙어 돌아오고, 이렇게 유보된 결과가 확실한 결과보다 압도적으로 많습니다. 탐색용 도구로서는 이해할 수 있는 편향입니다. 하지만 분류 대기열에서는 치명적입니다. 추측성 결과 하나하나를 기각하는 데 인간의 주의와 토큰이 소모되며, 이 비용은 수천 개의 결과에 걸쳐 누적됩니다.

Mythos Preview는 이 점에서 분명한 개선을 보여줍니다. 특히 프리미티브를 연결하는 능력, 즉 여러 취약점을 따로따로 보고하는 대신 작동하는 개념 증명으로 결합하는 능력이 그렇습니다. PoC와 함께 도착한 결과는 즉시 조치할 수 있는 결과이며, "이게 정말 실제인가?"를 확인하는 데 쓰는 시간을 크게 줄여줍니다.

저희 하네스는 더 많이 보고(그리고 덜 놓치기) 위해 의도적으로 과다 보고하도록 조정되어 있어, 그만큼 잡음도 많습니다. 하지만 분류 단계에서 보면 Mythos Preview의 출력은 눈에 띄게 더 품질이 높습니다. 유보적 결과가 더 적고, 재현 단계가 더 명확하며, 수정할지 기각할지 결정하는 데 드는 작업도 더 적습니다.

범용 코딩 에이전트를 저장소에 바로 투입해도 작동하지 않는 이유

작년에 AI 보조 취약점 연구를 처음 시작했을 때, 저희의 본능은 너무도 당연한 것이었습니다. 범용 코딩 에이전트를 임의의 저장소에 투입하고 취약점을 찾아내라고 하는 것이었습니다. 이 접근은 모델이 결과를 내놓는다는 의미에서는 작동합니다. 하지만 실제 코드베이스를 의미 있게 포괄하고 가치 있는 결과를 식별한다는 측면에서는 작동하지 않습니다. 여기에는 두 가지 주요 이유가 있습니다.

• 컨텍스트 - 코딩 에이전트는 하나의 집중된 작업 흐름, 즉 기능 개발, 버그 수정, 리팩터링 작성에 맞춰 조정되어 있습니다. 많은 소스 코드를 받아들이고, 한 번에 하나의 가설을 유지하며, 그것을 바탕으로 반복합니다. 이것은 본질적으로 좁고 병렬적인 취약점 연구에는 정확히 맞지 않는 형태입니다. 인간 연구자는 하나의 구체적인 대상을 골라 깊이 있게 조사합니다. 그 하나는 단일한 복잡한 기능일 수도 있고, 보안 경계를 넘는 전이일 수도 있으며, 또는 공격자 입력이 셸 명령으로 실행되는 command injection 같은 특정 취약점 클래스일 수도 있습니다. 그리고 그런 일을 다시, 다른 기능이나 보안 경계, 다른 취약점 클래스에 대해 코드베이스 전반에서 수천 번 반복합니다. 10만 줄짜리 저장소를 상대로 한 단일 에이전트 세션은(서브에이전트를 쓰더라도) 모델의 컨텍스트 윈도우가 차고 압축이 시작되기 전까지 표면의 0.1% 정도만 유의미하게 다룰 수 있을 뿐이며, 그 과정에서 중요했을 초기 발견이 버려질 수 있습니다.

• 처리량 - 단일 스트림 에이전트는 한 번에 하나의 일만 합니다. 그러나 실제 코드베이스에는 한 번에 여러 컴포넌트에 대해 여러 가설을 적용하고, 흥미로운 점이 발견되면 더 넓게 확장할 수 있는 능력이 필요합니다. 단일 에이전트를 더 강하게 밀어붙일 수는 있지만, 어느 시점이 되면 모델의 한계보다 상호작용 형태 자체의 한계에 부딪히게 됩니다. 모델을 코딩 에이전트 안에서 직접 사용하는 방식은 연구자가 이미 단서를 가지고 있고 두 번째 시선이 필요할 때 수동 조사에는 괜찮다는 것이 드러났습니다. 하지만 높은 커버리지를 달성하는 데는 잘못된 도구입니다. 이 점을 받아들인 뒤, 저희는 Mythos Preview에게 맞지 않는 일을 시키려는 시도를 멈추고, 대신 그것을 둘러싼 하네스를 구축하기 시작했습니다.

하네스가 실제로 해결하는 것

대규모로 작업을 운영하면서 네 가지 교훈이 나왔고, 각각은 전체 실행을 관리하는 하네스의 필요성을 가리켰습니다.

• 좁은 범위가 더 나은 결과를 만든다 - 모델에게 "이 저장소에서 취약점을 찾아라"라고 하면 이리저리 헤맵니다. 반면 "이 특정 함수에서 command injection을 찾아라. 그 위에 이런 신뢰 경계가 있고, 여기 아키텍처 문서가 있으며, 이 영역에 대한 이전 커버리지는 이렇다"라고 말하면, 실제 연구자가 하는 방식에 훨씬 더 가까운 일을 하게 됩니다.

• 적대적 검토가 잡음을 줄인다 - 초기 결과와 대기열 사이에 두 번째 에이전트를 추가하고, 여기에 다른 프롬프트와 다른 모델을 사용하며, 자체적으로 새 결과를 생성할 능력은 주지 않으면, 첫 번째 에이전트가 자기 작업만 점검할 때 놓칠 많은 잡음을 걸러낼 수 있습니다. 하나의 에이전트에게 조심하라고 말하는 것보다, 두 에이전트를 의도적으로 불일치 상태에 두는 편이 훨씬 더 효과적이라는 사실이 드러났습니다.

• 체인을 여러 에이전트에 나누면 추론이 더 좋아진다 - "이 코드에 버그가 있는가?"와 "공격자가 실제로 시스템 외부에서 이 버그에 도달할 수 있는가?"는 서로 다른 질문입니다. 이를 따로 물으면 각 질문의 범위가 결합된 질문보다 더 좁기 때문에, 모델은 각각을 더 잘 수행합니다.

• 병렬의 좁은 작업이 하나의 철저한 에이전트보다 낫다 - 하나의 에이전트에게 철저함을 요구하는 것보다, 많은 에이전트가 좁게 범위를 정한 질문을 병렬로 수행하고 나중에 결과를 중복 제거하는 편이 커버리지를 더 높입니다.

이 관찰들은 모두 모델 행동에 관한 것이며, 이를 종합하면 더 이상 채팅 인터페이스라고 부를 수 없는 무언가를 설명하게 됩니다. 최종 결과를 달성하도록 돕는 하네스입니다. 하네스 구축의 첫 단계는 단순하며, 모델에게 도움을 요청할 수 있습니다. 저희도 그렇게 했습니다. Mythos Preview를 사용해 저희의 기존 하네스를 기반으로 확장하고, 맞춤화하고, 그 강점에 맞게 개선했습니다. 실제 하네스가 어떤 모습인지에 대한 예시는 아래에 설명합니다.

저희의 취약점 발견 하네스

다음은 저희 취약점 발견 하네스의 단계별 모습입니다. 이 하네스는 런타임, 에지 데이터 경로, 프로토콜 스택, 제어 평면, 그리고 저희가 의존하는 오픈소스 프로젝트 전반의 실제 코드 스캔에 사용되었습니다.

단계수행 내용중요한 이유 **

Recon**에이전트 하나가 저장소를 상위부터 하위까지 읽고, 각 서브시스템을 담당하는 서브에이전트로 확장한 뒤, 빌드 명령, 신뢰 경계, 진입점, 가능성 높은 공격 표면을 포함하는 아키텍처 문서를 생성합니다. 또한 다음 단계용 초기 작업 대기열도 생성합니다.모든 다운스트림 에이전트에 공유 컨텍스트를 제공합니다. 헤매는 문제를 줄여줍니다. **

Hunt**각 작업은 하나의 공격 클래스와 범위 힌트의 조합입니다. Hunters(실제로 버그를 찾는 에이전트)는 동시에 실행되며, 보통 약 50개가 한 번에 돌아가고, 각각은 소수의 탐색 서브에이전트로 다시 확장됩니다. 각 hunter는 작업별 임시 디렉터리에서 개념 증명 코드를 컴파일하고 실행하는 도구에 접근할 수 있습니다.대부분의 작업이 이 단계에서 이루어집니다. 하나의 철저한 에이전트가 아니라, 많은 좁은 작업이 병렬로 수행됩니다. **

Validate**독립적인 에이전트가 코드를 다시 읽고 원래 결과를 반박하려 시도합니다. 이 에이전트는 다른 프롬프트를 사용하며, 스스로 새로운 결과를 내보낼 수는 없습니다.hunter가 자기 작업을 검토할 때는 걸러내지 못할 의미 있는 비율의 잡음을 잡아냅니다. **

Gapfill**hunters는 건드렸지만 충분히 다루지 못한 영역에 표시를 남깁니다. 그 영역은 다시 대기열에 들어가 또 한 번의 패스를 거칩니다.모델이 이미 성공 경험이 있는 공격 클래스 쪽으로 쏠리는 경향을 상쇄합니다. **

Dedupe**같은 근본 원인을 공유하는 결과는 하나의 레코드로 통합됩니다.변형 분석은 기능이지, 중복으로 대기열을 부풀리는 수단이 아닙니다. **

Trace**공유 라이브러리에서 확인된 각 결과에 대해 tracer 에이전트가 확장되며(소비자 저장소마다 한 인스턴스), 저장소 간 심볼 인덱스를 사용해 공격자 제어 입력이 실제로 시스템 외부에서 그 버그에 도달하는지 판단합니다."결함이 있다"를 "도달 가능한 취약점이 있다"로 바꿉니다. 가장 중요한 단계가 바로 이 단계입니다. **

Feedback**도달 가능한 추적은 버그가 실제로 노출되는 소비자 저장소에서 새로운 hunt 작업이 됩니다.루프를 닫습니다. 파이프라인은 실행될수록 더 좋아집니다. **

Report**에이전트가 미리 정의된 스키마에 맞춘 구조화된 보고서를 작성하고, 그 스키마에 대한 검증 오류가 있으면 스스로 수정한 뒤, ingest API에 보고서를 제출합니다.출력은 자유 형식 산문이 아니라 질의 가능한 데이터입니다.

이것이 보안 팀에 의미하는 바

다른 보안 리더들이 Mythos Preview에 대해 가장 크게 반응한 부분은 속도였습니다. 더 빨리 스캔하고, 더 빨리 패치하고, 대응 주기를 압축하는 것입니다. 저희가 대화한 팀들 가운데 하나 이상은 이제 CVE 공개부터 프로덕션 패치까지 두 시간 SLA를 기준으로 운영하고 있습니다. 이런 본능은 이해할 수 있습니다. 공격자 타임라인이 짧아지면 방어자 타임라인도 짧아져야 하기 때문입니다. 하지만 더 빠른 것만으로는 충분하지 않을 것이며, 많은 팀이 머지않아 그 사실을 힘들게 배우는 데 많은 시간과 노력, 비용을 쓰게 될 것이라고 저희는 생각합니다.

더 빨리 패치하는 것은 패치를 만들어내는 파이프라인의 형태 자체를 바꾸지 않습니다. 회귀 테스트에 하루가 걸린다면, 이를 건너뛰지 않고는 두 시간 SLA에 도달할 수 없습니다. 그런데 회귀 테스트를 건너뛰며 배포하는 버그는 대개 원래 패치하려던 버그보다 더 나쁩니다. 저희도 모델에게 자체적으로 패치를 쓰게 해보고, 원래 버그는 고치면서 조용히 코드가 의존하던 다른 것을 망가뜨리는 사례 몇 건이 실제로 나가는 것을 보며 비슷한 교훈을 얻었습니다.

더 어려운 질문은 취약점을 둘러싼 아키텍처가 어떤 모습이어야 하느냐입니다. 원칙은 버그가 존재하더라도 공격자가 이를 악용하기 더 어렵게 만들어, 취약점이 공개되는 시점과 패치되는 시점 사이의 간격이 덜 중요해지게 하는 것입니다. 이는 애플리케이션 앞단에 위치해 버그에 도달하는 것을 막는 방어를 의미합니다. 또한 코드의 한 부분의 결함이 공격자에게 다른 부분으로의 접근을 주지 못하도록 애플리케이션을 설계하는 것을 의미합니다. 그리고 개별 팀의 배포를 기다리는 대신, 코드가 실행되는 모든 위치에 동시에 수정 사항을 배포할 수 있어야 함을 의미합니다.

저희는 또한 이 주제가 양면성을 가진다는 점을 인식하고 있습니다. 저희가 자체 코드에서 버그를 찾는 데 도움을 준 바로 그 역량이, 잘못된 손에 들어가면 인터넷의 모든 애플리케이션에 대한 공격 측을 가속할 수 있습니다. Cloudflare는 수백만 개의 애플리케이션 앞단에 서 있으며, 위에서 설명한 아키텍처 원칙은 바로 저희 제품이 고객을 대신해 적용하도록 설계된 원칙들입니다. 이것이 고객에게 무엇을 의미하는지에 대해서는 앞으로 몇 주 안에 더 공유하겠습니다.

귀사의 팀도 비슷한 작업을 하고 있고 의견을 비교해 보고 싶다면, security-ai-research@cloudflare.com으로 연락해 주세요.

Mythos Preview를 활용한 저희 연구는 저희 자체 코드만을 대상으로 한 통제된 환경에서 수행되었으며, 이 작업을 통해 드러난 모든 취약점은 Cloudflare의 공식 취약점 관리 프로세스에 따라 조치가 필요한 경우 분류, 검증, 수정되었습니다.

이 작업은 팀의 공동 노력으로 이루어졌습니다. 이 블로그 글의 배경이 된 연구, 엔지니어링, 분석에 기여한 Albert Pedersen, Craig Strubhart, Dan Jones, Irtefa Fairuz, Martin Schwarzl, Rohit Chenna Reddy에게 감사드립니다.

SecurityAIAgentsThreat IntelligenceLLMRisk ManagementThreat OperationsAutomationEngineering