Google fixed more Chrome bugs in June than over the past two years, thanks to AI

得益于人工智能，谷歌在六月份修复的 Chrome 漏洞数量超过了过去两年总和

Chrome Stronger with every update: How we’re making Chrome and the web safer in the AI Era Chrome 每次更新都更强大：我们如何在人工智能时代让 Chrome 和网络更安全

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. 我们正经历着软件安全行业的一场巨大变革。大语言模型（LLMs）正在释放自动化漏洞发现的前所未有的能力，其规模远远超出了人类安全专家的极限，这也要求我们采取新的方法来领先于攻击者。

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 新版本)
• Chrome is restarted and the update is applied. (重启 Chrome 并应用更新)

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. Chrome 安全团队多年来一直在使用大语言模型。2023 年，我们开发了利用大语言模型提高安全模糊测试覆盖率和性能的方法。2024 年，我们与 Project Zero 合作开发了 Naptime，为大语言模型提供了专门的漏洞研究工具。2025 年，我们与 DeepMind 和 Project Zero 合作开发了 Big Sleep，这是一个人工智能漏洞发现代理，成功在 V8 JavaScript 引擎和图形堆栈中发现了漏洞。

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. 2026 年初，我们构建了一个代理框架，利用 Gemini 在更广泛的 Chrome 代码库中以更高的效率和更低的误报率发现漏洞。我们发现的其中一个漏洞是沙箱逃逸，它允许受损的渲染器诱骗浏览器读取本地文件——这个漏洞在我们的代码库中悄无声息地存在了超过 13 年！对于我们许多人来说，这一刻巩固了人工智能驱动的漏洞检测的潜力。

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. (建立 Chrome 知识库，包括所有先前识别的 CVE 和 Chrome 的整个 Git 历史记录，以将大语言模型的推理能力扩展到其训练数据之外。)
• Encouraging developers to add SECURITY.md files, which help models better understand trust boundaries and develop an accurate view of the threat model. (鼓励开发人员添加 SECURITY.md 文件，这有助于模型更好地理解信任边界并建立准确的威胁模型视图。)
• Adding a “critic” agent with a separate context to consume these SECURITY.md files. (添加一个具有独立上下文的“评论家”代理来处理这些 SECURITY.md 文件。)
• 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. 我们在构建这一切时始终将安全放在首位，并设置了护栏以降低人工智能出现意外行为的风险。我们的人工智能严格分析静态源代码，并在缺乏通用互联网访问权限的受限机器上运行。我们还为这些内部扫描使用了专门的设置，拦截所有网络请求，根据发起应用程序和目标采用严格的白名单，阻止任何可疑的模型活动。此外，我们从不在不受限制的模式下运行模型，并严格限制我们的子代理修改本地系统或访问指定源代码目录之外的文件。

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. 随着我们利用人工智能工具发现更多安全漏洞，我们同时也利用人工智能来扩展和自动化验证、分类和修复漏洞的过程。过去，处理一份安全报告通常需要 5 到 30 分钟甚至更长时间，且主要依赖于人类专家的经验。我们正越来越多地将分类流程转向一种结合了基于规则的系统与人工智能的自动化方法，以提高处理效率和准确性。

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. (过滤噪音。系统检查传入的漏洞报告是否为垃圾信息，确保其符合接收标准（例如不是重复报告），并验证其是否清晰地描述了 Chrome 安全漏洞。)
• 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. (利用元数据丰富报告。系统会向报告中添加必要的元数据，例如漏洞首次引入的时间及其严重性评级。为了帮助这一流程扩展，我们使严重性准则更加清晰，且更容易自动应用。)