에이전트에게 「취약점을 찾아줘」라고 말하면 왜 실패하는가──Cloudflare가 50개 이상의 리포지토리로 보여준 harness의 정체

「코딩 에이전트 (Coding Agent)를 자사 리포지토리 (Repository)로 향하게 하여, 『취약점을 찾아줘』라고 부탁한다」──직관적인 생각입니다. 하지만 이것은 제대로 실패합니다. Cloudflare가 Anthropic의 보안 특화 모델인 Mythos Preview를 사용하여, 자사의 50개 이상의 리포지토리(런타임, 에지 데이터 경로, 프로토콜 스택, 컨트롤 플레인, 의존하고 있는 OSS)를 실제로 스캔한 Project Glasswing의 보고서는, 왜 단순한 방식이 실패하는지, 그리고 대신 무엇이 효과적인지를 명확하게 보여줍니다.

그리고 결론은 지금까지의 기사들과 맥을 같이 합니다──주역은 모델이 아니라 harness입니다. 순서대로 기술적인 내용까지 살펴보겠습니다.

우선: Mythos Preview는 무엇이 「한 단계 다른」가

harness 이야기를 하기 전에, 토대가 되는 모델이 무엇을 할 수 있는지 파악해 둡시다. Cloudflare는 「이것은 이전 세대의 범용 프론티어 모델 (Frontier Model)의 개량판이 아니라, 다른 종류의 도구가 다른 종류의 일을 하고 있는 것」이라고 단언하며, 특히 두 가지 능력을 꼽습니다.

① 익스플로잇 체인 (Exploit Chain) 구축. 현실의 공격은 단 하나의 버그로 완결되는 경우가 드뭅니다. 작은 「공격 프리미티브 (Attack Primitive)」를 여러 개 연결해야 비로소 작동하는 익스플로잇이 됩니다. 예를 들어, use-after-free (해제 후 사용) 버그를 「임의의 읽기/쓰기」 프리미티브로 바꾸고, 제어 흐름을 탈취하여, ROP (return-oriented programming) 체인으로 시스템을 완전히 장악하는 식입니다. Mythos Preview는 이러한 프리미티브를 여러 개 다루며, 어떻게 조합해야 작동하는 증명이 되는지를 추론할 수 있습니다. 그 중간 과정의 사고는 자동 스캐너의 출력이라기보다, 시니어 연구자의 작업처럼 보인다고 보고서는 말합니다.

② 증명 (PoC, Proof of Concept) 생성. 버그를 찾는 것과 그것이 정말로 악용 가능한지 증명하는 것은 별개의 문제입니다. Mythos Preview는 두 가지를 모두 수행합니다. 의심스러운 버그를 트리거하는 코드를 작성하고, 일회용 작업 환경에서 컴파일하여 실행합니다. 프로그램이 예상대로 작동하면 그것이 증명입니다. 작동하지 않으면 실패를 읽고 가설을 수정하여 다시 시도합니다. 이 루프 자체가 버그 발견만큼이나 중요하며, 「작동하는 증명이 없는 의심」은 단순한 추측에 그칠 수 있는 지점을 Mythos Preview는 스스로 그 간극을 메웁니다.

이 부분이 핵심인데, 동일한 harness에 다른 프론티어 모델을 통과시켜도 많은 근본적인 버그는 발견되었고, 추론 면에서도 기대 이상으로 진전되는 경우도 있었습니다. 차이가 벌어진 것은 「파편을 꿰매는」 단계입니다. 어떤 모델은 흥미로운 버그를 특정하고 왜 중요한지를 정중하게 작성하지만, 거기서 멈춥니다──체인은 미완성인 채로, 악용 가능성은 불투명해집니다. Mythos Preview로 변화된 점은, 기존 방식이라면 백로그 (Backlog)에 파묻혀 보이지 않았을 저심각도 버그를 하나의 더 심각한 익스플로잇으로 연쇄시킬 수 있다는 점이었습니다.

즉 모델은 확실히 진보했습니다. 하지만──라고 보고서는 여기서 다시 harness 이야기로 돌아갑니다.

왜 범용 코딩 에이전트를 향하게 해도 안 되는가

Cloudflare는 작년에 AI 지원 취약점 연구를 시작했을 때, 가장 단순한 발상을 시도했습니다. 「범용 코딩 에이전트를 적당한 리포지토리에 향하게 하여 취약점을 찾게 한다」. 이것은 「findings (발견 사항)는 나온다」는 의미에서는 작동합니다. 하지만 실제 코드베이스를 의미 있는 범위로 커버하고 가치 있는 발견을 내놓는다는 의미에서는 작동하지 않습니다. 이유는 두 가지입니다.

① 문맥 (Context). 코딩 에이전트는 「하나의 집중된 작업 흐름」──기능을 만들기, 버그 수정하기, 리팩터링하기──에 튜닝되어 있습니다. 대량의 소스를 읽어 들이고, 한 번에 하나의 가설을 유지하며, 그것에 대해 반복합니다. 이는 취약점 연구와는 형태가 완전히 반대입니다. 취약점 연구는 본질적으로 「좁고 병렬적」입니다. 인간 연구자는 어떤 한 점(하나의 복잡한 기능, 보안 경계를 가로지르는 전이, 혹은 커맨드 인젝션 (Command Injection)과 같은 특정 취약점 클래스 = 공격자의 입력이 최종적으로 쉘 커맨드로 실행되는 것 등)을 선택하여 철저하게 조사합니다. 그리고 그것을 다른 기능, 경계, 취약점 클래스에 대해 코드베이스 전체에서 수천 번 반복합니다. 10만 행의 리포지토리에 대해 단일 에이전트의 세션은, 서브 에이전트를 사용하더라도 컨텍스트 윈도우 (Context Window)가 가득 차서 컴팩션 (Compaction, 문맥 압축)이 실행되기 전에 공격면의 0.1% 정도밖에 의미 있는 형태로 커버할 수 없습니다. 게다가 그 컴팩션이 나중에 효과를 발휘했을 초기 발견을 버려버리는 경우도 있습니다.

② 처리량 (Throughput). 단일 스트림의 에이전트는 한 번에 하나씩밖에 수행할 수 없습니다. 하지만 실제 코드베이스는 「많은 가설 × 많은 컴포넌트」를 동시에 대입해야 하며, 흥미로운 결과가 나오면 더욱 가지를 쳐나가야 합니다. 에이전트를 강력하게 구동할 수는 있어도, 어느 시점부터는,

당신은 모델에 의해 제약받는 것을 멈추고, 상호작용의 "형태" 그 자체에 의해 제약받기 시작합니다.

(at some point you stop being limited by the model and start being limited by the shape of the interaction itself)

모델을 코딩 에이전트로 직접 사용하는 것은, 연구자가 이미 단서를 가지고 있으며 「또 한 쌍의 눈」이 필요한 수동 조사에는 적합합니다. 하지만 높은 커버리지 (Coverage)를 달성하기 위한 도구로서는 잘못된 선택입니다. 그것을 받아들인 시점에서, 그들은 Mythos에게 잘못된 일을 시키는 것을 멈추고, 주변에 harness를 구축하기 시작한 것입니다.

노이즈와의 싸움──signal-to-noise야말로 핵심

취약점 대응에서 가장 어려운 것은, 발견한 버그 중에서 「어느 것이 진짜이고, 어느 것이 악용 가능하며, 어느 것을 지금 즉시 수정해야 하는가」를 구분하는 것입니다. 이는 AI 이전부터 어려운 문제였습니다. AI 스캐너와 AI 생성 코드가 이를 더욱 악화시키고 있습니다. Cloudflare는 사후 검증 단계를 여러 겹 쌓아 이에 대처해 왔습니다.

보고서에 따르면 노이즈율을 지배하는 요인은 두 가지가 있습니다.

① 프로그래밍 언어. C와 C++은 직접적인 메모리 조작을 허용하며, 그에 따라 버그 클래스──버퍼 오버플로우 (Buffer Overflow), 경계 외 읽기/쓰기──를 생성합니다. 이것들은 Rust와 같은 메모리 안전 (Memory-safe) 언어라면 컴파일 시점에 사라질 종류의 것들입니다. 실제로 메모리 비안전 언어로 작성된 프로젝트에서는 일관되게 허위 양성 (False Positive)이 많이 발생했습니다.

② 모델의 편향 (Bias). 우수한 인간 연구자는 「무엇을 발견했는지, 얼마나 확신하는지」를 전달합니다. 모델은 전달하지 않습니다. 모델에게 버그를 찾으라고 하면, 코드에 버그가 있든 없든 찾아냅니다. 돌아오는 결과물 (Findings)은 「possibly (아마도)」, 「potentially (잠재적으로)」, 「could in theory (이론상으로는 가능함)」와 같이 희석되어 있으며, 그 모호한 결과물들이 확실한 것들을 숫자로 압도합니다. 탐색적인 도구로서는 타당한 편향일지라도, 트리아지 (Triage) 큐 입장에서는 재앙입니다. 투기적인 결과물 하나하나가 거부하기 위해 인간의 주의력과 토큰을 소모하며, 그 비용이 수천 건의 규모로 쌓입니다.

Mythos Preview는 이 지점에서 명확하게 개선되었다고 합니다. 특히 프리미티브 (Primitive)를 연쇄시키는 능력──여러 취약점을 개별적으로 보고하는 것이 아니라, 하나의 작동하는 PoC (Proof of Concept)로 통합하는 능력──덕분에, PoC와 함께 전달되는 결과물은 그대로 행동으로 옮길 수 있습니다. 「이게 애초에 진짜인가?」에 소비하는 시간이 급격히 줄어듭니다. 참고로 Cloudflare의 harness는 의도적으로 과잉 보고 (Over-report) 쪽으로 튜닝되어 있습니다. 놓치는 것을 줄이는 만큼 노이즈는 늘어납니다. 하지만 트리아지 시점에서 Mythos의 출력은 분명히 질이 높습니다. 모호함이 줄어들고, 재현 절차가 명확하며, 「수정할 것인가, 거부할 것인가」의 판단에 도달하기까지의 수고가 적습니다.

harness가 해결하는 4가지 사항

규모 있게 운용하며 얻은 교훈은 4가지였습니다. 모두 「전체 실행을 관리하는 harness가 필요하다」는 점을 가리키고 있었습니다.

좁은 스코프(Scope)가 더 좋은 발견을 만들어낸다. 「이 리포지토리의 취약점을 찾아줘」라고 하면 모델이 방황하게 된다. 「이 특정 함수의 커맨드 인젝션(Command Injection)을 이 신뢰 경계(Trust Boundary) 하에서 찾아줘. 아키텍처 문서는 이것이고, 이 영역의 과거 커버리지(Coverage)는 이것이야」라고 말하면, 연구자가 실제로 하는 방식에 훨씬 가까워진다. -
적대적 리뷰(Adversarial Review)가 노이즈를 제거한다. 첫 번째 발견(Finding)과 큐(Queue) 사이에 두 번째 에이전트(별도의 프롬프트, 별도의 모델, 스스로 발견을 찾아낼 권한은 없음)를 배치하면, 첫 번째 에이전트가 자기 리뷰(Self-review)에서는 놓칠 법한 노이즈를 대량으로 잡아낸다. 두 에이전트를 의도적으로 대립시키는 것이 한 에이전트에게 "조심해"라고 말하는 것보다 훨씬 효과적이다. -
체인(Chain)을 에이전트 간에 나누면 추론(Reasoning)이 좋아진다. 「이 코드에 버그가 있는가?」와 「공격자가 외부에서 그 버그에 실제로 도달할 수 있는가?」는 별개의 질문이며, 나누어서 물었을 때 모델이 각각에 더 잘 답변한다. 합쳐진 버전보다 각 질문의 범위가 좁기 때문이다. -
좁은 병렬 태스크는 망라성을 노리는 단일 에이전트보다 우세하다. 다수의 에이전트가 엄격하게 스코프가 지정된 질문에 매달리고 나중에 결과를 중복 제거(Deduplication)하는 것이, 하나의 에이전트에게 "망라해라"라고 말하는 것보다 커버리지(Coverage)를 높일 수 있다.

이것들은 모두 「모델의 행동에 대한 관찰」이며, 이를 종합하면 더 이상 채팅 인터페이스가 아닌 무언가──최종 성과를 달성하게 만드는 harness를 그려낸다. 그리고 흥미로운 점은, harness를 만드는 첫걸음은 간단하며 모델 스스로 돕게 하면 된다는 것이다(실제로 그렇게 했다). Mythos Preview를 사용하여 원래의 harness를 Mythos의 강점에 맞춰 개량했다고 한다.

취약점 발견 harness의 전 단계

실제 harness는 단계별로 다음과 같이 구성되어 있습니다. 런타임(Runtime)/에지(Edge)의 데이터 경로/프로토콜 스택(Protocol Stack)/컨트롤 플레인(Control Plane)/의존 OSS에 대해 살아있는 코드를 스캔하는 데 사용되었습니다.

단계	수행 내용	효과적인 이유
Recon (정찰)	에이전트가 리포지토리를 위에서부터 읽고, 서브시스템 담당 서브 에이전트로 분기. 빌드 절차·신뢰 경계·진입점·예상 공격 표면을 작성한 「아키텍처 문서」를 생성하고, 다음 단계의 초기 태스크 목록도 생성함	하류(Downstream)의 모든 에이전트에게 공유 컨텍스트(Context)를 전달하여 방황을 방지함
Hunt (사냥)	각 태스크 = 「1가지 공격 클래스 + 스코프 힌트」. Hunter(실제로 버그를 찾는 에이전트)가 동시에 약 50개 병렬 기동되며, 각 Hunter는 다시 여러 개의 탐색 서브 에이전트로 가지를 침. PoC를 태스크별 일회용 작업 영역에서 컴파일 및 실행 가능	업무의 대부분을 차지함. 좁은 병렬 태스크 다수가 망라형 단일 에이전트보다 우세함
Validate (적대적 검증)	독립된 에이전트가 코드를 다시 읽고, 원래의 발견을 반증하려 시도함. 별도의 프롬프트를 사용하며, 자신의 새로운 발견을 내놓을 권한은 없음	Hunter의 자기 리뷰(Self-review)로는 잡아낼 수 없는 노이즈를 상당 부분 제거함
Gapfill	Hunter가 「접촉했으나 다 채우지 못했다」라고 표시한 영역을 다시 큐에 넣음	모델이 「과거에 맞닥뜨렸던 공격 클래스」로 편향되는 습성을 상쇄함
Dedupe (중복 제거)	동일한 근본 원인(Root Cause)의 발견을 하나의 레코드로 집약	변형 분석(Variant Analysis)을 기능으로 취급하여 큐가 중복으로 부풀려지는 것을 방지함
Trace (도달성 추적)	공유 라이브러리의 확정된 발견마다, Tracer가 이용 측 리포지토리당 1개의 인스턴스로 분기. 리포지토리 간 심볼 인덱스를 통해 공격자 제어 입력이 외부에서 해당 버그에 도달할 수 있는지 판정	「결함이 있다」를 「실제로 도달 가능한 취약점」으로 바꿈. 이 부분이 가장 중요함
Feedback	도달하는 트레이스(Trace)를, 버그가 실제로 노출되는 이용 측 리포지토리의 새로운 Hunt 태스크로 만듦	루프를 닫아, 돌리면 돌릴수록 파이프라인이 개선됨
Report	사전 정의된 스키마로 보고서를 생성하고, 스키마 위반은 스스로 수정하여 Ingest API에 제출	산문이 아닌 쿼리 가능한 데이터로 출력함

가장 핵심적인 부분은 「적대적 검증」

이 파이프라인에서 핵심적인 부분은 Validate 단계, 즉 두 에이전트를 의도적으로 대립시키는 설계입니다. 검증 역할은 「새로운 발견을 만들 권한 없이, 오직 원래의 발견을 무너뜨리는 것」에 집중합니다.

두 에이전트를 의도적으로 대립시키는 것이 한 에이전트에게 "조심해"라고 말하는 것보다 훨씬 효과적입니다.

(putting two agents in deliberate disagreement is way more effective than just telling one agent to be careful)

그리고 또 하나, 왜 역할을 나누는지에 대한 핵심은:

모델은 각각을 따로 물었을 때 더 잘 수행합니다. 각 질문이 합쳐진 버전보다 범위가 좁기 때문입니다.

(the model is better at each one when you ask them separately)

이는 제가 이전에 썼던 ClickHouse의 「판정의 벽」과 같은 계열의 이야기입니다. 그것은 「빠르고 자동화된 판정」이 거짓말을 하는 에이전트를 신뢰할 수 있는 존재로 바꾸었습니다. 이것은 「적대적인 두 번째 눈」이 그럴듯하기만 한 오탐(False Positive)을 걸러냅니다. L0–L7 라더(Ladder)로 말하자면, 검증역이라는 독립된 관문은 부탁(소프트 채널)이 아니라 구조(하드웨어에 가까운 방식)로 품질을 담보하는 L6적인 거버넌스에 해당합니다.

간과할 수 없는 이야기──모델은 「정당한 연구」조차 거부한다

이 부분은 기술과 안전의 경계선에 있어 흥미롭기에 남겨둡니다. Project Glasswing에서 Anthropic이 제공한 Mythos Preview는 일반 제공 버전(Opus 4.7이나 GPT-5.5)에 있는 추가적인 세이프가드(Safeguard)를 갖추지 않은 상태였습니다.

그럼에도 모델은 자발적으로 일부 요청을 거부합니다. 취약점 헌팅(Vulnerability Hunting)에 도움이 되었던 능력과 마찬가지로, 창발적인 가드레일(Guardrail)을 가지고 있어 정당한 보안 연구 요청조차 밀어내는 경우가 있습니다. 다만, 그 자발적인 거부는 일관적이지 않습니다. 보고된 사례가 꽤 유효합니다. 어떤 프로젝트에서는 처음에는 취약점 연구를 거부했으나, 코드와 무관한 환경 변경 이후에는 완전히 동일한 코드에 대해 동일한 연구 요청에 응했습니다. 다른 사례에서는 심각한 메모리 버그를 여러 개 찾아내고 확인했음에도, 데모용 익스플로잇(Exploit)을 작성하는 것은 거부했습니다. 의미론적으로 등가한 태스크라도, 언제 어떻게 제시되느냐에 따라 정반대의 결과가 나올 수 있습니다 (모델이 확률적(Probabilistic)인 이상, 동일한 요청이라도 실행할 때마다 다릅니다).

함의는 무겁습니다. 모델의 자발적인 거부는 실제이지만, 그것 단독으로 완전한 안전 경계로서 신뢰할 수 있을 만큼 일관적이지는 않습니다. 그렇기 때문에 향후 일반 제공될 사이버 능력을 갖춘 프런티어 모델(Frontier Model)은 이 베이스라인 동작 위에 반드시 추가적인 세이프가드를 얹어야 합니다. Project Glasswing와 같은 통제된 연구 환경 밖에서 널리 사용한다면 더욱 그렇습니다.

보안 팀에게 주는 의미──「속도」만으로는 살 수 없다

Mythos Preview에 대한 다른 보안 리더들의 반응 중 가장 컸던 것은 속도였습니다. 빠르게 스캔하고, 빠르게 패치하며, 대응 사이클을 단축하는 것. 여러 팀이 이제 「CVE 공개부터 운영 패치까지 2시간 SLA」로 움직이고 있다고 합니다. 공격자의 타임라인이 단축된다면 방어 측도 단축해야 한다는 발상은 이해합니다. 하지만 Cloudflare는 주의를 줍니다. 속도만으로는 부족합니다. 많은 팀이 그것을 고통스러운 방식으로 배우게 될 것입니다.

빠르게 패치하더라도 패치를 만들어내는 파이프라인의 "형태"는 변하지 않습니다. 회귀 테스트(Regression Test)에 하루가 걸린다면, 2시간 SLA를 달성하기 위해 이를 건너뛰어야만 합니다. 그리고 회귀 테스트를 건너뛰고 출시한 버그는 대개 고치려 했던 버그보다 질이 나쁩니다. 그들 스스로 모델에게 직접 패치를 작성하게 해 보았더니, 원래의 버그는 고치지만 코드가 의존하고 있던 다른 무언가를 조용히 망가뜨리는 패치가 몇 건 나왔다고 합니다.

따라서 정말 어려운 질문은 「취약점 주변의 아키텍처를 어떻게 설계할 것인가」로 향합니다. 원칙은 버그가 존재하더라도 공격자가 악용하기 어렵게 만드는 것입니다. 그렇게 하면 취약점이 공개된 시점부터 패치가 적용될 때까지의 간극이 그리 치명적이지 않게 됩니다. 구체적으로는 앱 앞단에 앉아 버그로의 도달 자체를 차단하는 방어, 코드 일부의 결함이 공격자에게 다른 부분으로의 접근 권한을 주지 않도록 하는 설계, 그리고 개별 팀의 배포를 기다리는 것이 아니라 코드가 실행되는 모든 지점에 동시에 수정 사항이 전달될 수 있도록 하는 것입니다.

그리고 이 이야기는 양날의 검이기도 하다고 솔직하게 적고 있습니다. 자사 코드의 버그 발견을 도운 것과 동일한 능력은 악의적인 손에 넘어가면 인터넷상의 모든 앱에 대한 공격을 가속화합니다. Cloudflare는 수백만 개의 앱 "앞단"에 앉아 있으며, 위의 아키텍처 원칙은 바로 그들의 제품이 고객을 위해 적용하기 위해 만들어진 것이라고 결론짓습니다.

개인적인 견해

이것은 「harness가 주인공」이라는 주장의 가장 선명한 실례라고 생각합니다. 저자 스스로 이렇게 단언합니다.

(이러한 관찰들은) 결국 모두 모델의 행동에 관한 이야기다. … 그것을 최종 성과로 바꾸는 것이 harness다.

흥미로운 점은, 효과를 발휘하는 기법들이 모두 「더 똑똑한 모델을 할당하는 것」이 아니라, 업무를 나누는 방식이라는 점이다. 좁게 나누기 (Hunt), 대립시키기 (Validate), 도달성으로 거르기 (Trace), 루프를 통해 살찌우기 (Feedback). 기반이 되는 모델은 동일하더라도, 상호작용의 형태를 바꾸는 것만으로도 공격 면 (Attack Surface) 의 0.1%밖에 보지 못했던 것이 돌아가기 시작한다. 더욱이 보안이라는 영역이기에, 「속도」가 아니라 「벽」과 「대립」 그리고 「아키텍처」를 통해 확률을 확정으로 끌어올린다는 설계 사상이 와닿는다──ClickHouse의 운영기(運用記)와 완전히 동일한 결론이다.

할인(Discount)해야 할 점도 솔직하게 밝힌다. Cloudflare는 구체적인 탐지 수, 오탐률 (False Positive Rate), 적대적 검증 (Adversarial Validation)을 통해 노이즈가 몇 % 감소했는지와 같은 정량적 결과를 공개하지 않았다. 효과는 어디까지나 설계에 대한 설명으로서 이야기되고 있다. Mythos 또한 Anthropic의 프리뷰 (Preview) 모델을 사용하여, 일반 제공 버전의 세이프가드 (Safeguard)를 해제한 상태에서의 검증이다. 따라서 「이것으로 취약점 헌팅 (Vulnerability Hunting)이 해결되었다」가 아니라, 「단일 에이전트가 아니라, 적대적 검증을 포함한 다중 에이전트 harness로 만들어야 한다」라는 설계상의 지침으로 읽는 것이 정확하다. 그럼에도 불구하고, harness가 어디에서 효과를 발휘하는지를 단계별로 이토록 구체적으로 보여준 보고를 나는 달리 알지 못한다.

참고

1차 (Cloudflare 공식·전문): Project Glasswing: what Mythos showed us
관련 (동일한 「harness가 주인공」인 계보):

이 기사는 「AI 워치」에도 게재하고 있습니다. 최첨단 AI를 기술적인 내용까지 일본어로 풀어내고 있습니다.