에이전트 기반 공격의 부상: 왜 이제 소문만으로도 제로데이가 발생하는가

전통적인 보안 비공개 정책—버그를 사전에 수정하고 공개 발표 전에 사용자에게 알리는 관행—은 점점 더 쇠퇴하고 있다. 현대의 위협 환경에서는 취약점에 대한 소문이나 공개된 풀 리퀘스트(Pull Request, PR)만으로도 AI 에이전트가 분석을 자동으로 수행하고 몇 분 내에 취약점을 발견 및 악용할 수 있는 충분한 신호를 제공한다.

보안 비공개 정책의 붕괴

AI 에이전트는 취약점 발견과 악용 사이의 시간을 극도로 단축시켰다. 최근 OCaml의 cohttp 6.3.0에서 발생한 경로 탐색 문제 사례에서는, 취약점을 수정하기 위한 공개 PR을 열자마자 10분 내에 유지보수자가 운영 중인 웹서버에 대해 활성 탐색이 시작되었다.

이러한 속도는 최전방 LLM이 자율적인 연구를 수행할 수 있기 때문이다. 경로 정규화 문제에 대한 힌트와 같은 광범위한 방향만 제공되어도, 에이전트는 자율적으로 정확한 취약점을 식별하고 작동 가능한 악용 코드를 생성할 수 있다. 이 전환은 몇 가지 주요 추세를 통해 뚜렷하게 드러난다:

음의 평균 악용 시간: 2026년 데이터에 따르면, 평균 악용 시간이 0을 넘어서며, 악용이 공식 패치보다 앞서는 경우가 흔해졌다. 2018-19년에는 이 지표가 약 63일이었다.
보고서에서 공격으로의 빠른 전환: 최근의 CVE들(예: marimo의 CVE-2026-39987, Langflow의 CVE-2026-33017)은 공개된 증명자료 없이도 9~20시간 내에 첫 번째 악용 시도가 발생했다.
최소한의 데이터로 높은 성공률: Fang 등이 수행한 연구에 따르면, GPT-4 에이전트는 CVE 설명만 제공받아도 15개의 취약점 벤치마크 중 87%를 악용할 수 있지만, 설명이 없을 경우는 단 7%에 불과하다. 이는 고수준의 설명조차도 자동화된 악용을 촉발하는 강력한 계기라는 것을 시사한다.

'버그노믹스'의 개념

LLM이 취약점 탐색과 악용 생성을 자동화함에 따라 소프트웨어 보안의 핵심 장애물은 '버그를 찾는 것'에서 '방어자 대응 처리량'으로 이동했다. 이 현상을 '버그노믹스'라고 부르며, 공격자는 기계 속도로 악용 코드를 생성할 수 있지만, 인간 중심의 검증, 우선순위 설정, 지속 가능한 패치 배포 과정은 여전히 정체되어 있다는 심각한 불균형을 강조한다.

오픈소스 유지보수자는 특히 취약하다. 왜냐하면 공격자들이 사용하는 최전방 에이전트에 접근할 수 있는 기회가 부족하기 때문이다. Project Glasswing과 같은 이니셔티브는 일부 기관에 고급 AI 접근 권한을 제공하지만, 많은 독립 유지보수자는 상용 모델의 보안 가드레일에 막혀 자신의 방어적 패치 개발을 AI로 가속화할 수 없다.

현대 방어를 위한 제안 전략

에이전트 기반 악용에 대응하기 위해 산업계는 수동적인 우선순위 설정과 비공개 정책을 넘어서 더 동적인 방어 메커니즘으로 나아가야 한다.

1. 비공개 패치 개발 및 신뢰 네트워크

AI 모니터링 도구로부터 완전히 격리된 환경에서 패치를 개발하는 것은 필수적이다. 그러나 현재 GitHub의 일시적 프라이빗 포크와 같은 도구는 종종 부족하다. 왜냐하면 유지보수자들이 중요한 CI/CD 파이프라인과 단절되기 때문이다. 더 견고한 해결책은 신뢰할 수 있는 기여자들 사이에서 취약점 정보를 안전하게 공유할 수 있는 '신뢰 네트워크' 인프라를 구축하는 것이다. 이는 일반 대중에게 정보가 유출되지 않도록 한다.

2. 지속적 배포 및 자동 우선순위 설정

노출 시간을 줄이기 위해서는 지속적인 배포 모델로 전환해야 한다. 이에는 다음이 포함된다:

동적 패치: 재시작 없이 런타임에 바이너리를 교체할 수 있는 메커니즘을 구현한다(Chrome의 주간 업데이트와 유사).
다중 생태계 패키지 관리: 하류 제품에 라이브러리가 포함된 위치를 추적할 수 있는 능력을 향상시켜 업데이트가 더 빠르게 확산되도록 한다.
자동 우선순위 설정 도구: Scrutineer과 같은 도구를 활용해 유지보수자가 기계가 생성한 버그 보고서 폭주를 관리할 수 있도록 한다.

3. 프로토콜 계층의 사전 방어 보호

완전한 패치를 패키징하고 배포하기를 기다리지 않고, 방어자는 프로토콜 계층에서 '가상 패치'를 구현할 수 있다. 예를 들어, 경로 탐색 취약점은 하위 라이브러리가 업데이트되기 전에 엣지(CDN 또는 게이트웨이)에서 % 인코딩된 경로 구분자를 정규화하는 규칙을 배포함으로써 즉시 완화할 수 있다.

커뮤니티의 시각과 반론

유지보수자들 사이의 기술적 논의는 문제의 본질이 단순히 기술적인 것이 아니라 체계적인 문제라는 점을 시사한다. 일부는 취약점 개발의 민주화로 인해 저수준의 악성 행위자가 이제 동시에 전체 인터넷을 표적으로 삼을 수 있게 되었다고 주장한다.

"패치, 커밋 메시지, 또는 무작위로 듣거나 읽은 문장에서 악용 PoC를 뒤로 빼내는 것은 취약점 연구 역사와 함께 오래된 관행이다. LLM이 가져온 차이점은, '충분히 숙련된'(인간이든 아니든) 행위자들의 폭발적 증가로 인해, 이전에는 불가능했던 '전체 인터넷을 공격하는' 낮은 수준의 행위자가 가능해졌다는 점이다."

다른 유지보수자들은 양상의 급격한 증가를 보고하며, 한 rclone 유지보수자는 10년 동안 20건의 보안 공개를 경험했지만, 최근 한 달 사이에 40건 이상으로 급증했다고 밝혔다. 또한, '마이크로 업데이트' 추진이 새로운 위험을 초래할 수 있다는 우려도 제기된다. 예를 들어, 업데이트 메커니즘 자체가 원격 코드 실행을 유도하는 벡터가 될 수 있으며, 이는 극도로 신중하게 다뤄져야 한다.

미래 연구 방향

이러한 도전에 대응하기 위해서는 소프트웨어 강제 실행에 대한 새로운 아키텍처적 접근이 필요하다. 제안된 연구 방향에는 다음이 포함된다:

방어용 실험실: 취약점 소문에 기반해 자동으로 완화 규칙을 배포할 수 있는 게이트웨이(예: MirageOS 사용)를 구축하는 것.
강제 실행 오토마타: Lean에서 생성한 형식적 사양을 런타임 오토마타로 컴파일하여 파일시스템 및 네트워크 계층에서 라이브러리가 수행할 수 있는 작업에 엄격한 제한을 부여하는 것. 이는 특정 악용이 알려지지 않았더라도 전체 클래스의 취약점을 무력화할 수 있다.