Project Glasswing: Mythos가 보여준 것

• Mythos Preview는 Cloudflare의 50개 이상 저장소에서 개별 버그 탐지를 넘어 여러 원시 요소를 엮어 익스플로잇 체인을 구성함
• 의심 버그 탐지에 그치지 않고 트리거 코드 작성, 임시 컴파일·실행, 실패 후 가설 수정까지 반복해 동작 증명을 만들어냄
• 정당한 취약점 연구에서도 자발적 거부가 나타났지만, 문맥과 표현에 따라 달라져 안전 경계로 쓰기엔 일관성이 부족했음
• 범용 코딩 에이전트는 큰 저장소 커버리지와 병렬 탐색에 한계가 있어, Cloudflare는 좁은 작업을 병렬 실행하는 하네스를 구축함
• 보안 팀에는 더 빠른 스캔과 패치만으로 부족하며, 버그가 있어도 악용·도달이 어렵게 만드는 아키텍처가 중요해짐

Mythos Preview가 바꾼 취약점 연구 방식

• Cloudflare는 최근 몇 달 동안 자체 인프라에서 보안 중심 LLM을 테스트했고, Anthropic의 Mythos Preview를 Project Glasswing의 일부로 받아 50개 이상의 자체 저장소에 적용함
• Mythos Preview는 기존 범용 프런티어 모델의 단순 개선판이라기보다, 취약점 연구의 다른 단계를 수행하는 새 도구에 가까웠음
• 핵심 변화는 개별 버그를 나열하는 데서 끝나지 않고 여러 공격 원시 요소를 결합해 익스플로잇 체인을 구성한다는 데 있음
  • 실제 공격은 하나의 버그만 쓰기보다 use-after-free를 임의 읽기·쓰기 원시 요소로 바꾸고, 제어 흐름을 탈취하고, ROP 체인으로 시스템 제어를 얻는 식으로 이어짐
  • Mythos Preview는 이런 원시 요소들을 조합해 동작하는 증명으로 연결했으며, 자동 스캐너보다 숙련 연구자의 작업에 가까운 추론을 수행함
• 또 다른 변화는 의심되는 버그를 찾은 뒤 동작 증명까지 직접 만드는 능력임
  • 트리거 코드를 작성하고, 임시 환경에서 컴파일한 뒤 실행함
  • 예상대로 동작하면 증명이 되고, 실패하면 실패 내용을 읽고 가설을 조정한 뒤 다시 시도함
  • 작동하는 증명이 없는 결함은 추측에 머물지만, Mythos Preview는 이 간극을 스스로 줄였음
• 같은 하네스에서 다른 프런티어 모델들도 일부 기반 버그를 찾았고 예상보다 멀리 추론한 경우가 있었지만, 여러 조각을 실제 체인으로 완성하는 단계에서 차이가 났음
• Mythos Preview는 전통적으로 백로그에 낮은 심각도로 남았을 버그들을 하나의 더 심각한 익스플로잇으로 연결할 수 있었음

정당한 취약점 연구에서도 발생한 모델 거부

• Project Glasswing에 제공된 Mythos Preview에는 Opus 4.7이나 GPT-5.5 같은 일반 제공 모델의 추가 안전장치가 포함되지 않았음
• 그럼에도 모델은 특정 요청에 자발적으로 반발했고, 취약점 탐지에 유용했던 사이버 능력과 함께 발현적 가드레일도 드러남
• 자발적 거부는 일관적이지 않았음
  • 같은 작업도 표현 방식이나 문맥이 달라지면 완전히 다른 결과가 나올 수 있었음
  • 한 프로젝트에 대한 취약점 연구를 처음에는 거부했다가, 프로젝트 환경의 무관한 변경 이후 같은 코드에 대한 같은 연구를 수락함
  • 코드베이스에서 심각한 메모리 버그 여러 개를 찾고 확인한 뒤, 데모 익스플로잇 작성을 거부한 경우도 있었음
  • 같은 요청도 모델의 확률적 특성 때문에 실행마다 다른 결과를 낼 수 있었음
• 자발적 거부와 가드레일은 실제로 존재하지만, 그 자체만으로 완전한 안전 경계가 되기에는 충분히 일관적이지 않았음
• 유능한 사이버 프런티어 모델을 일반 제공하려면 Project Glasswing 같은 통제된 연구 환경 밖에서도 적절히 쓸 수 있도록 추가 안전장치가 필요함

신호와 잡음 문제

• 보안 취약점 선별에서 가장 어려운 일은 어떤 버그가 실제이고, 악용 가능하며, 지금 고쳐야 하는지 결정하는 것임
• 이 문제는 AI 이전에도 어려웠고, AI 취약점 스캐너와 AI 생성 코드가 이를 더 악화시켰으며, Cloudflare는 여러 사후 검증 단계를 구축함

• 프로그래밍 언어

  • C와 C++는 직접 메모리 제어를 제공하며, 버퍼 오버플로와 범위 밖 읽기·쓰기 같은 버그 부류를 만듦
  • Rust 같은 메모리 안전 언어는 이런 부류를 컴파일 시점에 제거함
  • 메모리 안전하지 않은 언어로 작성된 프로젝트에서 일관되게 더 많은 오탐이 나타났음

• 모델 편향

  • 좋은 인간 연구자는 무엇을 찾았고 얼마나 확신하는지 알려주지만, 모델은 코드에 버그가 있든 없든 결과를 만들어내는 경향이 있음
  • 결과는 “possibly”, “potentially”, “could in theory” 같은 표현으로 완화되어 돌아오며, 이런 추측성 결과가 확실한 결과보다 훨씬 많았음
  • 탐색 도구로서는 합리적인 편향이지만, 선별 큐에서는 모든 추측성 결과가 사람의 주의와 토큰을 소모하고 수천 개로 누적되면 비용이 커짐
  • Mythos Preview는 여러 취약점을 별개로 보고하는 대신 동작하는 PoC로 결합하는 원시 요소 체인 능력에서 뚜렷한 개선을 보임
  • PoC가 포함된 결과는 바로 조치 가능한 결과에 가까워 “이게 실제인가”를 확인하는 시간을 크게 줄여줌
  • Cloudflare의 하네스는 더 많이 보고해 덜 놓치도록 의도적으로 조정되어 잡음도 많지만, Mythos Preview의 출력은 완화된 표현이 적고 재현 단계가 더 명확해 수정 또는 기각 결정에 필요한 작업을 줄였음

범용 코딩 에이전트를 저장소에 바로 적용하는 방식의 한계

• AI 보조 취약점 연구 초기에는 범용 코딩 에이전트에 임의 저장소를 주고 취약점을 찾게 하는 방식이 자연스러운 출발점이었음
• 이 방식은 결과를 만들어내지만, 실제 코드베이스를 의미 있게 커버하고 가치 있는 결과를 찾는 데는 적합하지 않았음

• 문맥

  • 코딩 에이전트는 기능 구현, 버그 수정, 리팩터링처럼 하나의 집중된 작업 흐름에 맞춰져 있음
  • 취약점 연구는 단일 복잡 기능, 보안 경계 전환, 명령 주입처럼 좁은 대상을 깊게 조사하고 이를 코드베이스 전체에서 수천 번 반복하는 좁고 병렬적인 작업에 가까움
  • 하위 에이전트를 쓰더라도 10만 줄 저장소에 대한 단일 에이전트 세션은 모델 문맥 창이 차고 압축이 시작되기 전, 유용한 방식으로 표면의 0.1% 정도만 커버할 수 있음
  • 압축 과정에서 중요했을 수 있는 이전 결과가 버려질 가능성도 있음

• 처리량

  • 단일 스트림 에이전트는 한 번에 하나의 작업만 수행함
  • 실제 코드베이스에는 여러 구성 요소에 대한 많은 가설을 동시에 적용하고, 흥미로운 지점이 나오면 더 넓게 분기할 능력이 필요함
  • 연구자가 이미 단서를 갖고 있고 두 번째 검토자가 필요할 때는 코딩 에이전트가 수동 조사에 적합함
  • 높은 커버리지를 달성하는 도구로는 부적합해, Cloudflare는 Mythos Preview 주변에 하네스를 구축하는 쪽으로 전환함

하네스가 해결한 문제

• 대규모 실행 경험은 전체 실행을 관리하는 하네스가 필요하다는 결론으로 이어짐

• 좁은 범위가 더 나은 결과를 만듦

  • “이 저장소에서 취약점을 찾아라”는 요청은 모델을 헤매게 만듦
  • “이 특정 함수에서 명령 주입을 보라, 위에는 이 신뢰 경계가 있고, 여기 아키텍처 문서와 이 영역의 기존 커버리지가 있다”는 식의 요청은 실제 연구자의 작업 방식에 더 가까운 결과를 냄

• 적대적 검토가 잡음을 줄임

  • 초기 결과와 큐 사이에 두 번째 에이전트를 배치하면 첫 번째 에이전트가 자기 검토에서 놓칠 잡음을 많이 잡아냄
  • 두 번째 에이전트는 다른 프롬프트와 다른 모델을 쓰며, 자체 결과를 생성할 권한은 없음
  • 한 에이전트에게 조심하라고 말하는 것보다 두 에이전트를 의도적으로 불일치 상태에 두는 방식이 훨씬 효과적이었음

• 체인을 에이전트별로 나누면 추론이 좋아짐

  • “이 코드에 버그가 있는가”와 “공격자가 시스템 외부에서 실제로 이 버그에 도달할 수 있는가”는 서로 다른 질문임
  • 두 질문을 분리하면 각 질문이 더 좁아지고, 모델은 각각에서 더 나은 성능을 냄

• 병렬의 좁은 작업이 하나의 포괄적 에이전트를 이김

  • 많은 에이전트가 좁게 정의된 질문을 처리하고 이후 결과를 중복 제거할 때 커버리지가 좋아짐
  • 하나의 에이전트에게 포괄성을 요구하는 방식보다 효과적이었음
  • Cloudflare는 Mythos Preview를 사용해 기존 하네스를 그 강점에 맞게 확장·조정·개선함

Cloudflare의 취약점 발견 하네스

• 이 하네스는 Cloudflare의 런타임, 엣지 데이터 경로, 프로토콜 스택, 제어 평면, 의존하는 오픈소스 프로젝트의 실제 코드를 스캔하는 데 사용됨

• Recon

  • 에이전트가 저장소를 위에서부터 읽고, 각 하위 시스템을 맡는 하위 에이전트로 분기함
  • 빌드 명령, 신뢰 경계, 진입점, 예상 공격 표면을 담은 아키텍처 문서를 생성함
  • 다음 단계에 넘길 초기 작업 큐도 만들며, 모든 후속 에이전트에 공유 문맥을 제공해 모델이 헤매는 문제를 줄임

• Hunt

  • 각 작업은 하나의 공격 부류와 범위 힌트로 구성됨
  • 실제 버그를 찾는 헌터 에이전트들이 보통 약 50개씩 동시에 실행되고, 각 헌터는 몇 개의 탐색 하위 에이전트로 다시 분기함
  • 각 헌터는 작업별 임시 디렉터리에서 PoC 코드를 컴파일하고 실행하는 도구에 접근함
  • 대부분의 작업은 하나의 포괄적 에이전트가 아니라 많은 좁은 작업의 병렬 실행으로 이뤄짐

• Validate

  • 독립 에이전트가 코드를 다시 읽고 원래 결과를 반증하려고 시도함
  • 다른 프롬프트를 사용하며, 자체적으로 새로운 결과를 낼 수 없음
  • 헌터가 자기 작업을 검토할 때 놓칠 의미 있는 비율의 잡음을 잡아냄

• Gapfill

  • 헌터가 건드렸지만 충분히 커버하지 못한 영역을 표시함
  • 해당 영역은 다른 패스를 위해 다시 큐에 들어감
  • 모델이 이미 성공한 공격 부류 쪽으로 기울어지는 경향을 상쇄함

• Dedupe

  • 같은 근본 원인을 공유하는 결과를 하나의 레코드로 합침
  • 변형 분석은 기능이지, 중복으로 큐를 부풀리는 방식이 아님

• Trace

  • 공유 라이브러리에서 확인된 각 결과에 대해 트레이서 에이전트가 소비자 저장소별로 하나씩 분기함
  • 교차 저장소 심볼 인덱스를 사용해 공격자 제어 입력이 시스템 외부에서 실제로 버그에 도달하는지 판단함
  • “결함이 있다”를 “도달 가능한 취약점이 있다”로 바꾸는 가장 중요한 단계였음

• Feedback

  • 도달 가능한 추적 결과가 해당 버그가 실제로 노출되는 소비자 저장소의 새 헌트 작업이 됨
  • 실행될수록 파이프라인이 개선되는 루프를 닫음

• Report

  • 에이전트가 사전 정의된 스키마에 맞춰 구조화된 보고서를 작성함
  • 스키마 검증 오류를 스스로 수정하고 ingest API에 제출함
  • 출력은 자유 형식 산문이 아니라 질의 가능한 데이터가 됨

보안 팀에 주는 의미

• Mythos Preview를 본 다른 보안 리더들은 더 빠르게 스캔하고 더 빠르게 패치해 대응 주기를 압축하려 했음
• Cloudflare가 대화한 팀 중 하나 이상은 CVE 공개부터 프로덕션 패치까지 2시간 SLA로 운영하고 있었음
• 공격자 타임라인이 짧아지면 방어자 타임라인도 짧아져야 하지만, 속도만으로는 충분하지 않음
• 패치를 더 빠르게 한다고 해서 패치를 만들어내는 파이프라인의 형태가 바뀌지는 않음
  • 회귀 테스트가 하루 걸린다면 회귀 테스트를 건너뛰지 않고 2시간 SLA에 도달할 수 없음
  • 회귀 테스트를 건너뛰며 배포한 버그는 원래 고치려던 버그보다 더 나쁠 수 있음
  • 모델이 직접 패치를 작성하게 했을 때 원래 버그는 고쳤지만 코드가 의존하던 다른 부분을 조용히 깨뜨린 패치가 일부 배포된 일이 있었음
• 더 어려운 질문은 취약점 주변 아키텍처를 어떻게 설계할 것인가임
  • 버그가 존재하더라도 공격자가 악용하기 어렵게 만들어야 함
  • 취약점 공개와 패치 사이의 간격이 덜 중요해지도록 만들어야 함
  • 애플리케이션 앞단에서 버그 도달을 차단하는 방어가 필요함
  • 코드의 한 부분 결함이 공격자에게 다른 부분 접근 권한을 주지 않도록 애플리케이션을 설계해야 함
  • 개별 팀 배포를 기다리지 않고 코드가 실행되는 모든 위치에 동시에 수정 사항을 배포할 수 있어야 함
• 같은 능력은 양면성을 가짐
  • 자체 코드의 버그를 찾는 능력은 잘못된 손에 들어가면 인터넷상의 모든 애플리케이션에 대한 공격도 가속할 수 있음
  • Cloudflare는 수백만 개 애플리케이션 앞단에 있으며, 위의 아키텍처 원칙은 고객을 대신해 적용하도록 제품이 만들어진 원칙이라고 밝힘
• Mythos Preview 연구는 통제된 환경에서 Cloudflare 자체 코드를 대상으로 수행됐고, 발견된 모든 취약점은 Cloudflare의 공식 취약점 관리 프로세스에 따라 선별·검증됐으며 필요한 경우 수정됨