LLM 시대의 90일 공개 정책 종말

10년 넘게 보안 업계는 몇 가지 기본 가정에 의존해 왔습니다: 버그를 찾는 사람은 비교적 드물고, 익스플로잇 개발은 느리고 숙련된 과정이며, 90일 공개 창은 공급업체가 패치를 적용할 충분한 시간을 제공해 대중과 공격자에게 알려지기 전에 대비할 수 있다는 것이었습니다.

이러한 가정은 더 이상 유효하지 않습니다. 대형 언어 모델(LLM)이 공격 및 방어 워크플로에 통합되면서 발견에서 익스플로잇까지의 시간이 거의 0에 가깝게 압축되었습니다. 이제 "책임 있는 공개" 창이 사용자를 보호하는 것이 아니라, 이미 버그를 발견하고 보고하지 않기로 선택한 사람에게 선점 기회를 제공하고 있습니다.

발견 독점의 붕괴

전통적인 모델에서는 연구자가 중요한 버그를 찾아 몇 주 동안 그 지식을 독점할 수 있었습니다. 오늘날 LLM을 활용한 사냥은 "수렴 발견"이라는 현상을 만들었습니다.

예를 들어, 최근 한 사례에서 공격자가 웹사이트의 결제 검증을 우회하도록 하는 중요한 취약점이 보고되었습니다. 연구자는 자신이 같은 버그를 6주 동안 보고된 열한 번째 사람이라는 것을 알게 되었습니다. 이러한 패턴은 체계화되고 있습니다. LLM 프롬프트와 자동화된 기술이 공유되거나 독립적으로 도출될 때, 서로 관련 없는 여러 연구자가 거의 동시에 동일한 근본 원인에 도달합니다.

이는 위험한 인센티브 구조를 초래합니다. 열 사람이 버그를 찾았지만 CVE 크레딧이나 현상금을 받는 사람이 한 명뿐이라면, 나머지 아홉 사람은 강력한 무기를 손에 넣고 보상은 받지 못합니다. 발견이 빠르고 풍부한 세상에서 90일 시계는 보호가 아니라 노출 기간이 됩니다.

패치에서 익스플로잇까지 몇 분

과거에는 "n일 차이"—패치가 배포된 뒤 작동하는 익스플로잇이 개발되기까지의 시간이 중요한 안전망이었습니다. 이는 시스템 관리자가 며칠 또는 몇 주 동안 시스템을 업데이트할 수 있는 창을 제공했습니다.

그 차이는 사라졌습니다. 최근 React 보안 패치를 대상으로 한 실험에서 LLM이 패치 diff를 분석하고 취약한 코드 경로를 식별한 뒤, 30분 만에 작동하는 Proof of Concept (PoC)를 생성할 수 있음을 보여주었습니다. 단순하거나 중간 복잡도의 버그에 숙련된 리버스 엔지니어가 더 이상 필요하지 않으며, LLM이 지루한 분석을 담당하고 인간은 과정을 조정하기만 하면 됩니다.

사례 연구: 이번 주 Linux "불붙음"

두 개의 최근 Linux 커널 취약점은 오래된 공개 모델이 완전히 실패했음을 보여줍니다:

Copy Fail (CVE-2026-31431)

AI‑자동화 스캔을 통해 커널 crypto/ 서브시스템을 단 1시간 만에 발견한 이 논리 결함은 2017년 이후 배포된 거의 모든 Linux 배포판에서 100% 신뢰할 수 있는 루트 상승을 가능하게 했습니다. 무기화 속도는 충격적이었습니다: 공개 후 며칠 만에 국가 수준의 공격자들이 이 버그를 이용해 Ubuntu 서버를 DDoS 캠페인에 활용했습니다.

Dirty Frag (CVE-2026-43284 & CVE-2026-43500)

이 취약점 체인은 Copy Fail에 적용된 방어책을 우회했습니다. 조정된 노력과 5일 금지 조치에도 불구하고, 제3자가 몇 시간 안에 익스플로잇 정보를 공개하면서 금지 조치를 깨뜨렸습니다. 전체 보고서와 PoC가 공개될 때까지 Linux 배포판 중 패치를 제공한 곳은 없었습니다. Microsoft의 Defender 팀은 24시간 이내에 실제 악용 사례를 확인했습니다.

새로운 보안 필수 과제

90일 창과 월간 패치 사이클이 사라졌다면, 업계는 실시간 대응 모델로 전환해야 합니다.

공급업체와 연구자를 위한 지침

중요 보안 이슈는 P0 긴급 상황으로 취급해야 합니다. 시계는 보고서가 접수되는 순간부터 시작되며, 트리아지가 끝나는 시점이 아닙니다. 연구자는 가능한 한 짧은 공개 창을 요구해야 하며, 자신이 유일한 발견자가 아닐 가능성을 인식해야 합니다.

블루 팀을 위한 AI 기반 방어

방어자는 수동 프로세스로 LLM 기반 공격자를 상대할 수 없습니다. 방어 파이프라인은 공격 파이프라인과 동일한 속도로 자동화되어야 합니다:

Point-of-Push Review: AI‑보조 보안 검토를 CI 파이프라인에 통합합니다. 취약점은 CVE가 발행된 뒤가 아니라 Pull Request (PR) 단계에서 잡혀야 합니다.
Automated Patch Analysis: 상위 종속성이 패치될 때 AI가 자동으로 diff를 분석하고, 로컬 코드베이스에 영향을 미치는지 판단해 즉시 조치를 취하도록 표시합니다.
AI-Verified Patching: 보안 수정을 배포하기 전에 LLM을 사용해 패치가 실제로 구멍을 닫았는지, 새로운 회귀를 도입하지 않았는지 검증합니다.

반론: 이것이 단지 "쉽게 잡히는 버그" 단계인가?

일부는 LLM이 발견한 버그 급증이 일시적인 현상이라고 주장합니다. 이론은 레거시 코드의 "쉬운" 버그가 사라지면 업계가 다시 인간 통찰이 주요 발견 동력이 되는 상태로 돌아간다는 것입니다.

하지만 이는 AI의 반복적 특성을 과소평가한 것입니다. LLM이 복잡한 상태 머신과 레이스 컨디션을 이해하는 능력이 향상될수록 "쉽게 잡히는 버그"의 정의는 확대됩니다. 위험은 모든 버그가 발견되는 것이 아니라, 익스플로잇 전에 수정할 수 있는 창이 영구적으로 축소된다는 점입니다.

마무리 생각

현대 보안의 현실은 취약점과 익스플로잇 사이의 간격이 0에 가까워지고 있다는 것입니다. 이 변화를 견디는 유일한 방법은 방어 파이프라인에 AI를 일등 시민으로 만드는 것입니다. 스캔, 분석, 패치를 자동화하는 도구는 이미 존재합니다; 남은 질문은 방어자가 공격자보다 먼저 이를 배포할 수 있느냐입니다.