버그 소문만 흘러도 10분 만에 공격 코드가 나온다: AI가 바꿔버린 보안 엠바고의 시대
한 줄 요약
OCaml의 웹 라이브러리 cohttp 6.3.0에서 경로 순회(path traversal) 취약점을 수정하는 PR을 공개하자, 놀랍게도 약 10분 만에 실제 서버 로그에 동일한 패턴을 노리는 탐색 요청이 찍혔습니다. AI 에이전트에게 "경로 정규화에 문제가 있는 것 같다"는 정도의 힌트만 줬을 뿐인데, 1분 안에 실제로 작동하는 공격 코드가 만들어졌고요. 이제 취약점의 '자세한 설명'이 없어도 AI가 알아서 코드를 뒤져 익스플로잇을 완성하는 시대가 열리면서, 수십 년간 OSS 생태계를 지탱해온 '비공개 보안 엠바고' 전략 자체가 흔들리고 있습니다.
무슨 일이 있었나: cohttp 사건의 타임라인
- cohttp 6.3.0의 경로 순회 취약점은 Jane Street의 비공개 Slack 채널을 통해 제보됐고, 이를 처음 발견한 것도 AI 모델(Claude Fable)이었습니다.
- 연구팀이 취약점 조사를 여러 AI 모델에 맡겨보니 반응이 갈렸습니다. Fable은 보안 제약과 접근 권한 부족으로 조사를 거절한 반면, DeepSeek V4 Pro는 관련 문제를 스스로 여러 개 찾아냈고, 로컬 서버를 대상으로 한 익스플로잇까지 1분 안에 생성했습니다.
- 수정 방향을 조율해 실제 패치 PR(cohttp#1145)을 공개하자, 10분 만에 percent-encoded 경로 순회 시퀀스를 노리는 요청이 감지됐습니다. 누군가(혹은 어떤 자동화 시스템)가 공개 저장소를 실시간으로 감시하고 있다는 뜻이죠.
왜 문제인가: 보안 엠바고의 전제가 무너지고 있다
기존 보안 엠바고는 "취약점의 자세한 내용을 숨기면 사용자를 보호할 수 있다"는 전제 위에 서 있었습니다. 그런데 이제 AI 에이전트는 대략적인 방향만 주어져도 스스로 코드를 파고들어 공격법을 재구성할 수 있습니다.
실제 연구 수치도 이를 뒷받침합니다.
- Fang et al. 연구에서 GPT-4 에이전트는 **CVE 설명이 주어졌을 때 87%**의 취약점을 악용했지만, 설명이 없어도 7%는 여전히 악용에 성공했습니다.
- 2018~2019년에는 취약점 공개 후 실제 악용까지 평균 63일이 걸렸는데, 2024년에는 이 수치가 0일 아래로 떨어졌고, 2026년 현재는 평균 -7일, 즉 패치가 나오기도 전에 공격이 먼저 시작되는 상황입니다.
- 최근 사례로 marimo의 CVE-2026-39987은 공개된 개념 증명(PoC)조차 없었는데도 권고 발행 후 9시간 만에 첫 공격 시도가 있었고, Langflow의 CVE-2026-33017은 20시간 만에 공격이 발생했습니다.
진짜 병목은 '공격 속도'가 아니라 '방어자의 처리량'
2026년 5월 발표된 논문 *Demystifying the Mythos or Disrupting Bugonomics?*는 이 현상을 **'버고노믹스(bugonomics)'**라는 용어로 정리합니다. 핵심은 이렇습니다.
LLM 덕분에 취약점 발견과 익스플로잇 생성 속도는 폭발적으로 빨라졌지만, 유지보수자가 이를 검증하고, 분류하고, 우선순위를 매기고, 릴리스하는 속도는 그대로다.
즉 병목이 '공격자가 얼마나 빠른가'에서 '방어자가 얼마나 빨리 대응할 수 있는가'로 완전히 옮겨간 것입니다. 게다가 소규모 오픈소스 프로젝트는 최첨단 보안 모델 접근권조차 제한적이고(Project Glasswing 같은 특별 프로그램은 15개국 150개 대형 조직에만 열려 있음), Fable 출시 이후로는 자동 생성된 보고서가 쏟아져 수동 분류만으로 감당하기 어려운 상황까지 왔다고 합니다.
그래서 대안은? 세 갈래 접근
글에서는 단기적으로 세 가지를 함께 밀어붙여야 한다고 제안합니다.
- 비공개 협업의 재설계 — 기존 GitHub 임시 비공개 포크는 CI 접근 불가, PR 1개 제한, 리뷰어 수동 등록 등 한계가 많습니다. 종단간 암호화된 협업 도구와 '신뢰망(web-of-trust)' 기반 참여자 검증이 필요합니다.
- 엠바고 대신 지속적 배포 — Chrome처럼 주 단위 보안 업데이트와 동적 패치를 지향하고, Linux 커널처럼 수정 후 최대 7일(예외 14일) 내 배포를 목표로 삼는 방식입니다. 다만 OSS 라이브러리는 Chrome과 달리 수많은 하위 제품에 흩어져 포함되기 때문에, 생태계 간 패키지 추적 도구(예: Andrew Nesbitt의 Scrutineer)와 다중 플랫폼 CI 인프라가 관건입니다.
- 프로토콜 계층의 가상 패치(virtual patching) — 정식 패치가 리뷰·테스트·패키징을 거치는 동안, 일단 요청 단에서 위험 패턴을 차단하는 완화 규칙을 즉시 배포하는 방식입니다. Cloudflare가 2021년 Log4Shell 때 관리형 규칙으로 대응했던 것처럼요. 문제는 상용 CDN 밖의 순수 OSS 생태계에는 이런 수단이 마땅치 않다는 점인데, 이를 메우기 위한 'antibotty network' 구상(취약점 정보를 받은 로컬 방어 시스템이 수초 안에 자체 인프라에서 대응)도 논의되고 있습니다.
마무리하며
AI가 코드 리뷰와 버그바운티를 돕는 도구를 넘어, 이제는 '침묵'만으로는 막을 수 없는 자율 정찰병이 됐다는 게 이 글의 핵심 메시지입니다. cohttp 사례처럼 패치 PR 하나만 올려도 몇 분 안에 공격 신호가 잡히는 세상에서, 오픈소스 생태계가 살아남으려면 정보를 숨기는 전략에서 빠르게 고치고 빠르게 배포하는 전략으로 무게중심을 옮겨야 할 시점인 듯합니다. 여러분의 프로젝트는 패치가 나온 뒤 며칠 만에 실제 배포까지 마칠 수 있나요? 한 번쯤 점검해볼 만한 질문입니다.