AI가 패치를 작업 가능한 악성코드로 30분 만에 변환, 90일 공개 기간이 희생된다

대규모 언어모델(LLM)은 보안 패치의 before/after diff를 분석해 어떤 코드 경로가 수정됐는지, 왜 수정됐는지를 추론할 수 있습니다. 이 "패치 디핑(patch diffing)" 기법 자체는 오래된 보안 연구 방식이지만, 기존에는 숙련된 리버스 엔지니어가 며칠~몇 주에 걸쳐 수행하던 작업이었습니다. 이제 LLM은 패치된 함수의 컨텍스트를 읽고 취약 조건을 역추적해 PoC(Proof of Concept) 익스플로잇 코드까지 생성하는 과정을 30분 내외로 단축시킵니다. 모델이 정적 분석, 심볼릭 추론, 코드 합성을 동시에 수행할 수 있게 되면서 "1-day 익스플로잇"(공개된 패치를 기반으로 한 공격) 생산 비용이 사실상 0에 수렴하고 있다는 것이 이번 논의의 핵심입니다.

이는 Google Project Zero가 정착시킨 90일 책임공개(responsible disclosure) 모델의 전제 자체를 흔듭니다. 90일이라는 유예 기간은 "벤더가 패치를 만들고 사용자가 적용할 시간"을 가정하지만, 실제로 많은 기업은 패치 배포 후에도 수 주에서 수 개월에 걸쳐 점진적으로 롤아웃합니다. 공격자가 패치 공개 30분 뒤에 익스플로잇을 가동할 수 있다면, "패치가 나왔지만 아직 적용 전"인 윈도우가 가장 위험한 골든타임이 됩니다. 특히 오픈소스 라이브러리(예: log4j, libcurl, OpenSSL 류)의 CVE는 수많은 다운스트림 프로젝트에 동시에 노출되기 때문에, 의존성 트리 어딘가에 취약 버전을 묻어둔 채 빌드를 돌리고 있는 한국 백엔드/인프라 팀에게는 직접적인 위협입니다.

엔지니어 입장에서 가장 먼저 점검해야 할 것은 패치 적용 SLA입니다. "월 1회 정기 패치"나 "분기별 의존성 업데이트" 같은 운영 정책은 이미 위험한 가정 위에 서 있으며, Critical/High CVE의 경우 24~72시간 내 핫픽스 파이프라인이 필수가 됩니다. Renovate/Dependabot의 자동 PR 생성, SBOM(Software Bill of Materials) 관리, 카나리 배포 기반 빠른 롤아웃, 그리고 패치 적용 전에 임시로 위험 경로를 차단할 수 있는 WAF/RASP 룰 준비가 함께 가야 합니다. 사내 모니터링 측면에서는 CVE 공개 시점부터 자사 환경에 해당 취약 버전이 얼마나 남아 있는지를 실시간으로 보여주는 대시보드(예: Wazuh, Trivy + Grafana 조합)가 사실상 필수 인프라가 됩니다.

마지막으로 개발자가 인식해야 할 패러다임 변화는 "보안은 더 이상 보안팀만의 문제가 아니다"라는 점입니다. AI가 공격 측의 비용 곡선을 압도적으로 낮춘 만큼, 방어 측도 동일한 도구를 활용해야 합니다. CodeQL, Semgrep 같은 정적 분석에 LLM 보강을 붙여 PR 단계에서 취약 패턴을 잡고, 패치 릴리스 노트를 LLM으로 자동 요약해 영향도를 평가하며, 내부적으로도 "우리 코드의 어느 부분이 비슷한 취약 패턴을 갖고 있는가"를 선제적으로 탐색하는 워크플로우를 구축하는 것이 현실적인 대응입니다. 90일 공개 모델이 어떤 방향으로 재정의되든, 그 사이의 공백을 메우는 것은 결국 각 팀의 패치 운영 성숙도라는 점을 분명히 해둘 필요가 있습니다.