AI가 취약점을 찾고 고친다: 크롬 보안팀이 공개한 새로운 보안 파이프라인

출처: Chrome Security Team (Google 블로그)
원문: https://blog.google/security/chrome-stronger-with-every-update/

작성자: 팔복소프트-김팔복

한눈에 보기

크롬 보안팀이 LLM 기반 에이전트로 취약점 탐지·분류(triage)·수정까지 자동화한 과정을 공개했다.
Chrome 149와 150 두 마일스톤에서만 보안 버그 1,072건을 수정했는데, 이는 그 이전 23개 마일스톤을 모두 합친 것보다 많은 수치다.
버그를 더 많이 찾아내는 만큼 패치를 빠르게 전달하는 것도 과제가 됐다. 주 2회 보안 릴리스, 재시작 없는 동적 패치를 시험 중이다.
C++ 런타임 방어(MiraclePtr, spanification)와 Rust 전환이라는 2단계 메모리 안전 전략도 함께 진행된다.
사내 스캔용 AI는 인터넷이 차단된 격리 환경에서 소스 코드만 정적으로 분석하도록 제한된다.

주요 내용

13년 묵은 샌드박스 탈출 버그를 찾아낸 순간

크롬 보안팀의 LLM 활용은 최근에 시작된 게 아니다. 2023년에는 퍼징 커버리지를 높이는 데 LLM을 썼고, 2024년에는 Project Zero와 함께 취약점 연구용 도구를 모델에 쥐여준 Naptime을, 2025년에는 DeepMind·Project Zero와 함께 V8 자바스크립트 엔진과 그래픽 스택에서 실제 버그를 찾아낸 Big Sleep을 만들었다.

전환점은 2026년 초였다. Gemini를 활용한 에이전트 하네스를 크롬 코드베이스 전반에 돌렸고, 여기서 렌더러가 탈취되면 브라우저를 속여 로컬 파일을 읽게 만드는 샌드박스 탈출 버그가 나왔다. 13년 넘게 코드베이스에 남아 있던 버그였다. 팀 입장에서는 AI 기반 취약점 탐지의 가능성을 확인한 사건이었다.

이후 하네스는 이런 방향으로 개선됐다.

모델 상호 운용성: 오픈 웨이트 모델과 상용 모델의 강점을 각각 활용
크롬 전용 지식 베이스: 과거 CVE 전체와 Git 히스토리를 넣어 학습 데이터 밖의 맥락을 보강
SECURITY.md 확산: 개발자들이 컴포넌트별 신뢰 경계와 위협 모델을 문서로 남기도록 유도
critic 에이전트 도입: 별도 컨텍스트에서 SECURITY.md를 읽고 결과를 검증
반복 실행: 모델의 비결정성과 성능 향상을 고려해 같은 코드를 여러 번 스캔
가드레일도 함께 걸었다. AI는 정지 상태의 소스 코드만 분석하고, 일반 인터넷 접근이 차단된 격리 머신에서 동작한다. 모든 네트워크 요청은 가로채서 출발 애플리케이션과 목적지 기준 허용 목록으로 걸러내며, 무제한 모드로 모델을 돌리지 않고 서브에이전트가 지정된 소스 디렉터리 밖의 파일을 건드리거나 시스템을 수정하지 못하게 제한한다.

퍼징이 밀려난 것은 아니다. 코드베이스의 떨어져 있는 부분들이 장거리로 상호작용하며 생기는 버그, 서로 무관해 보이는 동작이 조합돼야 터지는 버그는 여전히 퍼징이 잘 잡는다.

외부 제보 쪽에서는 변화가 컸다. 2026년 3월 시점에 이미 2025년 한 해 전체보다 많은 버그 리포트가 들어왔고, 이에 맞춰 VRP(Chrome Vulnerability Reward Program)를 내부에서 이미 찾아내는 것과 겹치지 않는 제보, 그리고 자동화 파이프라인이 바로 처리할 수 있는 형태의 제보 중심으로 조정했다.

트리아지: 사람 손에서 자동화 파이프라인으로

보안 리포트 하나를 분류하는 데 예전에는 5분에서 30분 이상이 걸렸고, 대부분 사람의 판단에 의존했다. 지금은 룰 기반 시스템과 AI를 섞은 4단계 자동 처리로 옮겨가는 중이다.

노이즈 제거 — 스팸 여부, 중복 여부, 실제 크롬 보안 취약점을 설명하고 있는지 확인
재현 — PoC가 있으면 해당 OS와 브라우저 버전에서 실제로 돌려보고, 스택 트레이스 같은 정보를 리포트에 붙임
메타데이터 보강 — 버그가 처음 유입된 시점, 심각도 등급을 추가. 자동 판정이 가능하도록 심각도 가이드라인 자체를 더 명확하게 다듬었다
자동 배정 — 올바른 컴포넌트와 담당자에게 라우팅
심각도는 개발자가 잘못됐다고 판단하면 수정할 수 있고, SECURITY.md로 보안 경계에 대한 맥락을 모델에 추가로 줄 수 있다. 정확한 측정은 어렵지만 팀은 이 과정에서 월 수백 시간의 개발자 시간이 절약되는 것으로 보고 있다.

수정도 멀티 에이전트로

수정 단계 역시 여러 에이전트가 나눠 맡는다. 이슈 컨텍스트를 모아 빌드한 뒤 fixing 에이전트가 후보 패치를 여러 개 만들고, critic 에이전트가 그중 어떤 것이 적절한지 평가하면서 개발자가 검토할 자료를 함께 생성한다. 두 에이전트는 코드 리뷰와 비슷한 루프를 돌며 Chromium·Google 스타일 가이드와 로컬 코딩 관례를 지키는지 확인한다. 테스트 작성 에이전트는 크롬이 지원하는 모든 플랫폼과 구성에서 테스트가 동작하는지까지 검증하는데, 개발자 리뷰 전에 이 작업이 끝나 있으면 수 주 단위의 시간이 절약된다.

결과는 숫자로 드러난다. Chrome 149와 150에서 수정된 보안 버그는 1,072건으로, 직전 23개 마일스톤의 합계를 넘어섰다.

BigSleep과 CodeMender는 CI에 직접 통합돼 24시간마다 모든 CL을 대상으로 돌아간다. 5월 한 달에만 20건 이상의 취약점이 프로덕션에 도달하기 전에 차단됐고, 그중에는 S1+ 등급의 심각한 이슈도 있었다.

패치 갭과 재시작 문제

수정 커밋이 오픈소스 저장소에 올라가는 순간부터, 공격자는 그 diff를 역분석해 아직 업데이트되지 않은 사용자를 노릴 수 있다. 이른바 N-day 공격이고, 커밋부터 Stable 채널 도달까지의 간격이 패치 갭이다.

크롬은 심각도에 따라 메인 트리에서 활성 Stable 브랜치로 수정을 직접 머지하고, 새로운 크래시나 회귀가 없는지 계속 모니터링한다. 메이저 마일스톤은 2주 주기, 보안 업데이트는 주 1회로 전환 중인데, 여기서 더 나아가 주 2회 보안 릴리스를 시험하고 있다. 릴리스 노트와 CVE 설명 생성도 자동화해 공개 시점을 앞당기려 한다.

더 까다로운 병목은 사용자 쪽이다. 크롬은 2008년부터 백그라운드 무음 업데이트를 해왔지만, 실제 적용은 브라우저를 재시작해야 이뤄진다. 트리아지·수정·테스트·릴리스가 1~2일이면 끝나는 상황에서 사용자가 재시작을 미루는 시간이 오히려 위험 구간이 된 셈이다. 대응 방향은 세 가지다.

동적 패치(dynamic patching): 크롬의 멀티 프로세스 구조를 이용해 렌더러, GPU 같은 자식 프로세스를 새 바이너리로 순차 교체한다. 대부분의 경우 전체 재시작이 필요 없어진다. 아직 연구·개발 단계다.
세션 복원 강화: 상태를 더 많이 로컬에 저장해 복잡한 상황에서도 매끄럽게 복원
적절한 시점의 자동 재시작: Chrome 150에서는 macOS 특성상 창을 모두 닫아도 앱이 백그라운드에 남아 있는 상태를 활용해, 이때 대기 중인 업데이트가 있으면 자동으로 재시작하도록 했다.
기업 환경에서는 다음 세 가지가 권장된다. RelaunchNotification 정책으로 재시작을 안내하다가 일정 기간 후 강제 재시작으로 단계를 올리기, 변경 검증이 필요한 민감한 환경에서는 Extended Stable 채널 사용, Chrome Enterprise Core/Premium 대시보드로 조직 전체 버전 현황 관리.

버그를 아예 줄이는 쪽

개별 버그 수정과 별개로, 버그 클래스 자체를 없애는 작업도 병행된다.

C++ 런타임 방어는 세 축으로 정리된다.

MiraclePtr로 UAF(Use-After-Free)를 크게 줄인 데 이어, Skia·ANGLE·Dawn과 C++ 이터레이터, std 컨테이너로 적용 범위를 넓히고 있다. MiracleObject는 GPU 메인 스레드의 UAF 취약점을 최대 90%까지 무력화하는 것이 목표이며, 국소적인 런타임 성능을 내주고 시간적 안전성을 얻는 선택이다.
Spanification: 포인터+길이 형태의 레거시 코드를 컴파일러가 검증하는 std::span으로 옮기는 작업으로, 현재 크롬 자체 코드의 97%가 엄격한 unsafe-buffer 경고 아래 깨끗하게 컴파일된다. 이 요구사항을 Skia·ANGLE·Dawn 같은 하위 코드베이스로 확대하는 중이다.
메모리 할당과 연결된 계산에 checked math를 적용해 정수 오버플로 경로를 막고, 포인터를 포함한 타입과 그렇지 않은 타입을 힙 파티션 수준에서 분리해 UAF 익스플로잇을 어렵게 만든다.
다만 런타임 완화는 몇 년 안에 한계 효용에 도달할 것으로 보고 있다. 런타임 검사는 컴파일 타임 보장보다 본질적으로 비싸고, 아무리 방어를 넣은 C++ 바이너리라도 Rule of Two를 만족하려면 성능을 깎는 샌드박싱이 필요하기 때문이다.

그래서 장기 해법은 Rust로의 이동이다. Chromium API와 도구를 Rust에서 바로 쓸 수 있게 하는 중앙 Rust SDK를 만들어 새 컴포넌트를 Rust로 짜는 것이 자연스러운 선택이 되도록 하고, 파서·이미지 코덱·폰트 스택처럼 역사적으로 버그가 몰린 영역을 우선 교체한다. 또한 Rust로 작성한 모듈은 샌드박싱 비용 없이 브라우저 프로세스 같은 고권한 프로세스 안에서 복잡한 기능을 실행할 수 있어, 기존 C++ 아키텍처의 제약을 깬다. Rust 외에 브라우저 최상위 UI를 HTML·CSS·TypeScript로 구현하는 방안도 검토 중이다.

커밋 전 차단도 강화됐다. 대량 스캔만으로는 크롬의 개발 속도를 따라갈 수 없기 때문에, CI와 커밋 큐(CQ) 파이프라인에서 diff를 자동 검사해 spanification 수정 제안, 댕글링 포인터 경고, 숫자 안전성 강제 같은 작업을 수행한다. 특히 주목할 만한 건 잠복형(latent) 이슈다. 그 자체로는 안전한 코드가 트리의 전혀 다른 곳에서 일어난 사소한 로직 변경 때문에 취약점으로 바뀌는 경우인데, CQ 안에서 LLM 기반 의미 분석을 돌려 기존 정적 분석이 놓치던 이런 상호작용을 커밋 전에 잡으려 한다.

크롬 밖의 생태계

크롬만 지킨다고 웹이 안전해지지는 않는다. Google은 최근 다른 참여자들과 함께 Alpha-Omega 프로젝트에 1,250만 달러를 기부했고, 업스트림 메인테이너의 부담을 줄이기 위해 취약점 리포트를 한곳에 모으고 보안 대응팀을 제공하는 Akrites 프로젝트의 창립 멤버로 참여했다.

규모 감각을 보여주는 숫자도 있다. Chromium과 V8, BoringSSL, Skia·ANGLE·Dawn 같은 위성 프로젝트를 합치면 서드파티 의존성이 2,300개가 넘고, 이 중 약 1,700개가 어떤 형태로든 사용자에게 배포된다. 안드로이드 기기부터 엣지 컴퓨팅, 대규모 클라우드 스택까지 퍼져 있는 코드다.

지금까지는 NVD, OSV 같은 외부 피드와 내부 피드를 받아 자동 스캔하는 방식이었지만, 반응형 모니터링만으로는 공백이 생긴다. 그래서 올해부터 모든 서드파티 의존성을 최신 업스트림 버전으로 자동 갱신하는 파이프라인에 올리기 시작했다. 자동화에는 가드레일이 필요하므로 GOSSIP(Google's Open Source Security Intelligence Platform) 같은 안전성 신호를 함께 참고한다.

정리

수정된 보안 버그 수가 급증한 것은 크롬이 갑자기 취약해졌다는 뜻이 아니라, 그동안 사람 손으로 도달하지 못하던 영역까지 탐지 범위가 넓어졌다는 뜻이다. 크롬팀 스스로 밝히듯 발견과 수정은 절반일 뿐이고, 이제 병목은 "얼마나 빨리 사용자 기기까지 패치가 도달하느냐"로 옮겨갔다. 주 2회 릴리스와 동적 패치 실험은 그 병목을 겨냥한 것이다.

같은 흐름은 크롬만의 이야기가 아니다. 대규모 코드베이스를 운영한다면 취약점 탐지 자동화보다 트리아지·수정·배포 파이프라인이 그 속도를 감당할 수 있는지가 곧 현실적인 질문이 된다. SECURITY.md처럼 모델이 신뢰 경계를 이해하도록 돕는 문서화, 격리 환경에서만 스캔을 돌리는 가드레일 설계는 규모와 무관하게 참고할 만한 부분이다.

추천 태그:

Chrome
보안
AI 에이전트
취약점
Rust