AI로 13년 된 취약점 발견…크롬 보안 강화

Chrome Stronger with every update: How we’re making Chrome and the web safer in the AI Era Jul 30, 2026 | x.com Facebook LinkedIn Mail Copy link How Chrome is using AI to improve vulnerability discovery, triage, and patching. Chrome Security Team Share x.com Facebook LinkedIn Mail Copy link We’re living through a massive shift in the software security industry. Large Language Models (LLMs) are unlocking unprecedented capabilities for automated vulnerability discovery, scaling far beyond the limits of human security expertise, and requiring new approaches for staying ahead of attackers. This means deploying AI models at scale to find and fix hundreds of security bugs, faster than ever, with the goal of achieving greater resilience and comprehensive remediation. Here’s how we’re doing it. The Life of A Bug Some software bugs have security implications. While a purely functional bug might result in a frustrating UI freeze, a security bug (or vulnerability) can be used to build an exploit. Exploits allow attackers to perform malicious actions on a victim’s computer, such as reading private data, or controlling their machine without their knowledge. Once a security bug enters the codebase, its life cycle proceeds as follows: The bug is found. The bug is triaged. The bug is fixed. A new update of Chrome with the bug fix is released. Chrome is restarted and the update is applied. Our goal is for every one of these steps to happen as quickly as possible. Finding vulnerabilities The Chrome Security team has been using LLMs for years. In 2023 we developed ways to use LLMs to increase security fuzzing coverage and performance . In 2024, we worked with Project Zero on Naptime , giving LLMs specialized tools for vulnerability research. And in 2025, we collaborated with DeepMind and Project Zero on Big Sleep , an AI vulnerability discovery agent that successfully found bugs in the V8 JavaScript engine and graphics stack. In early 2026, we built an agent harness that used Gemini to find vulnerabilities across the broader Chrome codebase with higher efficiency and lower false positives. One of the bugs we found was a sandbox escape that would allow a compromised renderer to trick the browser into reading local files — a bug that quietly survived in our codebase for more than 13 years! For many of us, this moment cemented the potential of AI-powered vulnerability detection. From there, we improved on our vulnerability finding agent harness by: Adding support for model interoperability to leverage the unique strengths of both open-weights and proprietary models. Building a knowledge base of Chrome, including all previously identified CVEs and Chrome’s entire Git history, to extend the LLMs reasoning capacity past its training data. Encouraging developers to add SECURITY.md files, which help models better understand trust boundaries and develop an accurate view of the threat model. Adding a “critic” agent with a separate context to consume these SECURITY.md files . Introducing the ability to run vulnerability finding models over the codebase multiple times to account for model non-determinism and model improvements over time. We’ve built all of this with safety in mind, and have put in place guardrails to mitigate the risk of AI behaving unexpectedly. Our AI analyzes source code strictly at rest, operating on locked-down machines that lack general internet access. We also utilize a dedicated setup for these internal scans that intercepts all network requests, employing strict allowlists based on the initiating application and destination, blocking any suspicious model activity. Furthermore, we never run models in an unrestricted mode, and we strictly limit our subagents from modifying the local system or accessing files outside of designated source code directories. AI-powered vulnerability detection complements our existing security testing infrastructure. For example, fuzzing continues to be especially effective at finding bugs that arise from long-range interactions between disparate parts of our codebase, or those requiring a combination of seemingly unrelated operations. We also want to continue to reward external researchers for their expertise and creativity in finding the most challenging and impactful vulnerabilities via the Chrome Vulnerability Reward Program (VRP). In early 2026, we saw a gradual increase in all categories of bug reports, but by March, the shift was apparent: we received more bug reports than we had in the entirety of 2025. This led us to change our VRP to focus researchers on bug submissions that are additive to what we are finding internally, and easily ingestible by our newly automated processing pipelines. Triaging vulnerabilities As we discover more security vulnerabilities with AI-powered tools, we’ve simultaneously used AI to scale and automate validating, triaging, and fixing bugs. Historically, triaging a single security report took anywhere from 5 to 30 or more minutes, and relied primarily on human expertise. We have been increasingly shifting our triage process towards an automated approach that blends rule-based systems with AI to increase throughput and accuracy. The automated triage process is broken down into four key phases: Filtering out the noise. The system checks if an incoming bug is spam, ensures it meets intake criteria (e.g. is not a duplicate), and verifies that it clearly describes a Chrome security vulnerability. Reproducing bugs. Next, the system checks for a proof of concept. Reproducible bugs are tested on the specific operating system and browser versions they affect. Based on this, the system attaches further details such as stack traces to the bug to help inform the fix. Enriching the report with metadata. The system adds essential metadata to the report, such as when the bug was first introduced and its severity rating. To help this process scale, we’ve made our severity guidelines clearer and easier to apply automatically. We continue to allow developers to modify the severity rating if they believe it is incorrect, and to add context to help models reason about security boundaries using SECURITY.md files. Automatic assigning. The system automatically routes the issue to the correct component and human owner. While it's hard to measure precisely, we estimate that this new process is saving hundreds of hours of developer time per month, allowing our team to focus on other security priorities. Fixing vulnerabilities Across Google, developers share the responsibility of prioritizing security fixes with the security team, but scaling bug discovery requires an equally scalable bug fixing process. To achieve this, we rely on multi-agent workflows throughout: After initial build steps that bring in context from a specific issue, we run a fixing agent that returns multiple candidate fixes. A critic agent then evaluates which would be the best fit, producing other relevant artifacts for developers to evaluate the fix. The fixing and critic agents work in a loop that mimics a typical code review process to ensure that code is functional and compliant with Chromium and Google style guidelines, as well as other local code conventions. Test-writing agents help write tests for fixes. These agents can ensure that tests work across the full array of Chrome supported platforms and configurations before a developer reviews the fix, saving up to weeks of developer time. At this point, we have LLMs generating candidate fixes for most vulnerabilities, dramatically increasing the rate of security fixes in recent Chrome releases: Number of security bugs fixed in recent Chrome Stable release milestones In the last two milestones, Chrome 149 and 150, we have fixed 1072 security bugs, surpassing the total number of security bugs fixed across the prior 23 milestones combined. We have partnered closely with Google DeepMind and Project Zero for years, including on BigSleep and CodeMender. These tools are natively integrated into our