得益于AI，谷歌在6月修复的Chrome漏洞比过去两年还多

# 每次更新都更强大：我们如何在人工智能时代让 Chrome 和网络更安全 来源：https://blog.google/security/chrome-stronger-with-every-update/ Chrome 如何利用 AI 改进漏洞发现、分类和修补。 --- --- 我们正经历软件安全行业的巨变。大型语言模型（LLM）正在解锁前所未有的自动化漏洞发现能力，其规模远超人类安全专家的极限，也要求我们采用新方法来领先攻击者一步。 这意味着要大规模部署 AI 模型，以比以往更快的速度发现并修复数百个安全漏洞，目标是实现更强的韧性和全面的修复。 以下是我们正在采取的措施。 ## **漏洞的一生** 有些软件漏洞具有安全影响。纯功能性 bug 可能只会导致令人沮丧的界面卡顿，而安全漏洞则可能被用来构建利用程序（exploit）。利用程序允许攻击者在受害者计算机上执行恶意操作，例如读取私人数据，或在用户不知情的情况下控制其机器。 一旦安全漏洞进入代码库，其生命周期如下： - 发现漏洞。 - 对漏洞进行分类（triage）。 - 修复漏洞。 - 发布包含修复的 Chrome 新版本。 - 重启 Chrome 并应用更新。 漏洞管理流程的各个步骤 我们的目标是让上述每一步都尽可能快速完成。 ### 发现漏洞 Chrome 安全团队使用 LLM 已有数年。2023 年，我们开发了利用 LLM 提高安全模糊测试覆盖率和性能的方法。2024 年，我们与 Project Zero 合作开展了 Naptime 项目，为 LLM 提供漏洞研究专用工具。2025 年，我们与 DeepMind 和 Project Zero 合作开展了 Big Sleep 项目，这是一个 AI 漏洞发现代理，成功在 V8 JavaScript 引擎和图形栈中发现了漏洞。 2026 年初，我们构建了一个代理框架，利用 Gemini 在更广泛的 Chrome 代码库中查找漏洞，效率更高且误报率更低。我们发现的其中一个漏洞是沙箱逃逸漏洞，它可能允许被入侵的渲染器欺骗浏览器读取本地文件——这个漏洞在我们的代码库中悄悄存活了超过 13 年！对我们许多人来说，这一刻巩固了 AI 驱动漏洞检测的潜力。 此后，我们通过以下方式改进了漏洞发现代理框架： - 增加对模型互操作性的支持，以利用开放权重模型和专有模型的各自优势。 - 构建 Chrome 知识库，包括之前发现的所有 CVE 以及 Chrome 的完整 Git 历史，以扩展 LLM 的推理能力，使其超越训练数据。 - 鼓励开发者添加 SECURITY.md 文件，帮助模型更好地理解信任边界，并准确建立威胁模型视图。 - 添加一个具有独立上下文的“评论家”代理，用于读取这些 SECURITY.md 文件。 - 引入多次在代码库上运行漏洞发现模型的能力，以应对模型的非确定性和模型随时间的改进。 我们构建所有这些功能时都将安全性放在首位，并设置了防护措施以降低 AI 意外行为的风险。我们的 AI 严格在静态状态下分析源代码，运行在锁定且无通用互联网访问权限的机器上。我们还为这些内部扫描使用专用设置，拦截所有网络请求，基于发起应用程序和目标采用严格白名单，阻止任何可疑模型活动。此外，我们绝不以无限制模式运行模型，并严格限制我们的子代理修改本地系统或访问指定源代码目录之外的文件。 AI 驱动的漏洞检测是对现有安全测试基础设施的补充。例如，模糊测试在发现由代码库中不同部分之间的长距离交互引起的漏洞，或需要看似无关操作组合的漏洞时，仍然特别有效。 我们还希望继续通过 Chrome 漏洞奖励计划（VRP）奖励外部研究人员的专业知识和创造力，以发现最具挑战性和影响力的漏洞。2026 年初，我们看到各类漏洞报告逐渐增加，但到 3 月，变化已经很明显：我们收到的漏洞报告数量超过了 2025 年全年的总和。这促使我们调整 VRP，引导研究人员专注于提交那些对我们内部发现具有补充价值、且易于被我们新自动化处理流程吸收的漏洞。 ### 对漏洞进行分类 随着我们使用 AI 驱动的工具发现更多安全漏洞，我们同时也在利用 AI 来扩展和自动化验证、分类及修复漏洞的工作。从历史上看，分类单个安全报告需要 5 到 30 分钟甚至更长时间，且主要依赖人类专家。我们越来越多地将分类流程转向一种自动化方法，将基于规则的系统与 AI 相结合，以提高吞吐量和准确性。 自动化分类流程分为四个关键阶段： 1. **过滤噪音。** 系统检查传入的 bug 是否为垃圾信息，确保其满足接收标准（例如，不是重复报告），并验证其是否清晰描述了 Chrome 安全漏洞。 2. **复现漏洞。** 接下来，系统检查是否存在概念验证。可复现的漏洞会在其影响的具体操作系统和浏览器版本上进行测试。基于此，系统会为 bug 附加更多细节，例如堆栈跟踪，以帮助确定修复方案。 3. **为报告补充元数据。** 系统为报告添加必要的元数据，例如漏洞首次引入的时间及其严重性评级。为了帮助此流程扩展，我们使严重性指南更加清晰且更容易自动应用。我们继续允许开发者在其认为严重性评级不正确时进行修改，并使用 SECURITY.md 文件添加上下文，以帮助模型推理安全边界。 4. **自动分配。** 系统自动将问题路由到正确的组件和人工负责人。 虽然难以精确衡量，但我们估计这一新流程每月可节省数百小时的开发者时间，让我们的团队能够专注于其他安全优先事项。 ### 修复漏洞 在 Google，开发者与安全团队共同承担优先修复安全漏洞的责任，但扩展漏洞发现规模同样需要可扩展的漏洞修复流程。 为实现这一目标，我们在整个过程中依赖多代理工作流： - 在初始构建步骤引入特定问题的上下文后，我们运行一个**修复代理**，它返回多个候选修复方案。 - 然后，**评论家代理**评估哪个方案最合适，并生成其他相关工件供开发者评估修复。 - **修复代理和评论家代理**在一个循环中运行，模拟典型的代码审查流程，以确保代码功能正常，并符合 Chromium 和 Google 风格指南以及其他本地代码约定。 - **测试编写代理**帮助为修复编写测试。这些代理可以确保测试在 Chrome 支持的所有平台和配置组合上通过——*在开发者审查修复之前*，从而节省多达数周的开发者时间。 目前，我们已经让 LLM 为大多数漏洞生成候选修复方案，大幅提高了近期 Chrome 版本中安全修复的速率： 近期 Chrome Stable 版本里程碑中修复的安全漏洞数量 图表显示近期 Chrome Stable 版本里程碑中修复的安全漏洞数量 在最近两个里程碑版本 Chrome 149 和 150 中，我们修复了 1072 个安全漏洞，超过了之前 23 个里程碑版本修复安全漏洞数量的总和。 我们多年来一直与 Google DeepMind 和 Project Zero 密切合作，包括 BigSleep 和 CodeMender 等项目。这些工具已原生集成到我们的持续集成（CI）系统中，每 24 小时在所有 CL 上运行，以主动检测安全漏洞。这一集成已取得显著成果：仅 5 月份，我们就阻止了超过 20 个漏洞进入生产环境，其中包括一个关键的 S1+ 问题。 ### 发布修复 一旦修复落地并在公共开源代码库中可见，攻击者就可以在修复到达用户机器之前开始对其进行逆向工程并利用该漏洞——即所谓的“N-day”攻击。这通常被称为“补丁缺口”。由于提交到主干“树”的修复通常需要数周才能到达 Chrome Stable 频道（我们绝大多数用户使用的版本），因此最小化这一补丁缺口是我们战略的关键部分。 根据严重性，安全修复会直接从主干“树”合并到活跃的 Chrome Stable 发布分支，该分支会持续监控以防止新的崩溃或回退。我们正在逐步过渡到每两周发布一个主要 Chrome 里程碑的节奏，并每周发布安全更新。然而，面对快速发展的 AI 驱动的攻击，我们的交付节奏必须进一步加快。为了应对这一时刻，我们正在试点每周两次安全发布。 即使在这种节奏下，适当的公开披露仍然至关重要。每个到达 Chrome Stable 的安全漏洞，无论内部发现还是外部报告，都会作为标准最佳实践被记录并公开披露。我们正在努力实现从安全漏洞修复中自动生成发布说明和 CVE 描述，以消除人工瓶颈，缩短从漏洞发现到公开披露之间的时间窗口。 ### 应用更新 2008 年，Chrome 开创了静默后台软件更新的概念：新二进制文件会自动下载并暂存在磁盘上，几乎无需用户干预。在浏览器下次重启时，更新会被应用，用户将受到保护。然而，与分类、修复、测试和发布所需的 1-2 天相比，等待用户重启 Chrome 所花费的时间可能成为 N-day 利用风险的重要来源。 人们有合理的理由推迟重启 Chrome。重启可能会中断工作，需要在任务之间安排时间，并且在任何给定时刻通常都不是最优先事项。为了消除这一摩擦，我们正在开创一些方法，将负担从用户身上转移，具体措施包括： - 投资“动态修补”技术，在大多数情况下无需完全重启浏览器。通过利用 Chrome 的多进程架构，动态修补可以依次用更新后的二进制文件替换后台子进程（如渲染器和 GPU），并在运行中完成。请持续关注我们在研究和开发该功能时的更多信息。 - 探索通过本地保存更多状态来确保即使复杂情况下也能无缝恢复会话的方法。 - 寻找合适的时机自动重启，同时保证无缝会话恢复。例如，在 Chrome 150 中，我们推出了一项变更，利用 macOS 上独特的应用状态——即使所有窗口都关闭，应用通常仍在后台继续运行。现在，如果 Chrome 在这种无窗口状态下检测到待应用的更新，它会自动重启。 macOS 上的无窗口自动重启 macOS 上的无窗口自动重启 我们的长期愿景是打造一个始终保持最新状态的浏览器——持续动态修补，并在干扰最小的合适时段自动重启。在我们努力实现这一目标的同时，您可以通过点击右上角的更新提示来保持 Chrome 处于最新状态。 对于希望让 Chrome 保持最新状态的企业客户，我们建议 IT 管理员： - 应用 RelaunchNotification 策略，该策略会提示用户重启 Chrome 以应用待处理更新，并在设定时间段内从温和提醒升级为强制重启。 - 利用 Chrome Extended Stable 频道，适用于必须审查软件变更的高度敏感环境。 - 利用 Chrome Enterprise Core 或 Premium 提供的与操作系统无关的仪表板，以更精细的粒度跟踪整个组织的浏览器版本并管理更新。 ## **防患于未然** 除了修复单个安全漏洞外，我们还在投资缓解和消除*整类*安全漏洞，并从一开始就防止它们进入代码库。随着 AI 编码技术的进步，我们相信有机会加速推进那些以前可能需要数年甚至永远无法启动的项目。 ### 内存安全缓解措施 Chrome 正在执行两层内存安全策略：加固我们的运行时环境以中和遗留的 C++ 漏洞，同时转向内存安全语言以实现长期架构韧性。 Chromium 代码库绝大部分仍使用 C++，因此即时工具链和运行时缓解措施是我们关键的第一道防线。我们长期以来一直优先考虑大规模内存安全工程，部署了加固的标准模板库，并开创了 MiraclePtr 系列等技术来中和释放后使用（UAF）漏洞。AI 驱动的漏洞检测只会进一步印证这类技术的必要性。 我们的 C++ 防御路线图聚焦于三大支柱： - **MiraclePtr 与 MiracleObject 扩展。** 通过 MiraclePtr 已经大幅减少了 UAF 漏洞，我们正在将该范式扩展到更多库，如 Skia、ANGLE、Dawn、C++ 迭代器和 std:: 容器。我们还在积极部署 MiracleObject，目标是在 GPU 主线程上中和高达 90% 的 UAF 漏洞，有意用局部运行时性能换取时间安全性。 - **Span 化。** 为了系统性地消除越界（OOB）空间安全错误，Chrome 正在进行大规模的“span 化”工作，将遗留的指针加大小结构迁移到编译器强制的 std::span 类型。目前，第一方 C