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

^{source https://blog.cloudflare.com/cyber-frontier-models/}

Project Glasswing: Mythos가 보여준 것

• 지난 몇 달간 자체 인프라에 보안 특화 LLM 여러 종을 투입해 시험

  • 자사 시스템의 잠재 취약점을 미리 찾아 보완하고, 최신 모델로 공격자가 어디까지 할 수 있을지도 가늠하는 용도

• 그중 가장 큰 주목을 받은 모델이 Anthropic의 Mythos Preview

  • 몇 주 전 Project Glasswing 일환으로 Mythos Preview를 사용할 기회를 얻었고, 사내 저장소 50여 개 이상에 적용해 무엇을 찾아내는지와 실제 작동 방식을 확인

• 이 글은 관찰 결과와 모델의 강점·한계, 그리고 이를 대규모로 쓰려면 주변 아키텍처와 프로세스를 어떻게 바꿔야 하는지 정리

Mythos Preview에서 달라진 점

• Mythos Preview는 분명한 도약

  • 이전부터 여러 모델을 코드에 적용해 왔지만, 기존 범용 프런티어 모델에서 Mythos Preview로 넘어오며 생긴 변화는 단순한 성능 개선이 아니었음

• 같은 일을 더 잘하는 도구라기보다, 다른 종류의 일을 맡는 다른 종류의 도구에 가까움

  • 예전 모델과 일대일 벤치마크로 비교하기보다 실제로 무엇을 할 수 있는지 설명하는 편이 더 적절

• Mythos Preview에서 특히 두드러진 점은 두 가지

  • 익스플로잇 체인 구성(Exploit chain construction)

    • 실제 공격은 버그 하나로 끝나지 않음

    • 여러 작은 공격 원시 기능을 엮어 동작하는 익스플로잇으로 연결하는 방식

    • 예를 들어 use-after-free를 임의 읽기·쓰기 원시 기능으로 바꾸고, 제어 흐름을 탈취한 뒤 return-oriented programming(ROP) 체인으로 시스템 전체 제어권을 확

    • Mythos Preview는 이런 원시 기능 여러 개를 받아 실제로 성립하는 증명까지 어떻게 결합할지 추론 가능

    • 그 과정에서 드러난 추론도 자동 스캐너 출력보다는 시니어 연구자의 작업에 가까움

  • 증명 생성(Proof generation)

    • 버그를 찾는 일과 실제 악용 가능성을 입증하는 일은 별개

    • Mythos Preview는 둘 다 수행

    • 의심한 버그를 실제로 유발하는 코드를 작성하고, 임시 환경에서 컴파일한 뒤 실행

    • 프로그램이 예상대로 동작하면 그것이 곧 증명

    • 예상과 다르면 실패 결과를 읽고 가설을 조정해 다시 시도

    • 중요한 것은 버그 발견 자체만이 아니라 이 반복 루프

    • 동작하는 증명 없는 취약점 의심은 추정에 머무르지만, Mythos Preview는 그 간극을 스스로 메움

• 이런 특성 일부가 Mythos Preview만의 완전한 독점 능력은 아님

  • 같은 하네스에 다른 프런티어 모델도 넣어 보니 같은 근본 버그를 꽤 많이 찾아냈고, 일부는 추론 단계에서도 예상보다 더 나아감

  • 한계는 조각을 이어 붙이는 지점에서 드러남

  • 흥미로운 버그를 찾고 왜 중요한지 설득력 있게 설명한 뒤, 실제 체인은 완성하지 못한 채 멈추는 경우가 많았음

• Mythos Preview로 달라진 핵심은, 백로그에 묻히던 낮은 심각도의 버그를 더 치명적인 단일 익스플로잇 체인으로 엮어낼 수 있게 됐다는 점

정당한 취약점 연구에서 나타난 모델 거부

• Project Glasswing에서 제공된 Mythos Preview에는 일반 공개 모델(Opus 4.7, GPT-5.5 등)에 들어가는 추가 안전장치가 적용되지 않았음

• 그럼에도 이 모델은 일부 요청에 스스로 제동을 거는 모습

  • 취약점 탐색에 유용했던 사이버 역량과 마찬가지로, 정당한 보안 연구 요청에도 간헐적으로 거부 반응을 보이는 창발적 가드레일이 나타남

  • 문제는 이런 거부가 일관되지 않는다는 점

  • 같은 작업도 표현 방식이나 맥락이 조금만 달라지면 결과가 완전히 달라질 수 있었음

• 실제로 같은 프로젝트, 같은 코드에 대한 취약점 연구를 처음에는 거부했다가, 프로젝트 환경에 무관한 변경이 들어간 뒤에는 수행에 동의한 사례가 있었음

  • 분석 대상 코드 자체는 전혀 바뀌지 않았음

• 다른 사례에서는 코드베이스의 심각한 메모리 버그 여러 개를 찾아 확인해 놓고도 시연용 익스플로잇 작성을 거부

  • 같은 요청도 표현을 바꾸면 다른 답이 나왔고, 모델의 확률적 특성 때문에 완전히 같은 요청도 실행마다 다른 결과가 나오기도 함

  • 의미상 같은 작업인데도 언제, 어떤 맥락으로 제시됐는지에 따라 정반대 결과가 나올 수 있는 상황

• 이 점이 중요한 이유는, 모델의 자생적 거부와 가드레일이 실제로 존재하더라도 그것만으로 완전한 안전 경계가 되지는 못하기 때문

  • 앞으로 강력한 사이버 프런티어 모델이 일반에 공개된다면, 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로 만드는 능력이 컸음

  • PoC가 함께 도착한 발견은 바로 조치 가능한 발견이고, "이게 진짜인가?"를 따지는 시간이 크게 줄어듦

• 우리가 쓰는 하네스는 일부러 과다 보고 쪽으로 조정돼 있음

  • 더 많이 보고 덜 놓치려는 대신 노이즈도 훨씬 많아짐

  • 그래도 트리아지 단계에서 Mythos Preview 출력은 눈에 띄게 품질이 높았음

  • 유보 표현이 줄고, 재현 절차는 더 명확해졌고, 수정할지 기각할지 결정하는 데 드는 작업도 줄었음

범용 코딩 에이전트를 저장소에 바로 투입해도 안 되는 이유

• 작년 AI 보조 취약점 연구를 시작했을 때 가장 먼저 떠올린 접근은 단순했음

  • 범용 코딩 에이전트를 임의 저장소에 붙이고 취약점을 찾아보라고 시키는 방식

• 이 접근은 겉보기에는 작동함

  • 모델은 실제로 발견 사항을 내놓음

  • 하지만 실제 코드베이스를 의미 있게 커버하고, 가치 있는 발견을 식별하는 데는 제대로 작동하지 않았음

• 이유는 크게 두 가지

• 맥락

  • 코딩 에이전트는 기능 개발, 버그 수정, 리팩터링처럼 한 줄기 작업에 맞춰 튜닝된 구조

  • 많은 소스 코드를 읽고, 한 번에 하나의 가설만 붙든 채 반복 검증하는 방식

  • 이런 형태는 본질적으로 좁고 병렬적인 취약점 연구와 맞지 않음

  • 사람 연구자는 특정 대상 하나를 정해 깊게 파고듦

    • 하나의 복잡한 기능일 수도 있고

    • 보안 경계 사이 전이일 수도 있으며

    • 공격자 입력이 셸 명령으로 실행되는 command injection 같은 특정 취약점 계열일 수도 있음

  • 이런 조사를 기능, 보안 경계, 취약점 계열을 바꿔 가며 코드베이스 전반에 수천 번 반복하는 흐름

  • 10만 줄 규모 저장소에서 단일 에이전트 세션은 서브에이전트를 붙여도 유의미하게 커버할 수 있는 범위가 많아야 전체 표면의 0.1% 수준

  • 그전에 모델 컨텍스트 창이 차고 compaction이 시작되며, 앞서 나온 중요한 단서가 밀려날 위험도 큼

• 처리량

  • 단일 스트림 에이전트는 한 번에 한 가지씩만 처리하지만, 실제 코드베이스에는 여러 컴포넌트에 여러 가설을 동시에 적용하고 흥미로운 신호가 나오면 더 넓게 확장할 수 있어야 함

  • 단일 에이전트를 더 강하게 돌릴 수는 있어도, 어느 시점부터는 모델보다 상호작용 구조 자체가 병목이 됨

  • 연구자가 이미 단서를 쥔 상태에서 두 번째 눈으로 점검받는 용도라면, 코딩 에이전트 안에서 모델을 직접 쓰는 방식도 충분히 유효

  • 다만 높은 커버리지를 확보하는 도구로는 맞지 않음

  • 이 점을 받아들인 뒤 Mythos Preview에 맞지 않는 일을 억지로 시키는 대신, 그 주변 하네스를 구축하는 쪽으로 방향 전환

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

• 이 작업을 대규모로 돌리며 얻은 교훈은 네 가지였고, 모두 전체 실행을 관리하는 하네스의 필요성으로 이어짐

• 범위를 좁힐수록 더 나은 발견

  • 모델에 "이 저장소에서 취약점을 찾아라"라고 하면 이리저리 헤맴

  • "이 특정 함수에서 command injection을 찾아라, 그 위에는 이 신뢰 경계가 있고, 여기 아키텍처 문서와 이 영역의 기존 커버리지가 있다"라고 주면 실제 연구자에 훨씬 가까운 방식으로 조사 가능

• 적대적 검토가 노이즈를 줄임

  • 초기 발견과 큐 사이에 두 번째 에이전트를 두고, 프롬프트와 모델을 다르게 하며, 새 발견을 직접 만들지 못하게 하면 첫 번째 에이전트가 자기 검토만으로는 놓칠 노이즈를 상당수 걸러냄

  • 한 에이전트에게 조심하라고 지시하는 것보다, 의도적으로 서로 다른 입장에 놓인 두 에이전트를 붙이는 편이 훨씬 효과적

• 체인을 에이전트별로 나눌수록 추론 품질이 좋아짐

  • "이 코드에 버그가 있는가?"와 "공격자가 시스템 외부에서 실제로 이 버그까지 도달할 수 있는가?"는 서로 다른 질문

  • 둘을 한 번에 묻는 것보다 분리해 물을 때 각 질문의 범위가 더 좁아져 성능이 좋아짐

• 병렬의 좁은 작업이 하나의 완전탐색 에이전트보다 나음

  • 한 에이전트에게 완전탐색을 요구하기보다, 범위를 좁힌 질문을 여러 에이전트가 병렬로 처리하고 뒤에서 결과를 중복 제거할 때 커버리지가 더 좋아짐

• 이 관찰은 모두 모델의 행동 특성에 관한 것

• 이를 종합하면 더 이상 채팅 인터페이스가 아니라, 최종 결과를 만들어내는 하네스에 가까운 구조

• 하네스 구축의 첫걸음은 단순함

  • 모델에게 하네스 구축 자체를 돕게 하면 됐고, 실제로 그렇게 진행함

  • Mythos Preview를 활용해 기존 하네스를 보강하고, 강점에 맞게 조정하며 개선함

• 아래는 실제 취약점 탐지 하네스의 구성 예시

우리의 취약점 탐지 하네스

• 이 하네스는 런타임, edge 데이터 경로, 프로토콜 스택, control plane, 그리고 우리가 의존하는 오픈소스 프로젝트의 실제 운영 코드를 스캔하는 데 사용됨

보안팀에 주는 의미

• 다른 보안 리더들이 Mythos Preview에 가장 크게 반응한 지점은 속도

  • 더 빠르게 스캔하고, 더 빨리 패치하고, 대응 주기를 압축하려는 방향

• 실제로 이야기를 나눈 팀들 가운데 CVE 공개 후 프로덕션 패치까지 2시간 SLA로 운영하는 곳이 이미 여럿 있음

• 공격자 타임라인이 짧아질수록 방어자 타임라인도 짧아져야 한다는 본능 자체는 이해 가능

• 그래도 속도만으로는 부족함

  • 많은 팀이 시간, 노력, 비용을 크게 들인 뒤에야 그 사실을 뼈아프게 배우게 될 가능성이 큼

• 패치를 더 빨리 한다고 해서, 그 패치를 만들어내는 파이프라인의 구조 자체가 바뀌지는 않음

  • 회귀 테스트에 하루가 걸린다면, 2시간 SLA를 맞추려면 결국 회귀 테스트를 건너뛰게 됨

  • 회귀 테스트를 생략하고 배포한 버그는, 원래 막으려던 버그보다 더 심각한 경우가 많음

• 모델이 스스로 패치를 쓰게 두었을 때도 비슷한 교훈을 얻음

  • 원래 버그는 고쳤지만, 그 코드가 의존하던 다른 무언가를 조용히 깨뜨린 패치가 실제로 몇 건 나감

• 더 어려운 질문은 취약점 주변 아키텍처를 어떻게 설계할 것인가임

• 원칙은 버그가 존재하더라도 공격자가 악용하기 어렵게 만들어, 취약점 공개 시점과 패치 완료 시점 사이 간격의 중요도를 낮추는 것

• 그러려면 애플리케이션 앞단에서 동작하며 버그 자체에 도달하지 못하게 막는 방어선이 필요함

• 애플리케이션 구조도 한 부분의 결함이 다른 부분에 대한 접근권으로 이어지지 않게 설계해야 함

• 코드가 실행되는 모든 위치에 동시에 수정사항을 배포할 수 있어야 함

  • 각 팀이 개별적으로 배포하기를 기다리는 방식으로는 부족함

• 이 주제는 분명 양면적임

  • 우리 코드의 버그를 찾는 데 도움이 된 역량이 악의적 주체의 손에 들어가면, 인터넷 전반의 모든 애플리케이션을 겨냥한 공격도 더 빠르게 고도화될 수 있음

  • Cloudflare는 그런 애플리케이션 수백만 개의 앞단에 있고, 앞서 설명한 아키텍처 원칙이 바로 고객을 대신해 적용되도록 자사 제품을 설계한 기반

  • 이것이 고객에게 어떤 의미인지도 앞으로 몇 주 안에 추가로 공유 예정

• 비슷한 작업을 하는 팀이라면 security-ai-research@cloudflare.com으로 연락해 서로 경험을 비교할 수 있음

• Mythos Preview를 활용한 이번 연구는 통제된 환경에서 자사 코드만 대상으로 진행

  • 이 과정에서 드러난 모든 취약점은 Cloudflare의 공식 취약점 관리 절차에 따라 분류·검증했고, 조치가 필요한 항목은 모두 수정 완료

• 이번 작업은 팀 차원의 협업 결과물

  • Albert Pedersen, Craig Strubhart, Dan Jones, Irtefa Fairuz, Martin Schwarzl, Rohit Chenna Reddy가 이번 블로그 글의 바탕이 된 연구, 엔지니어링, 분석에 기여함

HN 댓글에서 가장 많이 나온 반응은 구체적인 수치가 빠졌다는 불만이었다. 몇 건을 찾았는지보다 실제 취약점과 오탐이 각각 얼마나 있었는지, 사람이 이를 검증하는 데 얼마나 시간이 들었는지가 빠져 있어 홍보성 글처럼 읽힌다는 지적이 반복됐다.

이게 모델 자체의 도약인지, 하네스의 성과인지를 두고도 논쟁이 길었다. 범위를 좁히고 신뢰 경계나 아키텍처 문서를 함께 주면 결과가 좋아진다는 건 익숙한 운영 방식인데, 정작 글은 무엇이 Mythos의 변화이고 무엇이 오케스트레이션의 효과인지 끝내 분명하게 갈라 보여주지 못했다는 반응이 많았다.

다만 범용 모델과 다른 지점으로 더 긴 호흡의 탐색 능력과 취약점 연결 능력을 꼽는 흐름도 분명했다. 작은 버그를 여러 단계로 엮어 실제 악용 경로를 만들고, 실패한 가설을 고쳐 가며 다시 시도하는 부분은 기존 모델보다 실무 가치가 높아 보인다는 평가가 이어졌다.

그래서 관심도 단순 탐지보다 검증 단계에 더 쏠렸다. 모델이 익스플로잇 코드를 직접 써서 재현까지 해야 오탐 논쟁이 줄어드는데, 그 과정이 빠지면 설명이 그럴듯한 결과를 결국 사람이 다시 걸러내야 해서 검토 부담이 그대로 남는다는 의견이 많았다.

운영 방식 자체는 가져다 쓸 만하다는 반응도 있었다. 큰 탐색 범위를 상위 에이전트가 나누고, 앞 단계에서 찾은 단서를 다음 탐색 큐로 넘기거나 다른 시도로 다시 검토하게 하는 절차는 보안 외 작업에도 적용할 수 있다는 얘기가 나왔다.

보안 연구용 모델인데도 요청 맥락에 따라 거절 반응이 달라진다는 대목은 의외라는 반응을 불렀다. 합법적인 접근 권한을 더 자주 입증해야 하거나 표현을 바꿔 여러 번 시도해야 한다면 자동화의 이점이 줄어든다는 우려가 남았다.