우리는 소프트웨어 보안 산업의 거대한 변화를 겪고 있습니다. 대규모 언어 모델 (LLMs)은 자동화된 취약점 발견 (vulnerability discovery)을 위한 전례 없는 능력을 열어주고 있으며, 인간 보안 전문가의 한계를 훨씬 뛰어넘어 확장되고 있으며, 공격자보다 앞서 나가기 위한 새로운 접근 방식을 요구하고 있습니다.

이는 더 큰 회복 탄력성과 포괄적인 복구 (remediation)를 달성하는 것을 목표로, 수백 개의 보안 버그를 그 어느 때보다 빠르게 찾아내고 수정하기 위해 AI 모델을 대규모로 배포하는 것을 의미합니다.

우리가 이를 어떻게 수행하고 있는지 소개합니다.

버그의 생애 (The Life of A Bug)

일부 소프트웨어 버그는 보안에 영향을 미칩니다. 순수하게 기능적인 버그는 짜증 나는 UI 프리징 (UI freeze)을 초래할 수 있지만, 보안 버그(또는 취약점 (vulnerability))는 익스플로잇 (exploit)을 구축하는 데 사용될 수 있습니다. 익스플로잇을 통해 공격자는 피해자의 컴퓨터에서 개인 데이터를 읽거나, 피해자가 모르는 사이에 기기를 제어하는 등 악의적인 행동을 수행할 수 있습니다.

보안 버그가 코드베이스 (codebase)에 유입되면, 그 생애 주기는 다음과 같이 진행됩니다:

• 버그가 발견됩니다.
• 버그가 분류 (triaged)됩니다.
• 버그가 수정됩니다.
• 버그 수정이 포함된 Chrome의 새로운 업데이트가 출시됩니다.
• Chrome이 재시작되고 업데이트가 적용됩니다.

Steps of the vulnerability management process

우리의 목표는 이 모든 단계가 가능한 한 빨리 일어나는 것입니다.

취약점 찾기

Chrome 보안 팀은 수년 동안 LLMs를 사용해 왔습니다. 2023년에 우리는 보안 퍼징 (security fuzzing) 커버리지와 성능을 높이기 위해 LLMs를 사용하는 방법을 개발했습니다. 2024년에는 Project Zero와 함께 Naptime을 작업하며 LLMs에 취약점 연구를 위한 특화된 도구를 제공했습니다. 그리고 2025년에는 DeepMind 및 Project Zero와 협력하여 Big Sleep을 개발했습니다. Big Sleep은 V8 JavaScript 엔진과 그래픽 스택에서 버그를 성공적으로 찾아낸 AI 취약점 발견 에이전트 (AI vulnerability discovery agent)입니다.

2026년 초, 우리는 Gemini를 사용하여 더 넓은 Chrome 코드베이스 전반에서 더 높은 효율성과 더 낮은 오탐률 (false positives)로 취약점을 찾을 수 있는 에이전트 하네스 (agent harness)를 구축했습니다. 우리가 발견한 버그 중 하나는 샌드박스 탈출 (sandbox escape) 버그로, 공격받은 렌더러 (renderer)가 브라우저를 속여 로컬 파일을 읽게 만들 수 있는 것이었습니다. 이 버그는 우리 코드베이스에서 13년 이상 조용히 살아남아 있었습니다! 우리 중 많은 이들에게 이 순간은 AI 기반 취약점 탐지의 잠재력을 확고히 하는 계기가 되었습니다.

그로부터 우리는 다음과 같은 방식으로 취약점 탐지 에이전트 하네스를 개선했습니다:

• 오픈 웨이트 (open-weights) 모델과 독점 (proprietary) 모델 모두의 고유한 강점을 활용하기 위해 모델 상호 운용성 (model interoperability) 지원을 추가했습니다.
• 이전에 식별된 모든 CVE와 Chrome의 전체 Git 히스토리를 포함한 Chrome 지식 베이스를 구축하여, LLM의 추론 능력을 학습 데이터 너머로 확장했습니다.
• 개발자들이 SECURITY.md 파일을 추가하도록 권장하여, 모델이 신뢰 경계 (trust boundaries)를 더 잘 이해하고 위협 모델 (threat model)에 대한 정확한 관점을 개발할 수 있도록 했습니다.
• 이러한 SECURITY.md 파일을 소비할 별도의 컨텍스트를 가진 "비판 (critic)" 에이전트를 추가했습니다.
• 모델의 비결정성 (non-determinism)과 시간에 따른 모델 개선을 고려하여, 코드베이스에 대해 취약점 탐지 모델을 여러 번 실행할 수 있는 기능을 도입했습니다.

우리는 이 모든 것을 안전을 염두에 두고 구축했으며, AI가 예기치 않게 동작할 위험을 완화하기 위한 가드레일 (guardrails)을 마련했습니다. 우리의 AI는 소스 코드를 엄격하게 정지 상태 (at rest)에서만 분석하며, 일반적인 인터넷 접속이 차단된 폐쇄된 머신에서 작동합니다. 또한, 우리는 이러한 내부 스캔을 위해 모든 네트워크 요청을 가로채고, 시작 애플리케이션과 목적지에 기반한 엄격한 허용 목록 (allowlists)을 사용하여 의심스러운 모델 활동을 차단하는 전용 설정을 활용합니다. 나아가, 우리는 모델을 제한 없는 모드로 절대 실행하지 않으며, 서브 에이전트 (subagents)가 로컬 시스템을 수정하거나 지정된 소스 코드 디렉터리 외부의 파일에 접근하는 것을 엄격히 제한합니다.

AI 기반 취약점 탐지 (AI-powered vulnerability detection)는 우리의 기존 보안 테스트 인프라를 보완합니다. 예를 들어, 퍼징 (fuzzing)은 코드베이스의 서로 다른 부분 간의 장거리 상호작용(long-range interactions)에서 발생하는 버그나, 겉보기에 관련 없어 보이는 작업들의 조합이 필요한 버그를 찾는 데 여전히 특히 효과적입니다.

우리는 또한 Chrome 취약점 보상 프로그램 (Chrome Vulnerability Reward Program, VRP)을 통해 가장 까다롭고 영향력 있는 취약점을 찾아내는 외부 연구자들의 전문성과 창의성에 대해 계속해서 보상하고자 합니다. 2026년 초에는 모든 카테고리의 버그 보고가 점진적으로 증가했으나, 3월에 이르러서는 그 변화가 뚜렷해졌습니다. 우리는 2025년 전체 기간 동안 받았던 것보다 더 많은 버그 보고를 받았습니다. 이로 인해 우리는 연구자들이 내부적으로 발견하는 것들에 추가적인 가치를 더하고, 우리의 새로운 자동화된 처리 파이프라인(automated processing pipelines)에 쉽게 수용될 수 있는 버그 제출에 집중할 수 있도록 VRP를 변경하게 되었습니다.

취약점 분류 (Triaging vulnerabilities)

AI 기반 도구로 더 많은 보안 취약점을 발견함에 따라, 우리는 동시에 AI를 사용하여 버그를 검증(validating), 분류(triaging), 수정(fixing)하는 과정을 확장하고 자동화해 왔습니다. 역사적으로 단일 보안 보고서를 분류하는 데는 5분에서 30분 이상이 소요되었으며, 주로 인간의 전문 지식에 의존해 왔습니다. 우리는 처리량(throughput)과 정확도를 높이기 위해 규칙 기반 시스템(rule-based systems)과 AI를 결합한 자동화된 접근 방식으로 분류 프로세스를 점점 더 전환하고 있습니다.

자동화된 분류 프로세스는 네 가지 주요 단계로 나뉩니다:

노이즈 필터링 (Filtering out the noise). 시스템은 유입된 버그가 스팸인지 확인하고, 접수 기준(예: 중복 여부)을 충족하는지 확인하며, Chrome 보안 취약점을 명확하게 설명하고 있는지 검증합니다.

버그 재현 (Reproducing bugs). 다음으로, 시스템은 개념 증명 (Proof of Concept, PoC)을 확인합니다. 재현 가능한 버그는 해당 버그가 영향을 미치는 특정 운영 체제(OS) 및 브라우저 버전에서 테스트됩니다. 이를 바탕으로 시스템은 수정 작업을 돕기 위해 스택 트레이스 (Stack trace)와 같은 추가 세부 정보를 버그에 첨부합니다.

메타데이터를 통한 보고서 보강 (Enriching the report with metadata). 시스템은 버그가 처음 발생한 시점 및 심각도 등급 (Severity rating)과 같은 필수 메타데이터를 보고서에 추가합니다. 이 프로세스의 확장성을 높이기 위해, 당사는 심각도 가이드라인을 더 명확하게 만들고 자동으로 적용하기 쉽게 개선했습니다. 개발자가 심각도 등급이 잘못되었다고 판단할 경우 이를 수정할 수 있도록 계속 허용하고 있으며, SECURITY.md 파일을 사용하여 모델이 보안 경계 (Security boundaries)에 대해 추론할 수 있도록 문맥을 추가할 수 있게 하고 있습니다.

자동 할당 (Automatic assigning). 시스템은 이슈를 올바른 컴포넌트 (Component)와 담당 개발자에게 자동으로 라우팅합니다.

정확하게 측정하기는 어렵지만, 당사는 이 새로운 프로세스를 통해 매달 수백 시간의 개발자 시간을 절약하고 있으며, 이를 통해 팀이 다른 보안 우선순위에 집중할 수 있도록 하고 있다고 추정합니다.

취약점 수정 (Fixing vulnerabilities)

Google 전반에 걸쳐 개발자들은 보안 팀과 함께 보안 수정의 우선순위를 정하는 책임을 공유하지만, 버그 발견의 규모를 확장하려면 그에 못지않게 확장 가능한 버그 수정 프로세스가 필요합니다.

이를 달성하기 위해, 당사는 전 과정에서 멀티 에이전트 워크플로 (Multi-agent workflows)에 의존합니다:

• 특정 이슈로부터 컨텍스트 (Context)를 가져오는 초기 빌드 단계 이후, 우리는 여러 개의 후보 수정안을 반환하는 **수정 에이전트 (fixing agent)**를 실행합니다. - 그 다음 **비평 에이전트 (critic agent)**가 어떤 수정안이 가장 적합한지 평가하며, 개발자가 수정 사항을 검토할 수 있도록 다른 관련 아티팩트 (Artifacts)를 생성합니다. - **수정 및 비평 에이전트 (fixing and critic agents)**는 전형적인 코드 리뷰 (Code review) 프로세스를 모방한 루프 내에서 작동하여, 코드가 기능적으로 동작하고 Chromium 및 Google 스타일 가이드라인뿐만 아니라 기타 로컬 코드 컨벤션 (Code conventions)을 준수하는지 확인합니다. **테스트 작성 에이전트 (Test-writing agents)**는 수정 사항에 대한 테스트 작성을 돕습니다. 이 에이전트들은 개발자가 수정 사항을 검토하기 전에, 테스트가 Chrome이 지원하는 모든 플랫폼 및 구성 범위 전체에서 작동하는지 확인할 수 있어 개발 시간을 최대 몇 주까지 절약해 줍니다.

이 시점에서 우리는 대부분의 취약점 (Vulnerabilities)에 대해 LLM이 후보 수정안을 생성하도록 하고 있으며, 이는 최근 Chrome 릴리스의 보안 수정 속도를 극적으로 높였습니다:

최근 Chrome Stable 릴리스 마일스톤 (Milestones)에서 수정된 보안 버그 수

Graph showing number of security bugs fixed in recent Chrome Stable release milestones

지난 두 마일스톤인 Chrome 149 및 150에서 우리는 1,072개의 보안 버그를 수정했으며, 이는 이전 23개 마일스톤 전체에서 수정된 보안 버그의 총합을 넘어선 수치입니다.

우리는 BigSleep 및 CodeMender를 포함하여 수년간 Google DeepMind 및 Project Zero와 긴밀히 협력해 왔습니다. 이러한 도구들은 우리의 지속적 통합 (CI) 시스템에 네이티브하게 통합되어, 모든 CL (Changelists)에 대해 24시간마다 실행되며 보안 버그를 선제적으로 탐지합니다. 이러한 통합은 상당한 결과를 낳았습니다. 지난 5월 한 달 동안에만, 우리는 심각한 S1+ 이슈를 포함하여 20개 이상의 취약점이 프로덕션 (Production)에 도달하는 것을 차단했습니다.

수정 사항 배포

수정 사항이 반영되어 공개 오픈 소스 코드베이스(open source codebase)에서 확인할 수 있게 되면, 공격자들은 수정 사항이 사용자의 기기에 도달하기 전에 버그를 역공학 (reverse engineer)하고 악용하기 시작할 수 있습니다. 이를 소위 "N-day" 공격이라고 합니다. 이는 흔히 "패치 격차 (patch gap)"라고 불립니다. 메인 "트리 (tree)"에 커밋된 수정 사항이 Chrome Stable 채널(대다수의 사용자가 사용하는 버전)에 도달하는 데는 보통 몇 주가 걸리기 때문에, 이 패치 격차를 최소화하는 것이 우리 전략의 핵심적인 부분입니다.

보안 수정 사항은 심각도에 따라 메인 "트리 (tree)"에서 활성 Chrome stable 릴리스 브랜치로 직접 병합되며, 새로운 충돌(crash)이나 회귀(regression)를 방지하기 위해 지속적으로 모니터링됩니다. 우리는 주요 Chrome 마일스톤(milestone)을 2주 단위의 주기로 전환하고 주간 보안 업데이트를 제공하는 과정에 있습니다. 하지만 빠르게 진화하는 AI 기반 공격에 맞서기 위해, 우리의 전달 주기(delivery cadence)는 더욱 가속화되어야 합니다. 이러한 상황에 대응하기 위해, 우리는 주 2회 보안 릴리스를 제공하는 시범 운영을 진행하고 있습니다.

이러한 속도에도 불구하고, 적절한 공개 공시 (public disclosure)는 여전히 가장 중요합니다. 내부에서 발견되었든 외부에서 보고되었든, Chrome Stable에 도달하는 모든 보안 버그는 표준적인 베스트 프랙티스 (best practice)에 따라 문서화되어 공개적으로 공시됩니다. 우리는 수동 병목 현상을 제거하고 취약점 발견과 공개 공시 사이의 간격을 단축하기 위해, 보안 버그 수정 사항으로부터 릴리스 노트 (release notes) 및 CVE 설명을 자동으로 생성하는 작업을 진행하고 있습니다.

업데이트 적용

2008년, Chrome은 조용하고 백그라운드에서 이루어지는 소프트웨어 업데이트 개념을 개척했습니다. 이는 사용자의 개입을 최소화하면서 새로운 바이너리 (binaries)를 자동으로 다운로드하여 디스크에 스테이징 (staged)하는 방식입니다. 브라우저를 다음에 재시작할 때 업데이트가 적용되어 사용자가 보호받게 됩니다. 하지만 분류 (triage), 수정, 테스트 및 릴리스에 소요되는 1~2일과 비교했을 때, 사용자가 Chrome을 재시작하기를 기다리는 시간은 N-day 악용 위험의 상당한 원인이 될 수 있습니다.

사용자들이 Chrome 재시작을 미루는 데에는 이해할 만한 이유가 있습니다. 재시작은 흐름을 끊을 수 있고, 작업 사이에 일정을 잡아야 하며, 어떤 순간에도 최우선 순위가 되는 경우는 드뭅니다. 이러한 마찰을 제거하기 위해, 우리는 다음과 같은 방식으로 사용자에게 지워지는 부담을 덜어주는 선구적인 방법들을 시도하고 있습니다.

• 대부분의 경우 브라우저 전체 재시작이 필요 없도록 하는 "동적 패치 (dynamic patching)"에 투자하고 있습니다. Chrome의 멀티 프로세스 아키텍처 (multi-process architecture)를 활용하여, 동적 패치는 백그라운드 자식 프로세스(Renderer 및 GPU 등)를 업데이트된 바이너리로 실시간으로 순차 교체합니다. 이 기능을 연구 및 개발함에 따라 더 자세한 내용을 곧 확인하실 수 있을 것입니다.
• 더 많은 상태를 로컬에 저장함으로써, 복잡한 경우에도 원활한 세션 복구 (session restore)를 보장할 수 있는 방법을 탐색하고 있습니다.
• 원활한 세션 복구를 보장할 수 있는 적절한 시점에 자동으로 재시작하는 방법을 찾고 있습니다. 예를 들어, Chrome 150에서는 모든 창이 닫힌 후에도 애플리케이션이 일반적으로 백그라운드에서 계속 실행되는 macOS의 고유한 애플리케이션 상태를 활용하도록 변경 사항을 배포했습니다. 이제 Chrome은 창이 없는 상태에서 대기 중인 업데이트를 감지하면 자동으로 재시작합니다.

macOS에서의 창 없는 자동 재시작

Zero window auto-restart on macOS

우리의 장기적인 비전은 항상 최신 상태를 유지하는 브라우저입니다. 즉, 지속적이고 동적으로 패치되며, 방해가 최소화되는 적절한 시기에 자동으로 재시작되는 브라우저입니다. 저희가 이 작업을 진행하는 동안에는, 오른쪽 상단의 업데이트 메시지를 클릭하여 Chrome을 최신 상태로 유지할 수 있습니다.

Chrome을 최신 상태로 유지하고자 하는 기업 고객의 경우, IT 관리자에게 다음 사항을 권장합니다: