• Chrome은 Gemini 기반 에이전트로 취약점 발견부터 분류·수정·배포·업데이트 적용까지 자동화하며, Chrome 149와 150에서 이전 23개 마일스톤을 합친 것보다 많은 보안 버그 1,072개를 수정함
  • 취약점 탐지 시스템은 여러 모델과 Chrome의 CVE·Git 이력 지식 기반, SECURITY.md, 별도 비평 에이전트를 결합하고 인터넷과 로컬 시스템 접근을 엄격히 제한한 환경에서 작동함
  • 자동 분류는 스팸·중복 제거, 재현과 스택 추적 수집, 심각도 등 메타데이터 추가, 담당자 배정을 수행해 매달 수백 시간의 개발자 작업을 줄이는 것으로 추산됨
  • 수정 공개 후 악용까지의 패치 격차를 줄이기 위해 주 2회 보안 릴리스를 시험하고, 재시작 없이 자식 프로세스를 교체하는 동적 패치와 macOS 자동 재시작을 개발함
  • 개별 버그 수정에 그치지 않고 MiraclePtr·std::span·Rust로 메모리 안전성을 높이며, 제출 시점 AI 검사와 2,300개 이상의 외부 의존성 자동 업데이트로 취약점 유입을 예방함

AI가 바꾼 보안 버그의 생애주기

  • LLM은 사람의 보안 전문성만으로 처리할 수 있는 규모를 넘어 자동 취약점 탐지를 확장했으며, Chrome은 수백 개의 보안 버그를 더 빠르게 찾고 수정하는 데 AI를 활용함
  • 일반 기능 버그가 UI 멈춤 같은 문제를 일으키는 데 비해 보안 버그는 공격자가 개인 데이터를 읽거나 사용자 몰래 컴퓨터를 제어하는 익스플로잇에 이용될 수 있음
  • 보안 버그는 발견, 분류, 수정, 수정본이 포함된 Chrome 배포, 브라우저 재시작과 적용 순서로 처리되며 모든 단계를 최대한 단축하는 것이 목표임

취약점 탐지의 확장

  • Chrome 보안팀은 여러 해에 걸쳐 LLM 기반 탐지 기술을 발전시킴
  • 2023년에는 보안 퍼징의 범위와 성능을 높이는 방법을 개발함
  • 2024년에는 Project Zero와 Naptime을 개발해 LLM에 취약점 연구용 전문 도구를 제공함
  • 2025년에는 DeepMind·Project Zero와 Big Sleep을 개발했으며, 이 에이전트가 V8 JavaScript 엔진과 그래픽 스택에서 버그를 발견함
  • 2026년 초 구축한 Gemini 에이전트 하네스는 더 넓은 Chrome 코드베이스에서 탐지 효율을 높이고 오탐을 줄임
  • 발견된 샌드박스 탈출 버그는 침해된 렌더러가 브라우저를 속여 로컬 파일을 읽게 할 수 있었으며, 코드에 13년 넘게 남아 있었음
  • 탐지 하네스에는 다음 기능이 추가됨
  • 오픈 웨이트 모델과 독점 모델 각각의 강점을 이용하는 모델 상호운용성
  • 기존 CVE 전체와 Chrome의 전체 Git 이력을 포함한 지식 기반
  • 신뢰 경계와 위협 모델을 명확히 전달하는 SECURITY.md 작성 지침
  • 별도 컨텍스트에서 SECURITY.md를 읽는 비평 에이전트
  • 모델의 비결정성과 시간에 따른 개선을 반영하기 위한 코드베이스 반복 검사
  • AI는 일반 인터넷에 접근할 수 없는 잠금 장비에서 저장된 소스 코드만 분석함
  • 모든 네트워크 요청을 가로채 애플리케이션과 목적지 기반 허용 목록을 적용함
  • 모델을 무제한 모드로 실행하지 않으며, 하위 에이전트의 시스템 변경과 지정된 소스 디렉터리 외부 파일 접근을 제한함
  • AI 탐지는 기존 보안 테스트를 대체하지 않음
  • 퍼징은 서로 떨어진 코드 영역의 장거리 상호작용이나 무관해 보이는 여러 연산의 조합에서 발생하는 버그에 특히 효과적임
  • 외부 연구자는 Chrome Vulnerability Reward Program을 통해 어렵고 영향력 큰 취약점을 계속 찾도록 보상받음
  • 2026년 초 모든 유형의 신고가 증가했고, 3월에는 2025년 전체보다 많은 버그 신고가 접수됨
  • 이에 따라 VRP를 변경해 내부 탐지 결과에 추가 가치를 제공하고 자동 처리 파이프라인이 쉽게 수용할 수 있는 신고에 집중함

자동 분류와 다중 에이전트 수정

  • 과거에는 보안 신고 하나를 분류하는 데 5분에서 30분 이상이 걸리고 주로 사람의 전문성에 의존했지만, 현재는 규칙 기반 시스템과 AI를 결합해 처리량과 정확도를 높임
  • 자동 분류는 네 단계로 진행됨 1. 스팸과 중복을 제거하고 접수 기준 충족 여부와 Chrome 보안 취약점에 대한 명확한 설명이 있는지 검사함 2. 개념 증명과 재현 가능성을 확인하고 해당 운영체제·브라우저 버전에서 시험한 뒤 스택 추적 같은 정보를 첨부함 3. 버그가 처음 유입된 시점과 심각도를 추가함
    • 자동 적용이 쉽도록 심각도 지침을 명확하게 정비함
    • 개발자는 잘못된 심각도 등급을 변경하고 SECURITY.md로 보안 경계 정보를 보충할 수 있음 4. 문제를 올바른 구성요소와 담당자에게 자동 배정함
  • 정확한 측정은 어렵지만 자동 분류로 매달 수백 시간의 개발자 작업을 줄이는 것으로 추산함
  • 취약점 수정에는 다중 에이전트 작업 흐름을 적용함
  • 수정 에이전트가 문제별 컨텍스트를 받아 여러 후보 패치를 생성함
  • 비평 에이전트가 가장 적합한 후보를 평가하고 개발자의 검토에 필요한 산출물을 만듦
  • 두 에이전트가 코드 리뷰와 유사한 반복 작업을 수행해 기능 동작, Chromium·Google 스타일, 로컬 코드 관례 준수를 검사함
  • 테스트 작성 에이전트가 개발자 검토 전에 Chrome 지원 플랫폼과 구성 전반에서 테스트를 확인해 최대 수주의 시간을 절약함
  • 현재 대부분의 취약점에 LLM이 후보 수정을 생성함
  • Chrome 149와 150에서는 보안 버그 1,072개를 수정해 앞선 23개 마일스톤의 합계를 넘어섬
  • DeepMind·Project Zero와 협력한 Big Sleep과 CodeMender는 CI에 통합돼 모든 CL을 24시간마다 검사함
  • 5월 한 달 동안 치명적인 S1+ 문제를 포함해 20개 넘는 취약점이 프로덕션에 도달하기 전에 차단됨

패치 격차 단축과 업데이트 적용

  • 수정 코드가 공개 오픈소스 저장소에 들어간 뒤 사용자에게 배포되기 전까지 공격자가 이를 역공학해 악용할 수 있는 N-day 공격 구간을 패치 격차라고 함
  • 메인 트리에 반영된 수정이 대다수 사용자가 이용하는 Stable 채널에 도달하기까지 보통 수주가 걸림
  • 심각도에 따라 수정 사항을 현재 Stable 릴리스 브랜치에 직접 병합하고 새로운 충돌이나 회귀를 계속 감시함
  • 주요 Chrome 마일스톤을 2주 주기로 전환하면서 매주 보안 업데이트를 제공하고 있음
  • AI 기반 공격 속도에 대응하기 위해 주 2회 보안 릴리스도 시험 중임
  • Stable에 도달한 모든 보안 버그는 내부·외부 발견 여부와 관계없이 공개 문서화함
  • 수동 병목을 없애고 발견부터 공개까지의 시간을 줄이기 위해 패치에서 릴리스 노트와 CVE 설명을 자동 생성하는 작업을 진행함
  • Chrome은 2008년부터 새 바이너리를 백그라운드에서 내려받아 준비하고 다음 재시작 때 적용하는 자동 업데이트를 사용함
  • 분류·수정·테스트·배포에는 1~2일이 걸리지만, 사용자가 재시작할 때까지의 대기도 N-day 악용 위험에 크게 기여할 수 있음
  • 재시작은 작업을 방해하고 별도 일정을 잡아야 하므로 사용자가 미루기 쉬움
  • 사용자에게 재시작 부담을 넘기지 않기 위한 기능을 개발 중임
  • 동적 패치는 Chrome의 다중 프로세스 구조를 이용해 Renderer·GPU 같은 백그라운드 자식 프로세스를 새 바이너리로 순차 교체하며, 대부분의 경우 전체 브라우저 재시작을 없애는 것이 목표임
  • 복잡한 상황에서도 세션을 복원할 수 있도록 더 많은 상태를 로컬에 저장하는 방법을 검토함
  • 완전한 세션 복원이 보장되는 시점에 자동으로 재시작함
  • Chrome 150은 macOS에서 창이 모두 닫혔지만 앱이 백그라운드에 남아 있는 상태를 감지하고, 대기 중인 업데이트가 있으면 자동 재시작함
  • 장기적으로 지속적인 동적 패치와 방해가 적은 시점의 자동 재시작을 결합한 항상 최신 상태의 브라우저를 목표로 함
  • 기업 IT 관리자를 위한 권장 사항은 다음과 같음
  • RelaunchNotification 정책을 이용해 알림부터 정해진 기간 후 강제 재시작까지 단계적으로 적용함
  • 변경 사항을 검증해야 하는 민감한 환경에서는 Chrome Extended Stable Channel을 사용함
  • Chrome Enterprise Core 또는 Premium의 운영체제 독립 대시보드로 전체 브라우저 버전을 추적하고 업데이트를 세밀하게 관리함

C++ 방어와 Rust 전환

  • Chrome은 기존 C++ 취약점을 런타임에서 무력화하는 동시에 장기적으로 메모리 안전 언어로 전환하는 이중 전략을 사용함
  • Chromium 코드 대부분이 C++이므로 도구 체인과 런타임 완화가 즉각적인 1차 방어선임
  • 강화된 표준 템플릿 라이브러리와 MiraclePtr 계열 기술로 Use-After-Free(UAF) 취약점을 줄여 왔음
  • C++ 방어 로드맵은 세 축으로 구성됨
  • MiraclePtr·MiracleObject 확대
    • MiraclePtr를 Skia, ANGLE, Dawn, C++ 반복자, std:: 컨테이너로 확대함
    • MiracleObject는 국소적인 런타임 성능을 시간적 안전성과 교환해 GPU 메인 스레드 UAF 취약점의 최대 90%를 무력화하는 것이 목표임
  • std::span 전환
    • 포인터와 크기를 함께 사용하는 기존 구조를 컴파일러가 검사하는 std::span으로 바꿔 범위 밖 접근(OOB)을 제거함
    • Chrome 자체 코드의 97%가 엄격한 unsafe-buffer 경고와 함께 문제없이 컴파일되며, Skia·ANGLE·Dawn에도 요구 사항을 확대하고 있음
  • 구조·할당 강화
    • 메모리 할당 계산에 checked math를 적용해 정수 오버플로 경로를 막음
    • 포인터 포함 타입과 비포인터 타입을 엄격히 분리하는 추가 힙 파티셔닝으로 UAF 악용을 어렵게 함
  • C++ 런타임 완화는 향후 수년 안에 한계효용이 줄어들 것으로 봄
  • 런타임 검사는 컴파일 시점 보장보다 비용이 크며, 강하게 완화된 C++ 바이너리도 Rule of Two를 지키려면 성능을 제한하는 엄격한 샌드박스가 필요함
  • 장기적으로는 Rust 전환을 추진함
  • Rust 플라이휠: Chromium 기반 API와 도구를 Rust에 직접 제공하는 중앙 SDK를 구축해 새 구성요소에서 일상적으로 선택할 수 있게 함
  • 버그 밀집 영역 제거: 복잡한 데이터 파서, 이미지 코덱, 폰트 스택처럼 과거 버그 밀도가 높은 코드를 전략적으로 교체함
  • 고권한 모듈화: 새 모듈을 Rust로 작성해 브라우저 프로세스 같은 고권한 영역에서도 샌드박스 성능 비용 없이 복잡한 기능을 실행하도록 함
  • 브라우저 최상위 UI를 HTML·CSS·TypeScript로 구현해 기존 C++ 프레임워크 의존성을 더 줄이는 방안도 검토함

코드 제출 전에 취약점 차단

  • 전체 코드베이스를 주기적으로 스캔하는 방식만으로는 Chrome의 빠른 개발 속도를 따라가기 어려워 AI 검사를 코드 제출 시점 가까이에 배치함
  • CI와 커밋 큐(CQ)의 방어 모델은 변경분을 자동 검사함
  • std::span 전환 수정을 제안함
  • 댕글링 포인터를 표시함
  • 숫자 연산 안전성을 강제함
  • 독립적으로는 안전한 코드도 다른 위치의 작은 논리 변경과 결합하면 심각한 잠재 보안 문제가 될 수 있음
  • CQ 내의 지속적인 LLM 의미 분석은 전통적인 정적 분석이 놓치는 미묘하거나 복잡한 상호작용을 찾아 코드가 트리에 들어오기 전에 차단함

오픈소스 생태계와 외부 의존성

  • 웹 보안은 Chrome 자체뿐 아니라 오픈소스 프로젝트와 유지관리자의 대응 역량에도 의존함
  • Google은 유지관리자가 취약점 신고에 빠르게 대응할 도구와 지원을 확보하도록 Alpha-Omega 프로젝트에 다른 참여자들과 함께 1,250만 달러를 기부함
  • Akrites 프로젝트의 창립 회원으로 참여했으며, 중앙 취약점 신고 창구와 보안 사고 대응팀을 제공해 업스트림 유지관리자의 부담을 줄이는 것이 목표임
  • Chromium과 V8, BoringSSL, Skia, ANGLE, Dawn 같은 관련 프로젝트에는 2,300개가 넘는 외부 의존성이 있음
  • 이 가운데 약 1,700개가 Android 기기, 엣지 컴퓨팅 플랫폼, 대규모 클라우드 기업 스택 등 다양한 제품을 통해 사용자에게 배포됨
  • 자동 취약점 검사 파이프라인은 Google 내부 피드와 미국 정부의 NVD, 오픈소스 중심의 OSV 데이터를 수집함
  • 사후 모니터링만으로는 위험 격차가 남을 수 있어 모든 Chrome 외부 의존성을 최신 업스트림 버전으로 선제 갱신하는 자동 업데이트 파이프라인으로 옮기기 시작함
  • 자동화 과정에서는 GOSSIP 같은 프로젝트의 안전 신호를 이용해 외부 오픈소스 생태계의 다른 위험도 반영함

지속적으로 보호되는 브라우저

  • LLM으로 발견·수정되는 버그 수가 늘어나는 것은 실패가 아니며, 수정된 버그 하나마다 공격자가 이용할 발판이 하나씩 줄어듦
  • 발견과 수정만으로는 충분하지 않으며, 공격자가 악용하기 전에 수정본을 배포하고 사용자 환경에 적용해야 함
  • 더 빠른 릴리스, 동적 패치, 방해가 적은 시점의 자동 재시작과 구조적 방어를 결합해 사용자를 방해하지 않으면서 지속적으로 보호되는 Chrome을 지향함