90일 공개 정책은 죽었다

• 90일 책임 공개는 LLM으로 발견자와 익스플로잇 속도가 늘며 보호 효과를 잃음
• 6주 동안 11명이 같은 치명적 결제 검증 버그를 보고해 동시 재발견이 드러남
• React 패치 diff는 AI 도움으로 30분 만에 작동 익스플로잇으로 바뀜
• Copy Fail과 Dirty Frag는 공개 PoC와 실제 악용으로 이어져 엠바고가 무너짐
• 치명적 이슈는 P0로 즉시 처리하고, LLM을 보안 파이프라인에 넣어야 함

90일 책임 공개 모델이 깨진 배경

• 90일 책임 공개 기간은 버그 발견자가 드물고 익스플로잇 개발이 느리던 환경을 전제로 만들어졌음
• 최근 12개월 동안 보안 담당자, 공격자, 연구자가 쓰는 도구가 비슷한 속도로 더 똑똑해졌고, LLM이 취약점 발견과 익스플로잇 개발 시간을 거의 0에 가깝게 줄였다는 판단임
• 2019년식 모델에서는 Google Project Zero 스타일처럼 벤더에 90일을 주고, 그동안 다음 전제를 뒀음
  • 같은 버그를 찾은 사람이 거의 없을 것
  • 다른 사람이 찾아도 시간이 걸릴 것
  • 벤더가 패치 작성에서 충분한 선행 시간을 가질 것
  • 패치가 공개된 뒤 공격자가 이를 역공학해 작동하는 익스플로잇을 만들기까지 며칠 또는 몇 주가 걸릴 것
• 이 전제들이 모두 틀렸고, 90일 창은 사용자를 보호하기보다 이미 버그를 가진 사람들에게 90일의 선행 시간을 주는 구조가 됐음

사례 1: 6주 동안 11명이 같은 치명적 버그를 보고함

• 4월 말 한 회사에 심각한 버그를 보고했지만, 트리아지 팀은 3월에 처음 보고됐고 본인이 11번째 제보자라고 답함
• 버그의 형태는 웹사이트에서 물건을 산 뒤 공격자가 직접 조작한 응답을 서버에 돌려보내도, 응답에 대한 서명 검증이 없어 서버가 이를 그대로 받아들이는 구조였음
  • 예시로 5,000달러짜리 물건을 0달러에 사거나, 실제 결제 없이 구매를 완료 처리할 수 있었음
• 약 6주 동안 서로 다른 11명이 같은 치명적 버그를 찾았다는 점에서, LLM 지원 사냥꾼들이 거의 동시에 같은 취약점에 수렴하는 패턴이 드러남
• BlueWater CTF의 한 지인은 몇 달 전부터 서로 관련 없는 리포터와 워크플로가 LLM 보조로 같은 버그에 모이는 현상을 짚었음
• 트리아지 측에서도 같은 현상이 관측됨
  • @d0rsky는 LLM 프롬프트, 스킬, 자동화로 새 취약점이 발견되면 며칠 안에 같은 근본 원인의 중복 보고가 몰린다고 썼음
  • 연구자가 이렇게 빨리 재현할 수 있다면, 패치 전에 블랙햇도 같은 일을 할 수 있다는 우려가 커짐
• 10명이 보고했다면 보고하지 않은 사람도 있을 수 있고, 같은 LLM은 선의의 연구자뿐 아니라 다른 누구에게도 열려 있음
• CVE 크레딧과 버그바운티는 1명만 받을 수 있어 나머지 9명이나 애초에 보고하지 않은 사람은 90일 시계에 묶여 있지 않음
• 90일 공개 창은 이 상황에서 사용자를 보호하지 못하고, 이미 버그를 가진 사람들에게 시간을 벌어주는 장치가 됨

사례 2: React 패치에서 작동하는 익스플로잇까지 30분

• React는 여러 보안 이슈를 패치하고 공개 블로그 글을 냈음
  • CVE-2026-23870
  • CVE-2026-44575
  • CVE-2026-44579
  • CVE-2026-44574
  • CVE-2026-44578
• 로컬 테스트 앱을 대상으로 패치를 읽고 작동하는 익스플로잇을 만드는 데 30분이 걸렸음
• 해당 공개 이슈는 서비스 거부(DoS)였고, AI가 diff 이해, 취약한 코드 경로 식별, PoC 작성의 대부분을 처리했음
• 과거에는 공개 패치를 작동하는 n-day 익스플로잇으로 바꾸는 데 숙련된 역공학자가 며칠에서 몇 주를 썼고, 이 시간차가 관리자가 업데이트할 수 있는 안전망이었음
• 이제 단순한 버그는 몇 분, 복잡한 버그도 몇 시간 단위가 될 수 있으며, 숙련된 역공학자는 필수가 아니게 됨
• 패치가 나오는 순간 익스플로잇도 존재한다고 가정해야 하고, 다음 유지보수 창까지 배포를 미루는 방식은 맞지 않음

사례 3: Linux 커널에서 연달아 터진 Copy Fail과 Dirty Frag

• 최근 2주 동안 Linux 커널에서 연속으로 두 개의 치명적 취약점이 나왔고, 둘 다 공개 익스플로잇이 있었으며 주요 배포판에 영향을 줬음

• Copy Fail

  • 4월 29일 Xint Code가 Copy Fail을 공개함
  • Xint Code는 Theori 뒤의 팀이며, DEF CON CTF를 9회 우승한 팀으로 소개됨
  • Copy Fail은 CVE-2026-31431이며, 커널 crypto 하위 시스템의 직선적인 논리 결함으로 설명됨
  • 레이스 컨디션 없이 100% 신뢰 가능하고, 732바이트 Python 스크립트로 2017년 이후 배포된 모든 Linux 배포판에서 root 권한을 얻을 수 있다고 함
  • Ubuntu, RHEL, Amazon Linux, SUSE 등 주요 배포판이 영향을 받음
  • AI를 사용해 커널 crypto/ 하위 시스템을 약 1시간 자동 스캔해 찾았고, 9년 동안 노출된 취약점이었다고 함
  • 기술 분석은 Xint의 글에 있음
  • mainline 커밋 a664bf3d603d로 패치가 나왔고, algif_aead 모듈 비활성화라는 완화책도 있었음
  • 이후 이란 공격자가 해당 취약점을 이용해 Ubuntu 서버를 침해하고 DDoS 캠페인 노드로 재활용하는 정황이 관측됐다고 함
  • AI로 발견된 커널 권한 상승 취약점이 공개 PoC와 국가 단위 공격자의 무기화로 이어지는 데 며칠밖에 걸리지 않았음

• Dirty Frag

  • 약 1주 뒤인 5월 7일 Hyunwoo Kim(@v4bel)이 Dirty Frag를 공개함
  • Dirty Frag는 CVE-2026-43284와 CVE-2026-43500을 연결한 취약점임
  • 커널의 IPSec ESP(esp4/esp6)와 RxRPC 네트워킹 모듈에 있는 두 취약점을 체인으로 연결함
  • Copy Fail 및 Dirty Pipe와 같은 버그 계열, 같은 page-cache corruption 기법이지만 공격 경로는 다름
  • Copy Fail 완화책을 적용해도 Dirty Frag는 동작함
    • algif_aead를 블랙리스트에 올려도 Dirty Frag는 해당 모듈을 쓰지 않음
  • 비권한 사용자에서 root로 결정적으로 상승할 수 있고, Ubuntu, RHEL 10.1, openSUSE, CentOS Stream, AlmaLinux, Fedora 44 등 주요 배포판에서 동작한다고 함
  • 컴파일과 실행은 한 줄 명령으로 가능함

• Dirty Frag 공개 과정과 엠바고 붕괴

  • Hyunwoo Kim은 4월 29~30일 [email protected]에 보고했고, 패치를 공개 제출했음
  • 5월 7일 linux-distros 메일링 리스트와 조율했고 5일 엠바고가 합의됨
  • 같은 날 몇 시간 안에 관련 없는 제3자가 ESP 취약점의 상세 익스플로잇 정보를 공개해 엠바고가 깨짐
  • 배포판 유지관리자들과 상의한 뒤 Hyunwoo는 Dirty Frag 전체 분석, 익스플로잇 코드, 작동 PoC를 공개함
  • 그 시점에 패치를 제공하는 Linux 배포판은 0개였음
  • 현재 기준으로 CVE-2026-43284, 즉 ESP 쪽만 mainline 수정이 있고, CVE-2026-43500, 즉 RxRPC 구성요소는 아직 upstream 패치가 없다고 함
  • Ubuntu, Red Hat, Tenable 등이 자체 권고문을 냈음

• Dirty Frag의 실제 악용

  • Microsoft Defender 팀은 공개 후 24시간 안에 제한적인 실제 악용을 확인함
  • 공격자는 SSH 접근을 얻고, ELF 바이너리를 배포하고, su로 root 권한을 얻고, 인증 설정을 수정하고, 세션 파일을 지우고, 횡적 이동을 수행했다고 함
  • CTS(@gf_256)는 “responsible disclosure is dead🤦”라고 요약함

실제로 죽은 것들

• 90일 공개 창은 고칠 수 있는 문제가 아니라 끝난 모델임
• 이 모델은 발견자가 드물고 익스플로잇 개발이 느리던 세계에 맞춰졌지만, LLM은 발견자를 많게 만들고 익스플로잇 개발을 빠르게 만듦
• 서로 관련 없는 10명이 6주 안에 같은 버그를 찾고, AI가 patch diff를 30분 만에 작동 익스플로잇으로 바꿀 수 있다면 90일 창은 아무도 보호하지 못함
• Copy Fail은 AI 스캔에서 공개 PoC, 국가 단위 공격자의 무기화까지 며칠 만에 이어졌음
• Dirty Frag는 같은 버그 계열을 독립적으로 찾은 제3자 때문에 엠바고가 몇 시간 만에 깨짐
• 같은 취약점이 여러 연구자와 AI 도구에 의해 동시에 독립 재발견되는 환경에서는 공개 조율이 유지되기 어려움
• 월간 패치 주기도 끝났음
  • 취약점과 수정 사이 30일 창은 공격자가 릴리스 트레인보다 느리다는 전제를 둠
  • Microsoft가 Dirty Frag 실제 악용을 24시간 안에 본 상황에서 월간 유지보수 창은 안전 여유가 아니라 공격 창이 됨
• 권고문을 기다리는 방식도 끝났음
  • 방어자가 CVE 설명을 읽는 동안 공격자는 git log --diff-filter=M을 읽고 있음
  • 권고문은 downstream 산출물이고, patch diff가 신호가 됨

업계가 바꿔야 할 대응

• 모든 치명적 보안 이슈를 P0로 보고 즉시 고쳐야 한다는 결론임
• “24시간 안”, “다음 스프린트”, “영향 평가 후”가 아니라, 하던 일을 멈추고 바로 고치는 수준이 필요함
• 프로덕션 배포가 복잡하고 변경 관리가 필요한 이유는 있지만, 위협 환경은 변경 관리 절차를 기다리지 않음

• 벤더

  • 치명적 버그 보고가 들어온 순간부터 시간이 흐르기 시작함
  • 트리아지가 끝난 시점이나 엔지니어링이 맡은 시점이 아니라, 보고가 도착한 순간이 기준임
  • 누군가 보고했다면 10명이 이미 갖고 있고 그중 최소 1명은 우호적이지 않다고 가정해야 함

• 연구자

  • 치명적 버그를 오래 보유하지 말고 가능한 가장 짧은 공개 창을 밀어야 함
  • 벤더가 1주 안에 고치지 못한다면 이는 공개 문제가 아니라 벤더 문제임
  • 과거의 “시간을 준다”는 예의는 자신이 유일한 발견자일 때 의미가 있었지만, 이제는 유일한 발견자가 아닐 가능성이 큼

• 취약점 관리

  • 취약점 관리는 실시간이어야 함
  • “주간 스캔, 스프린트에서 트리아지, 주기에 맞춰 패치”는 공격자가 이미 떠난 타임라인임
  • 치명적 이슈의 새 최대 응답 시간은 며칠이 아니라 몇 시간이고, 그마저도 느릴 수 있음

블루팀이 LLM을 방어 파이프라인에 넣어야 하는 이유

• 공격자는 이미 LLM을 익스플로잇 파이프라인에 통합했으며, 방어 측도 같은 속도로 움직여야 함
• 코드 push 시점에 LLM을 통합해야 함
  • 모든 pull request, merge, deploy에서 AI 지원 보안 리뷰를 CI 파이프라인 일부로 실행해야 함
  • linter와 unit test처럼 push 시점에 실행해야 하며, 분기별 감사나 사후 점검이 아니어야 함
  • 취약점이 있으면 프로덕션 도달 전에 잡아야 하고, PR 리뷰에서 고치는 비용은 CVE 공개 후 고치는 비용보다 훨씬 낮음
• 패치 분석에도 LLM을 통합해야 함
  • upstream 의존성이 보안 패치를 내면 파이프라인이 자동으로 diff를 가져오고, 변경 내용을 분석하고, 자사 코드베이스 영향 여부를 판단하고, 플래그를 올려야 함
  • 사람이 메일링 리스트를 읽고 Jira 티켓을 여는 방식에 의존하지 않고, 공개 저장소에 패치가 올라오는 즉시 몇 분 안에 자동으로 일어나야 함
  • Xint Code가 자동 스캔 1시간으로 Copy Fail을 찾았다면, 자체 의존성도 같은 방식으로 스캔해야 함
• 의존성 스캐닝에도 LLM을 써야 함
  • 공급망은 가장 약한 전이 의존성만큼만 강함
  • AI 기반 의존성 스캐너는 의존성 트리에서 취약점 영향을 추적하고, 영향받는 버전을 표시하고, 업그레이드 경로도 제안할 수 있음
  • 주간이 아니라 지속적으로 실행해야 함
• 패치 출시 전 AI로 패치를 테스트해야 함
  • React 사례처럼 LLM이 30분 만에 패치를 익스플로잇으로 바꿀 수 있다면, 방어자는 패치 공개 전에 같은 도구로 먼저 검증해야 함
  • 패치가 실제로 문제를 고치는지, 새 문제를 만들지 않는지 확인해야 함
  • 회귀 테스트 생성, 같은 패턴이 코드베이스 다른 곳에 있는지 확인하는 데 활용해야 함
• “취약점 존재”와 “취약점 악용” 사이의 창은 0에 가까워지고 있으며, 방어 쪽도 공격 쪽과 같은 속도로 자동화해야 함
• 더 많은 zero-day가 더 빠르게 실제 환경에서 악용될 것이며, 같은 도구, 낮아진 진입 장벽, 늘어난 발견자, 짧아진 타임라인이 그 이유임
• 이 전환에서 살아남는 팀은 강제로 밀려나기 전에 AI를 보안 파이프라인의 일급 구성요소로 만든 팀임

결론

• Dirty Frag 권고문을 읽는 시스템 관리자가 패치는 없고, 익스플로잇은 이미 공개됐고, Microsoft는 실제 악용을 보고 있으며, 완화책은 IPSec 모듈 비활성화인 상황에서 400대 서버를 만져야 하는 현실이 새 기준이 됨
• 90일 공개 정책, 월간 패치 주기, 공개와 악용 사이에 시간이 있다는 가정은 모두 죽었음
• 아직 남아 있는 것은 빠르게 움직이고, 강하게 자동화하고, 치명적 버그를 실제 긴급상황처럼 다루는 능력임
• 기존 모델을 깬 AI 물결은 동시에 빠른 패치, 자동 스캔, 실시간 위협 인텔리전스, AI 지원 코드 리뷰 같은 새 모델도 가능하게 함
• 도구는 이미 있으며, 방어자가 공격자보다 먼저 사용할지가 핵심이고, 현재는 공격자가 그 경쟁에서 앞서 있음