수정 PR을 공개한 지 10분 만에 같은 버그를 노린 탐침이 서버에 들어왔다. 공격은 보안 권고를 기다리지 않지만, Dependabot 보안 업데이트는 권고가 떠야 열린다. 권고 없이 나온 패치가 기본 3일 쿨다운에 걸리는 의존성을 이번 주에 골라낸다.
보안 패치 기한을 정할 때 기준점은 대개 CVE 번호나 GitHub 보안 권고가 게시된 날이다. 그날을 0일로 놓고 심각도별 반영 기한을 정한다. 권고 전에는 취약점을 아는 사람이 신고자와 메인테이너뿐이라는 전제가 깔려 있다.
InfoQ 10월 3일 보도는 이 0일이 실제 공격 시작보다 늦을 수 있다는 메인테이너들의 경험을 모았다. 그렇다면 0일을 어디에 둘지, 우리 쪽 자동화가 그 0일에 맞춰 움직이는지를 다시 봐야 한다.
공격자는 권고문보다 수정 PR의 diff를 먼저 읽는다
케임브리지대 교수이자 OCaml 컴파일러 핵심 메인테이너인 Anil Madhavapeddy는 8월 22일 노트에 cohttp 6.3.0의 경로 탐색(path traversal) 취약점(OSEC-2026-16)을 고친 과정을 적었다. 수정 PR을 GitHub에 공개로 열었고, 약 10분 뒤 자기 웹사이트 로그에 퍼센트 인코딩된 경로 탐색 문자열을 보내는 탐침이 찍혔다. 탐침은 릴리스보다 먼저 왔고, 평소 1~2주 걸리던 릴리스를 그는 같은 날 냈다. 그는 로컬에서 익스플로잇을 직접 만드는 데 1분이 걸렸으니, 자동화된 공격에 10분은 오히려 길다고 썼다.
이 속도는 2024년 Fang 등의 논문으로 설명된다. GPT-4 에이전트는 15개 취약점 벤치마크에서 CVE 설명을 받았을 때 87%를 익스플로잇했고, 설명이 없을 때는 7%에 그쳤다. 성공률을 가른 것은 어디가 어떻게 틀렸는지 알려주는 텍스트였다. 수정 PR의 diff는 취약한 함수와 고친 조건을 줄 단위로 보여준다. CVE 설명보다 정보가 적지 않다.
권고문은 더 이상 공격자가 처음 읽는 문서가 아니다.
InfoQ가 인용한 Chainguard의 Adrian Mouat는 "사용자는 위험에 놓이는데 할 수 있는 일이 없다"고 했다. 수정 PR이 열린 뒤 릴리스가 나오기 전까지는 올릴 버전 자체가 없다. 에이전트가 뚫은 구멍은 전부 재래식이었다에서처럼 바뀐 것은 취약점의 종류가 아니라 공개에서 악용까지의 시간이다.
엠바고는 짧아지고, 권고를 쓸 메인테이너는 신고 처리에 묶인다
메인테이너 쪽은 비공개 기간을 줄이고 있다. QEMU 보안 절차 문서는 보안 감사에 AI·LLM 에이전트가 널리 쓰여 자동화 도구발 신고는 단기간에 여러 번 재발견될 가능성이 높다며, 심각도가 높지 않으면 임의의 엠바고 요청을 거절한다.
신고 물량도 늘었다. rclone의 Nick Craig-Wood는 첫 10년 동안 GitHub로 받은 보안 신고가 약 20건이었는데 지난 한 달에만 40건이 넘었다고 했다. Tom's Hardware 보도에 따르면 Google은 10월 1일부터 오픈소스 취약점 보상 프로그램(OSS VRP)의 제품 취약점 보고 접수를 멈췄고, 이유로 AI 기반 무효 보고의 급증을 들었다.
Madhavapeddy는 검증·우선순위 판단·릴리스 역량을 가장 모자란 자원으로 봤다. 권고문 작성과 CVE 발급도 밀린 신고를 처리하는 같은 메인테이너의 몫이라, 권고가 릴리스보다 늦거나 아예 없는 패치가 나올 수 있다.
Dependabot은 권고가 붙은 패치만 바로 PR로 연다
기업 쪽 자동화는 여기서 어긋난다. GitHub 7월 14일 공지 이후 Dependabot 버전 업데이트는 새 릴리스가 레지스트리에 올라온 뒤 최소 3일을 기다렸다가 PR을 연다. github.com의 모든 생태계에 설정 없이 적용됐고, GitHub Enterprise Server는 3.23부터다. 보안 업데이트는 이 대기에서 빠져 즉시 열린다.
남는 문제는 보안 업데이트의 출발 조건이다. Dependabot 보안 업데이트 문서에 따르면 보안 업데이트는 Dependabot 알림이 떠야 시작되고, 알림은 게시된 GitHub 보안 권고를 근거로 온다.
| 업스트림 상태 | Dependabot 경로 | PR이 열리는 시점 |
|---|---|---|
| 수정 PR 공개, 릴리스 전 | 없음 | 없음 (탐침은 이미 시작) |
| 릴리스 + 보안 권고 게시 | 보안 업데이트 | 알림 직후 |
| 릴리스, 권고 없음 | 버전 업데이트 | 릴리스 3일 뒤 (기본값) |
| 릴리스, 권고 없음, dependabot.yml 없음 | 없음 | 사람이 확인할 때까지 |
쿨다운을 0으로 끄는 것도 답이 아니다. 3일 대기는 오염된 릴리스가 걸러지기 전에 빌드로 들어오는 공급망 공격을 막으려고 들어갔다. Dependabot 옵션 문서의 cooldown은 semver-patch-days로 패치 버전만 대기를 줄이거나, include·exclude(각 최대 150개, 와일드카드 허용)로 의존성마다 다르게 걸 수 있다. 외부 요청을 직접 받는 소수 의존성만 대기를 줄이고 나머지는 3일을 유지해야 두 위험을 함께 다룬다.
가져갈 것
- 운영 저장소마다
.github/dependabot.yml이 있어 버전 업데이트가 켜져 있는가? -
cooldown을 적지 않은 저장소에서 패치 릴리스가 3일 뒤 PR로 온다는 사실을 보안 담당자가 알고 있는가? - 외부 요청을 직접 받는 HTTP 파서·인증·직렬화 라이브러리 목록을 뽑아
semver-patch-days단축이나exclude적용 여부를 정했는가? - 업스트림 보안 수정 PR이 공개된 날, 릴리스 전까지 쓸 WAF 차단 규칙과 즉시 회전할 단기 자격 증명이 있는가?
- 직접 관리하는 오픈소스가 있다면 보안 수정을 공개 PR보다 비공개 논의에서 먼저 만드는가?
안 되는 경우
- 10분은 Madhavapeddy 한 사람의 서버 로그 사례다. 다른 생태계에서도 같은 속도인지는 소스가 밝히지 않았다.
- 87%는 2024년 GPT-4 에이전트를 15개 취약점에 돌린 결과다. 수정 PR diff만 줬을 때의 성공률은 측정되지 않았다.
- 의존성을 OS 패키지나 상용 컨테이너 이미지로 받는 조직은 배포판의 보안 공지 주기를 따르므로 위 표가 맞지 않는다.
- 권고가 릴리스보다 얼마나 늦게 붙는지, 권고 없이 나가는 보안 패치가 얼마나 되는지는 어느 소스도 집계하지 않았다.
이번 주에 바꿀 것은 기한의 기준점이다. 외부 요청을 직접 받는 의존성만큼은 보안 권고 게시일이 아니라 업스트림 수정 릴리스가 나온 날을 0일로 센다. AX 전환을 검토 중이라면 운영 기준 전반에도 같은 질문을 던질 만하다: 공격자도 에이전트를 쓴다면 지금 기한은 며칠이어야 하는가. 사업영역 →