Chromeの脆弱性1072件をAIで修正、アップデートと再起動も改善

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. ／ 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. ／ 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. — LLM活用の経緯と13年もののバグ、探索ハーネスの5つの改善、安全策、ファジングとの関係に関する記述より

We have partnered closely with Google DeepMind and Project Zero for years, including on BigSleep and CodeMender. These tools are natively integrated into our continuous integration (CI) system, running every 24 hours across all CLs to proactively detect security bugs. This integration has yielded significant results: in May alone, we blocked over 20 vulnerabilities from reaching production, including a critical S1+ issue. — BigSleepとCodeMenderのCI統合と5月の実績に関する記述より

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. — 従来の所要時間、自動トリアージの4段階、節約規模の見積もりに関する記述より

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: ／ 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. ／ 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. — 修正件数、外部報告の増加とVRPの見直しに関する記述より

Once a fix has landed and is visible in the public open source codebase, attackers can start to reverse engineer and exploit the bug before the fix reaches users’ machines — so called "N-day" attacks. This is commonly referred to as the “patch gap.” Since fixes committed to the main “tree” typically take weeks to reach the Chrome Stable channel (what the vast majority of our users run), minimizing this patch gap is a critical part of our strategy. ／ Based on their severity, security fixes are merged directly from the main “tree” into the active Chrome stable release branch, which is continuously monitored to prevent new crashes or regressions. ／ We are in the process of transitioning to a two-week cadence for major Chrome milestones, with weekly security updates. However, in the face of fast-moving, AI-powered attacks, our delivery cadence must accelerate even further. To meet this moment, we are piloting a shift to two security releases per week. — パッチギャップの説明と、配信頻度の引き上げに関する記述より

In 2008, Chrome pioneered the concept of silent, background software updates: new binaries are automatically downloaded and staged on disk with minimal user intervention. At the next restart of the browser, the update would be applied and the user would be protected. ／ However, compared to the 1–2 days it takes for triage, fix, test and release, the time spent waiting for the user to restart Chrome can be a significant contributor to N-day exploitation risk. ／ Investing in "dynamic patching" that will eliminate the need for a full browser restart in most cases. By leveraging Chrome’s multi-process architecture, dynamic patching sequentially replaces background child processes (like the Renderer and GPU) with updated binaries on the fly. ／ For example, in Chrome 150, we rolled out a change to take advantage of the unique application state on macOS where applications typically continue running in the background even after all windows are closed. Now, if Chrome detects a pending update while in this windowless state, it automatically restarts. — 静かな背景更新の導入、再起動待ちの危険性、動的パッチと自動再起動の取り組みに関する記述より

Our long-term vision is a browser that is always up-to-date – continuously and dynamically patched, and automatically restarted during opportune periods of minimal disruption. While we’re working on this, you can keep your Chrome up to date by clicking on the update message in the top right corner. ／ For enterprise customers looking to keep Chrome up to date, we recommend that IT admins: ／ Apply the RelaunchNotification policy which prompts users to restart Chrome to apply a pending update, escalating from a gentle reminder to a forced restart over a set timeframe. ／ Utilize the Chrome Extended Stable Channel for highly sensitive environments where software changes must be vetted. ／ Leverage the OS-agnostic dashboard provided by Chrome Enterprise Core or Premium to track fleet-wide browser versions and manage updates at a more granular level. — 利用者向けの更新方法と、企業の IT 管理者への推奨に関する記述より

Once a security bug enters the codebase, its life cycle proceeds as follows: ／ Our goal is for every one of these steps to happen as quickly as possible. ／ an increase in bugs found and fixed is not a sign of failure. Every bug found and fixed is one less foothold for an attacker. But discovering and fixing a bug is only half the battle — we must also ship the fix and apply the update for users faster than adversaries can exploit the bug — 脆弱性の一生と、発見・修正・適用の関係に関する記述より