요즘은 버그에 대한 소문만으로도 보안 취약점(exploit)을 찾기에 충분하다

저는 오늘 OCaml의 cohttp 6.3.0 버전에서 경로 탐색 문제(path traversal issue)를 수정하는 보안 패치를 배포했습니다. 이 패치 자체는 간단했고, 평소라면 보안 절차는 문제를 비공개로 수정한 후, 영향을 받는 사용자들에게 알리고, 그 후에 공개 권고문을 발표하는 것이었을 겁니다. 하지만 이번에는 제가 이슈를 수정하기 위해 PR(Pull Request)을 열자마자 라이브 웹 서버 로그에서 정확한 버그 패턴의 프로브(probes)가 감지되는 것을 발견했습니다.

더 심각한 것은, 저는 대략적인 내용만 알고 있는 것만으로도 제가 직접 만든 에이전트(agents)를 사용해서 이 취약점을 찾아낼 수 있다는 것을 알게 되었고, 이는 공개 패치가 나오기 훨씬 전부터 공격자들이 악용할 수 있었다는 의미입니다!

보안 문제에 대한 소문만으로도 공격자들에게 새로운 취약점을 찾기에 충분한 정보를 제공하는 것 같으니, 우리는 오픈 소스에서 보안 대응 방식을 바꿔야 할 필요가 있습니다.

1 버그의 소문은 모든 새로운 에이전트 기반 취약점 시스템에 필요한 것이다

이 보고서는 지난주 Jane Street을 통해 Slack 채널로 비공개적으로 도착했으며, 그 자체는 Claude Fable을 통해 발견되었습니다. 이는 시간적 흐름(timelines)을 상당히 압축시킵니다...

1.1 현대 보안 보고서의 타임라인

패치를 자세히 검토하기 전에, 저는 제가 만든 Claude에게 영향을 받은 코드를 분석하게 하여 다른 잠재적인 문제점(경로 정규화 문제(path normalisation issues)를 조사하도록 요청하며)을 찾아보게 했습니다. Fable은 보안 차단 기능 때문에 명백히 거부했지만 (제가 Glasswing에 접근할 수 없어서), DeepSeek V4 Pro는 기꺼이 저를 도와주었고 독립적으로 여러 관련 문제를 발견했습니다. 또한 제 에이전트는 1분도 안 되어 로컬 라이브 서버를 프로빙하는 취약점(exploit)을 사소하게 생성해냈습니다.

버그 신고자와 가능한 수정 사항에 대해 몇 차례 논의한 후, 저는 더 많은 사람들의 시선을 받기 위해 cohttp#1145를 공개적으로 열었습니다. 보통 이런 과정은 며칠이 걸리고 일주일이나 이주 내에 배포되는 것이 합리적입니다. 그런데 약 10분 만에 (!) 이 웹사이트가 퍼센트 인코딩된 탐색 시퀀스(percent-encoded traversal sequences)에 대한 프로브를 받고 있는 것을 확인했는데, 이는 자동화된 감시자들이 공개 저장소들을 주시하고 있음을 나타냅니다.

만약 제가 로컬에서 제 자신의 취약점(exploit)을 만드는 데 단 1분밖에 걸리지 않았다면, 자동화된 공격 창이 시작하는 데 실제로 10분은 상당히 긴 시간처럼 느껴질 것입니다! 패키지 저장소를 모니터링하는 의도적인 공격자는 몇 초 만에 해당 취약점을 악용할 수 있습니다.

1.2 보안 금지 조치(Security embargoes)는 더 이상 효과적이지 않다

전통적인 보안 프로세스는 버그를 금지하고, 그 세부 정보의 기밀성이 사용자들을 보호한다고 가정합니다. 하지만 오늘날 에이전트가 필요한 것은 단지 광범위한 검색 방향일 뿐이며, 스스로 연구할 수 있습니다. Fang 등은 CVE 설명(CVE description)을 제공받았을 때 GPT-4 에이전트로 15개의 취약점 벤치마크 중 87%를 악용했으며, 설명 없이는 단지 7%에 그쳤다고 발견했습니다.

2년이 지난 지금, 악용까지 걸리는 평균 시간(mean time to exploit)은 -7일입니다. 다시 말해, 이제는 패치보다 악용이 선행됩니다! 같은 지표가 2018-19년에는 약 63일이었으며, 2024년에 0을 돌파했습니다. 간단히 검색해보면 요즘 비슷한 사례들이 많이 있습니다... marimo의 CVE-2026-39987은 공개적인 개념 증명(proof-of-concept)이 존재하지 않았음에도 불구하고 권고 사항에서 첫 악용 시도로까지 단 9시간 만에 진행되었습니다. Langflow의 CVE-2026-33017은 20시간이 걸렸습니다. 우리는 자동화된 취약점 생성의 루비콘강을 건넌 것 같습니다...

2 현재 버그 경제학(bugonomics)은 오픈 소스(OSS) 유지 관리자들에게 불리한가?

제 생각에는 우리의 보안 프로세스가 어느 정도 역전되어야 할 것 같습니다. 단 한 명의 사람이 이슈 클래스를 검색하는 것만으로도 (이것은 메일링 리스트 질문, 고아 브랜치(orphan branch)의 이상한 커밋, 또는 컨텍스트 유출일 수 있습니다) 다른 사람의 에이전트를 경고하고 그들이 악용 코드를 얻게 하기에 충분합니다. 정말 놀랍습니다.

2026년 5월에 발표된 논문은 '버그 경제학(bugonomics)'이라는 용어를 만들었으며, 병목 현상이 '방어자 구제 처리 처리량(defender remediation throughput)'으로 이동했다고 주장합니다. LLM은 즐겁게 취약점을 생성하고 있지만, 유지 관리자의 검증, 분류 및 릴리스 속도가 정체되어 있기 때문에 우리가 이에 방어할 수 있는 능력은 반드시 향상되고 있지는 않습니다. 이는 불행하게도 제가 OSS 유지 관리자라는 자리에서 보는 견해와 일치합니다:

문제는 최첨단 모델(frontier models), 오픈 가중치 모델(open-weight models), 또는 프로그램 분석 중 어느 것이 '승리'하느냐가 아닙니다. 문제는 희소한 검증, 우선순위 지정 및 출시 역량을 기계적인 검색과 보고서 초안 작성에 쏟는 대신, 지속 가능한 수정 작업으로 조정하는 방법입니다. 핵심 방어 기회는 기술 부채(technical debt) 해결입니다. 이는 의미론 기반(semantics-grounded), 도구 검증(tool-verified), 모델 지원 워크플로우로, 유지 관리자들이 보안 관련 결함을 내일의 악용 취약점(exploited vulnerabilities)이 되기 전에 찾고, 검증하고, 우선순위 지정하고, 수정하는 데 도움을 줍니다. -- Demystifying the Mythos or Disrupting Bugonomics?, Pesoli et al, 2026

그리고 왜 유지 관리자의 역량은 정체되어 있을까요? Mythos와 같은 최첨단 에이전트에 접근할 수 없다는 것이 명백한 이유 중 하나이지만, 회귀(regressions)를 일으키지 않는 보안 패치를 엔지니어링하는 것 자체가 근본적으로 더 많은 작업이기 때문이기도 합니다.

3 그래서 우리는 무엇을 할 수 있을까요?

우리는 분명히 상당히 빠르게 적응해야 합니다. 저는 현재의 수동 분류(manual triage) 프로세스가 사라져야 한다고 생각하지 않지만, Fable이 출시된 이후로 지속 불가능한 활동 증가를 목격했습니다. 들어오는 거대한 물줄기(firehose) 중 얼마나 많은 부분이 기계적으로 생성되었는지 파악하기 시작했을 뿐이지만, 분명히 엄청난 양입니다.

구글 같은 대형 엔지니어링 회사들은 수정 사항이 크롬 코드 저장소에서 수정되는 것보다 우선하여 사용자에게 직접 도달하도록 소프트웨어에 마이크로 업데이트를 구축해 왔습니다. 우리는 Docker나 OCaml에서는 그러한 종류의 사치를 누릴 수 없습니다. 왜냐하면 우리의 소프트웨어가 사용되는 엔드포인트를 우리가 통제하지 못하기 때문입니다. Docker Desktop을 제외하고, 다운스트림 배포판들은 자신들만의 시간표와 조건에 따라 OSS를 재패키징하는 것이 당연합니다.

OCaml 같은 소규모 프로젝트의 경우, 최첨단 모델에 접근하는 것 자체가 힘든 일입니다. 서구권 모델들은 보안 장치를 갖추고 있어 상업적으로 이용 가능한 모델을 사용할 수 없습니다. Project Glasswing은 중요 인프라 운영자, 클라우드 및 금융 제공업체, Linux Foundation 등 15개국 150개 조직으로 확장했지만, 여전히 '소규모' 관리자들은 접근할 수 없습니다. 지난 4월에는 이것이 해로운지 주저했지만, 오늘날 보니 상당히 심각한 상황입니다.

3.1 초비밀 사설 패치 개발

첫 번째 해결책은 AI의 손길이 닿지 않는 곳에서 수정 사항을 개발하는 것입니다. GitHub의 임시 비공개 포크(private forks)가 명목상 이를 수행하지만, 우리에게는 그다지 효과적이지 않습니다.

첫째, GitHub는 '취약점에 대한 정보를 안전하게 유지하기 위해 CI를 포함한 통합 기능이 임시 비공개 포크에 접근할 수 없습니다'라고 제한하는데, 이는 관리자를 우리의 CI 결과라는 생명줄로부터 즉시 단절시킵니다. 둘째, 포크에는 단 하나의 PR만 병합될 수 있는데, 이는 종종 여러 저장소에 걸쳐 발생하는 문제에는 적합하지 않습니다. 또한 검토자(reviewer)는 관리자에 의해 한 명씩 등록되어야 하는데, 오픈 소스 환경에서는 검토자들이 누가 가능한지에 따라 임시방편적으로 참여하는 경우가 많습니다 (특히 8월에는 더욱 그렇습니다!).

하지만 더 넓은 관점에서 볼 때, 이것은 잘못된 누수를 막고 있습니다. 패치를 비밀로 유지하는 것보다도 문제에 대한 설명이 공격자에게 새어 나가지 않도록 정확히 올바른 사람들에게 전달되도록 보장하는 것이 훨씬 중요합니다.

우리는 오픈 소스(OSS) 내에서 강력한 토론 인프라를 갖추고 있지 않습니다. 왜냐하면 이것은 다양한 종단 간 암호화된 플랫폼(저희는 Matrix를 사용합니다)을 통해 공유되거나, Discord나 Slack과 같은 매우 취약한 공유 인프라를 통해서만 공유되기 때문입니다. 우리는 특정 프로젝트 환경에서 누가 좋은 사람이고 나쁜 사람인지 구별할 수 있는 일종의 신뢰 네트워크(web-of-trust)가 필요합니다.

3.2 금지 기간 없이 지속적으로 배포하기

또 다른 방법은 공개적으로 문제를 신속하게 수정하고, 지속적으로 배포하며, 더 나은 자동화를 통해 릴리스 경로를 개선하는 것입니다.

Chrome과 같은 대형 프로젝트는 주간 보안 업데이트, 주당 두 번의 릴리스(!), 그리고 재시작 없이 백그라운드 프로세스를 업데이트된 바이너리로 교체하는 동적 패치(dynamic patching)를 통해 이것이 가능하다는 것을 보여줍니다. 이는 완전히 새로운 기술은 아닙니다. 저는 15년 전에 live ksplice Linux 패치와 Xen을 통합하는 방안을 검토한 적이 있습니다. 리눅스 커널 역시 가능한 한 빨리 수정 사항을 배포하며, 최대 7일, 예외적으로는 14일을 지연합니다.

하지만 소프트웨어 패키징이 우리의 주요 장애물입니다. Chrome은 하나의 바이너리 아티팩트를 배포하는 비교적 쉬운 작업을 수행하지만, 오픈소스(OSS)는 종종 다양한 다운스트림 제품에 임베드되는 수많은 라이브러리로 구성됩니다. 따라서 이를 위해서는 다음이 필요합니다:

• 서로 다른 라이브러리가 궁극적으로 어디에 임베드되었는지 발견할 수 있는 훨씬 더 나은 크로스 에코시스템 패키지 관리(cross-ecosystem package management).
• 분류 작업(triage)을 돕는 더 나은 스캐닝 도구; Andrew Nesbitt이 지난 몇 달 동안 Scrutineer를 사용하여 바로 이런 작업을 수행해 왔습니다. Thomas Gazagnaire와 저는 보안 차단 없이 합리적인 프론티어 모델에 접근할 수 있다는 전제 하에, 우리의 OCaml 코드에 이를 적용하는 방안을 논의해 왔습니다.
• 지원되는 플랫폼 스펙트럼 전체에서 작동하며 오탐(false positives)이 없는 더욱 강력한 품질 관리 인프라. 리눅스에서 CI를 실행하는 것은 비교적 쉽지만, OpenBSD, FreeBSD, macOS, 그리고 RISC-V와 같은 일부 아키텍처에서는 이야기가 다릅니다.

3.3 프로토콜 계층에서의 사전 예방 보호(Proactive protection at the protocol layer)

저는 또한 우리가 라이브러리를 사용하여 엔드포인트를 보호하기 위해 동적으로 방어 체계를 구축할 수 있는 방법에 대해 더 급진적인 생각을 해왔습니다.
만약 업스트림 패치 수정 사항이 항상 익스플로잇(exploit)보다 뒤처질 것이라고 받아들인다면, 우리는 반드시 그보다 앞서 나갈 무언가를 배치해야 합니다.

예를 들어, 오늘 수정된 cohttp 버그에는 간단한 완화책이 있습니다. 요청 URL에서 퍼센트 인코딩된 경로 구분자(path separators)만 정규화하면 됩니다. 이 규칙은 보고서가 도착하는 즉시 구현할 수 있었고, 전체 패치가 검토, 테스트 및 패키징을 거치는 동안에도 배포할 수 있었습니다. 가상 패치(Virtual patching)는 요즘 클라우드 인프라에서 일상적인 일이 되었습니다. Cloudflare는 2021년에 Log4shell에 대한 관리형 규칙(managed rules)을 배포했습니다.

하지만 오픈 소스(open source)는 상업용 CDN 외부에서 이러한 규칙을 배포할 메커니즘이 부족합니다. 이것이 바로 저희의 인터넷 생태학 논문에서 제시한 antibotty 네트워크 아이디어가 전 세계 인터넷 주변에 더 많은 소프트웨어 다양성을 통해 해결하려는 문제입니다. 취약점에 대해 듣고 몇 초 안에 즉각적인 인프라에서 대응할 수 있는, 지역적이고 빠르게 확산되는 방어 체계를 어떻게 구축할 수 있을까요?

4 후속 연구 (Some research followups)

단기적으로는 이 세 가지 옵션의 조합이 필요하다고 생각합니다. OSS 기여자들을 위한 가벼운 웹 오브 트러스트(web-of-trust) (예전 명망 높은 Advogato처럼), 그리고 소중한 인간 기여자들이 압도되지 않도록 OSS 패키징 및 지속적인 롤아웃과 분류(triage) 메커니즘에 더 많은 초점을 맞추는 것입니다.

또한, 다음 달 케임브리지로 오는 분들 중 프로젝트를 찾는 분들을 위해 몇 가지 새로운 MPhil 연구 아이디어를 게시했습니다.

Project Glasswing 팀에서 듣고 계신 분이 있다면, OCaml 팀은 지금 접근 권한이 필요합니다 :-)

(cohttp 수정 작업은 혼자만의 노력이 아니었습니다. Sapphire Livingstone이 문제를 발견하고 보고했으며, 수정 작업을 안내하고 함께 해결책을 개발했습니다. Michael Dales, Török Edwin, Patrick Ferris가 패치를 검토했고, Hannes Mehnert가 권고 사항을 조율했으며, Thomas Gazagnaire는 더 광범위한 트리아지(triage) 문제에 대해 고민해 왔습니다. 모두 감사합니다! 버그노믹스(bugonomics)가 우리에게 불리할지 모르지만, 우리는 이 고개를 넘을 것입니다.)