패치 공개 10분 만에 탐색이 시작됐다: AI 에이전트가 좁힌 보안 대응 창

오픈소스 보안 대응에는 오랫동안 암묵적인 시간표가 있었다. 취약점을 비공개로 신고하고, 유지관리자가 수정안을 만든 뒤, 리뷰와 테스트를 거쳐 릴리스한다. 세부 내용이 공개되기 전까지 공격자가 같은 문제를 찾아내지 못하리라는 가정이 이 시간표를 지탱했다.

2026년 8월 OCaml 컴파일러 핵심 유지관리자인 Anil Madhavapeddy가 공개한 사례는 이 가정이 빠르게 약해지고 있음을 보여준다. OCaml HTTP 라이브러리 cohttp의 경로 순회 취약점을 수정하기 위해 공개 PR을 열었더니, 약 10분 뒤 자신의 웹 서버에 같은 버그 패턴을 찾는 탐색 요청이 들어오기 시작했다는 것이다.

더 불편한 사실은 유지관리자 자신도 대략적인 취약점 종류만 알려준 상태에서 코딩 에이전트로 관련 문제를 찾고, 로컬 서버를 확인하는 코드를 1분 안에 만들 수 있었다는 점이다. 공격자가 패치의 세부 diff를 완전히 이해할 때까지 기다릴 필요가 없다. “경로 정규화 근처에 문제가 있다”는 소문만으로도 에이전트가 저장소를 검색하고 후보를 좁히며 시험할 수 있다.

Simon Willison은 이 사례를 소개하며 이제는 버그에 대한 소문만으로도 익스플로잇 탐색이 시작될 수 있다고 요약했다. 이 글은 Simon의 짧은 소개를 문장별로 옮긴 번역본이 아니다. Anil의 원문, 공식 OCaml 보안 공지와 수정 PR, rclone 유지관리자의 운영 경험, 관련 연구를 대조해 오픈소스 보안 프로세스가 어디서 막히는지 재구성한 한국어 해설이다.

cohttp 취약점에서 실제로 확인된 시간표

공식 OSV 기록과 GitHub 자료를 대조하면 사건의 공개 시간표는 다음과 같다.

• 8월 11일 — 취약점이 security@ocaml.org로 비공개 신고됐다.
• 8월 14일 11:16 UTC — 수정 PR cohttp#1145가 공개됐다.
• 공개 약 10분 뒤 — Anil은 자신의 웹 서버에서 percent-encoded 경로 순회 패턴을 찾는 탐색 요청을 관찰했다고 보고했다.
• 8월 20일 09:58 UTC — 수정 PR이 병합됐다.
• 8월 20일 17:15 UTC — 수정 버전 cohttp 6.3.0이 공개됐다.

OSV에 등록된 OSEC-2026-16은 URI 경로를 percent decoding하기 전에 정규화하면서 인코딩된 구분자가 정규화 단계를 우회할 수 있었던 경로 순회 문제다. 영향을 받은 버전은 cohttp 6.3.0 미만으로 기록돼 있다.

외부 탐색 요청이 실제로 AI가 생성한 것인지는 공개 로그만으로 독립 확인할 수 없다. Anil도 이를 자동화된 감시자가 공개 저장소를 지켜본 정황으로 해석한다. 따라서 “AI 공격자가 10분 만에 침해에 성공했다”고 표현하면 과장이다. 확인된 사실은 공개 PR 약 10분 뒤 정확한 버그 패턴을 겨냥한 탐색 요청이 관찰됐다는 것이다.

AI 에이전트는 완성된 익스플로잇 대신 짧은 방향 정보만으로 검색을 시작할 수 있다. cohttp 시간은 유지관리자의 직접 관찰, rclone 수치는 유지관리자 댓글 기준이다. 출처: Anil Madhavapeddy.

패치 diff가 없어도 대략적인 방향이 검색 키가 된다

Anil은 수정안을 자세히 보기 전에 자신의 에이전트에게 관련 코드에서 경로 정규화 문제를 조사하게 했다. Claude Fable은 보안 정책으로 작업을 거부했지만, DeepSeek V4 Pro는 관련된 여러 문제를 독립적으로 찾아냈다고 한다. 로컬 실행 환경을 확인하는 코드도 1분 이내에 만들었다.

이 사례의 핵심은 특정 모델의 승패가 아니다. 에이전트가 다음 작업을 하나의 루프로 묶을 수 있다는 점이다.

1. 공개 저장소에서 의심 영역을 찾는다.
2. 호출 경로와 입력 처리를 따라간다.
3. 취약점 가설을 만든다.
4. 로컬 환경에서 빠르게 시험한다.
5. 실패하면 다른 변형을 생성한다.

예전에는 “취약점 종류를 안다”와 “작동하는 공격 경로를 찾는다” 사이에 상당한 전문성과 시간이 필요했다. 코딩 에이전트는 그 사이의 기계적인 검색·코드 읽기·시험 비용을 크게 낮춘다. 패치가 비공개여도 메일링 리스트 질문, 브랜치 이름, 실패한 CI 로그, 커밋 메시지처럼 문제의 방향을 알려주는 작은 단서가 검색 시작점이 될 수 있다.

87%와 7%가 보여주는 설명의 가치

Anil이 인용한 2024년 연구 LLM Agents can Autonomously Exploit One-day Vulnerabilities는 실제 시스템의 15개 one-day 취약점으로 GPT-4 에이전트를 평가했다.

• CVE 설명을 제공했을 때: 87%에서 성공
• CVE 설명이 없었을 때: 7%에서 성공

이 결과를 오늘날 모든 모델의 절대 성능으로 일반화하면 안 된다. 표본은 15개이고 2024년 당시 GPT-4 기반 평가다. 다른 모델·도구·샌드박스에서는 결과가 달라질 수 있다.

그럼에도 차이는 중요한 메커니즘을 보여준다. CVE 설명은 완성된 익스플로잇이 아니지만, 검색 공간을 크게 줄여주는 방향 정보다. 모델 능력이 향상될수록 필요한 힌트가 완전한 CVE 설명에서 짧은 PR 제목이나 “이 모듈의 경로 처리에 문제가 있다”는 소문으로 줄어들 수 있다.

보안 엠바고의 보호 대상이 바뀐다

전통적인 엠바고는 취약점의 세부 정보를 소수에게만 공유하면 패치할 시간을 벌 수 있다는 전제에 기대고 있다. 하지만 에이전트가 넓은 방향만으로 문제를 재발견할 수 있다면 패치 파일만 숨겨서는 부족하다.

새로운 누출 지점은 훨씬 넓다.

• 공개 이슈와 PR 제목
• 이상한 브랜치나 커밋 메시지
• 보안 관련 메일링 리스트 질문
• 패치 때문에 바뀐 테스트와 CI 실패
• 여러 저장소에 동시에 나타난 유사한 수정
• 공개 패키지 릴리스 직전의 메타데이터 변화

그렇다고 모든 보안 논의를 영구히 폐쇄해야 한다는 뜻은 아니다. 오픈소스는 공개 리뷰와 다양한 환경의 테스트가 품질을 만든다. 문제는 공개 시점을 “패치를 논의하기 시작하는 시점”이 아니라 “사용자에게 실제 방어가 도달할 준비가 된 시점”에 더 가깝게 맞춰야 한다는 데 있다.

발견 속도보다 유지관리자의 처리량이 병목이다

rclone 유지관리자 Nick Craig-Wood는 Hacker News 댓글에서 자신의 프로젝트가 겪는 변화를 수치로 설명했다.

• 프로젝트 첫 10년 동안 GitHub 보안 제보 약 20건
• 최근 한 달 동안 40건 초과
• 최근 제보의 약 75%는 살펴볼 만한 실제 문제를 포함
• GitHub CVE 할당 대기 시간이 과거 2~3일에서 최근 3~4주로 증가

첫 10년과 한 달은 기간이 다르므로 단순 막대그래프로 성능처럼 비교할 수는 없다. 하지만 유지관리자가 체감하는 유입 속도의 변화는 분명하다. AI가 보고서 초안과 수정 후보를 만드는 데 도움을 줘도, 최종 검증·회귀 테스트·브랜치 관리·릴리스·하위 배포판 조율은 여전히 사람의 책임이다.

허위 양성만 늘어난 문제로 치부하기도 어렵다. Nick의 관찰에서는 약 75%가 검토할 신호를 담고 있었다. 이는 유지관리자가 보고서를 무시할 수 없으면서도 처리량을 쉽게 늘릴 수 없는 상태를 만든다.

취약점 발견 비용은 자동화되지만, 안전한 수정의 책임은 자동으로 줄지 않는다.

공개 저장소 감시를 막는 것만으로 충분하지 않다

공격자가 공개 PR을 감시한다면 저장소를 비공개로 만들면 해결될 것처럼 보인다. 실제로 GitHub 보안 권고의 임시 비공개 포크는 중요한 도구다. 그러나 Anil은 현실적인 제약을 지적한다.

• 보안을 위해 통합과 CI 접근이 제한될 수 있다.
• 여러 저장소에 걸친 수정은 하나의 비공개 PR로 다루기 어렵다.
• 오픈소스 리뷰어는 고정된 조직 구성원이 아니어서 접근 권한 조율이 느리다.
• Slack·Discord 등 공유 커뮤니케이션에서 문제의 방향이 먼저 새어 나갈 수 있다.

따라서 “패치 저장소를 숨긴다”와 “문제 설명이 필요한 사람에게만 전달된다”를 별도로 설계해야 한다. 저장소 접근 통제만 강화하고 신고·리뷰 채널이 넓게 열려 있으면 소문은 다른 경로로 유출될 수 있다.

대응 1: 신뢰할 수 있는 비공개 조정 채널

작은 프로젝트도 보안 신고자·유지관리자·배포판 담당자를 빠르게 연결할 수 있는 최소한의 신뢰망이 필요하다.

• 암호화된 보안 신고 채널
• 프로젝트별 검증된 리뷰어 목록
• 접근 권한의 만료와 감사 기록
• 여러 저장소를 묶는 비공개 조정 공간
• 공개 전에 패키지·배포판 담당자에게 전달하는 규칙

중요한 것은 비밀을 오래 유지하는 것이 아니라, 수정과 배포를 준비할 만큼만 정확한 사람에게 전달하는 것이다.

대응 2: 패치 공개와 릴리스 사이를 줄인다

패치 PR이 공개된 뒤 릴리스까지 며칠이 걸린다면 그 기간이 공격자의 자동 탐색 창이 된다. 가능한 프로젝트에서는 다음 준비가 필요하다.

• 보안 수정 전용 자동 회귀 테스트
• 여러 플랫폼의 사전 빌드와 재현 가능한 패키징
• 서명된 릴리스 자동화
• 패치 병합과 권고·패키지 공개의 원자적 실행
• 하위 배포판과의 기계 판독 가능한 영향 범위 공유

무조건 빠르게 병합하라는 뜻은 아니다. 보안 패치가 기능을 깨뜨리면 사용자가 업데이트를 회피할 수 있다. 목표는 리뷰를 생략하는 것이 아니라 반복적인 빌드·테스트·배포 단계를 미리 자동화해 사람이 판단해야 할 부분에 시간을 쓰는 것이다.

대응 3: 완전한 수정 전에 임시 완화를 배포한다

라이브러리 수정과 하위 제품 배포가 늦어질 수밖에 없다면 프로토콜·게이트웨이·WAF 계층의 임시 규칙으로 시간을 벌 수 있다.

cohttp 사례에서는 인코딩된 경로 구분자를 정규화하는 완화 규칙을 전체 라이브러리 수정과 별도로 적용할 수 있었다. 이는 장기 수정의 대체물이 아니다. 우회 가능성과 허위 양성을 검토하고, 정식 패치가 배포되면 제거해야 한다.

하지만 공격 탐색이 분 단위로 시작될 수 있다면, “완벽한 패키지가 나올 때까지 아무 방어도 배포하지 않는다”는 전략보다 제한적이고 되돌릴 수 있는 임시 완화가 유용할 수 있다.

AI 방어 도구에도 같은 접근권 문제가 있다

Anil의 실험에서 한 모델은 보안 정책으로 조사를 거부했고 다른 모델은 수행했다. 공격자가 제약이 적은 모델을 사용할 수 있는데 작은 오픈소스 프로젝트는 강한 방어용 모델에 접근하지 못한다면 비대칭이 커진다.

그렇다고 모든 유지관리자에게 무제한 공격 능력을 제공하는 것이 답은 아니다. 필요한 것은 다음과 같은 제한된 방어 경로다.

• 프로젝트 소유권이나 유지관리자 신원을 확인한 접근
• 격리된 복제 환경과 네트워크 제한
• 대상 저장소·취약점 범위를 명시한 작업 계약
• 생성된 시험 코드의 외부 전송 차단
• 모든 도구 호출과 결과의 감사 로그

방어자가 에이전트를 쓰지 못하도록 막는 것보다, 권한과 대상이 좁은 검증 환경을 제공하는 편이 현실적이다.

관찰과 일반화를 구분해야 한다

이번 사례에서 직접 확인된 것과 아직 가설인 것을 구분할 필요가 있다.

직접 확인된 기록

• cohttp 경로 순회 취약점의 신고·PR·병합·릴리스 날짜
• Anil이 자신의 에이전트로 로컬 시험 코드를 1분 이내 생성했다는 유지관리자 보고
• 공개 PR 약 10분 뒤 같은 패턴의 탐색 요청을 관찰했다는 유지관리자 보고
• rclone 유지관리자가 밝힌 보안 제보 수와 검토 신호 비율
• 15개 취약점 벤치마크에서 CVE 설명 유무에 따른 87%와 7% 결과

아직 단정할 수 없는 것

• cohttp를 탐색한 외부 요청이 어떤 모델이나 조직에서 생성됐는지
• 탐색 요청이 실제 침해 성공으로 이어졌는지
• 모든 오픈소스 프로젝트가 같은 속도로 공격받는지
• 공개 보안 논의보다 완전 비공개 개발이 항상 더 안전한지

이 구분을 유지해야 공포를 과장하지 않으면서도 프로세스 변화의 필요성을 놓치지 않을 수 있다.

결론: 패치가 아니라 방어가 사용자에게 도달하는 시간을 줄여야 한다

AI 코딩 에이전트가 바꾼 것은 취약점 발견 속도만이 아니다. 작은 단서에서 검색 방향을 얻고, 저장소를 읽고, 가설을 만들고, 시험 코드를 반복하는 전체 비용이 낮아졌다.

이 환경에서 “패치 세부 내용은 아직 공개하지 않았다”는 사실만으로 안전한 시간을 확보하기 어렵다. 오픈소스 프로젝트가 줄여야 할 핵심 지표는 신고에서 PR까지의 시간 하나가 아니라 다음 전체 구간이다.

취약점 인지 → 신뢰할 수 있는 조정 → 검증된 수정 → 임시 완화 → 사용자에게 실제 배포

공개 개발을 포기하는 것이 답은 아니다. 공개되는 순간 방어도 함께 움직일 수 있도록 비공개 조정, 자동 테스트, 연속 릴리스, 하위 배포판 통지, 프로토콜 계층 완화를 하나의 흐름으로 연결해야 한다.

버그에 대한 소문이 공격자의 검색 키가 될 수 있다면, 방어자의 목표는 소문을 영원히 숨기는 것이 아니라 소문이 퍼지기 전에 보호 조치가 더 빠르게 도착하게 만드는 것이다.

원문 및 출처

• Simon Willison, Just a rumour of a bug is enough to find a security exploit these days
• Anil Madhavapeddy, Just a rumour of a bug is enough to find a security exploit these days
• OSV, OSEC-2026-16
• mirage/ocaml-cohttp PR #1145
• Nick Craig-Wood의 Hacker News 댓글
• Fang et al., LLM Agents can Autonomously Exploit One-day Vulnerabilities