7.0
热点
AI SCORE
编程提效2026-07-31 15:29
Google 用 AI 一月修复漏洞超两年总和
Hacker News#AI编程#安全修复#Chrome
Editor brief · 编辑速览
Google 利用 AI 在 6 月修复的 Chrome 漏洞数量超过过去两年总和。直观展示 AI 在大规模代码库安全修复中的显著效能，具有实践参考价值。
我们正经历软件安全行业的巨大转变。大语言模型（LLM）为自动化漏洞发现释放了前所未有的能力，远超人类安全专家的能力上限，需要采取新的方法来保持领先于攻击者。
这意味着大规模部署 AI 模型来发现和修复数百个安全缺陷，速度比以往任何时候都快，目标是实现更强的韧性和全面的补救。
以下是我们的做法。
某些软件缺陷具有安全隐患。纯功能性的缺陷可能导致令人沮丧的 UI 冻结，但安全缺陷（或漏洞）可被用来构建漏洞利用。漏洞利用允许攻击者在受害者的计算机上执行恶意操作，例如读取私密数据或在不知情的情况下控制其机器。
一旦安全缺陷进入代码库，其生命周期如下所示：
我们的目标是让这些步骤尽可能快速地进行。
Chrome 安全团队多年来一直在使用 LLM。2023 年，我们开发了使用 LLM 增加安全模糊测试覆盖范围和性能的方法。2024 年，我们与 Project Zero 合作开发了 Naptime，为 LLM 提供了专门的漏洞研究工具。2025 年，我们与 DeepMind 和 Project Zero 合作开发了 Big Sleep，一个成功在 V8 JavaScript 引擎和图形栈中发现缺陷的 AI 漏洞发现智能体。
2026 年初，我们构建了一个使用 Gemini 的智能体框架，在整个 Chrome 代码库中以更高的效率和更低的误报率发现漏洞。我们发现的一个缺陷是一个沙箱逃逸漏洞，会允许被破坏的渲染器欺骗浏览器读取本地文件——这个缺陷在我们的代码库中已经存在超过 13 年了！对我们许多人来说，这个时刻证实了 AI 驱动的漏洞检测的潜力。
从那时起，我们通过以下方式改进了漏洞发现智能体框架：
我们在构建所有这些时都考虑了安全因素，并实施了护栏来减轻 AI 意外行为的风险。我们的 AI 严格在静态源代码上进行分析，在缺乏通用互联网访问的锁定机器上运行。我们还为这些内部扫描使用了专用设置，可以拦截所有网络请求，根据发起应用程序和目标采用严格的白名单，阻止任何可疑的模型活动。此外，我们从不在不受限制的模式下运行模型，并严格限制子智能体修改本地系统或访问指定源代码目录外的文件。
AI 驱动的漏洞检测补充了我们现有的安全测试基础设施。例如，模糊测试在发现源于代码库不同部分之间的长程交互的缺陷，或需要看似无关的操作组合的缺陷时特别有效。
我们还希望继续通过 Chrome 漏洞奖励计划（VRP）奖励外部研究人员在发现最具挑战性和影响力的漏洞方面的专业知识和创意。2026 年初，我们看到所有类型的缺陷报告都逐渐增加，但到 3 月，转变变得明显：我们收到的缺陷报告比整个 2025 年还要多。这促使我们改变 VRP，将研究人员的重点放在补充我们内部发现的缺陷提交上，以及易于被我们新的自动化处理流水线所使用的缺陷。
随着我们使用 AI 驱动的工具发现更多安全漏洞，我们同时使用 AI 来扩展和自动化验证、分类和修复缺陷。从历史上讲，对单个安全报告进行分类需要 5 到 30 分钟或更长时间，主要依靠人类专业知识。我们一直在逐步将分类流程转向自动化方法，该方法将基于规则的系统与 AI 相融合，以提高吞吐量和准确性。
自动分类流程分为四个关键阶段：
虽然很难精确测量，但我们估计这个新流程每月为开发者节省数百小时的工作量，使我们的团队能够专注于其他安全优先事项。
在整个 Google，开发者与安全团队共享安全修复优先级的责任，但扩展缺陷发现需要同样可扩展的缺陷修复流程。
为实现这一点，我们依赖全程的多智能体工作流：
此时，我们有 LLM 为大多数漏洞生成候选修复，大幅提高了最近 Chrome 发布中的安全修复速率：
在最后两个里程碑 Chrome 149 和 150 中，我们修复了 1072 个安全缺陷，超过了之前 23 个里程碑中修复的安全缺陷总数。
我们多年来与 Google DeepMind 和 Project Zero 密切合作，包括在 Big Sleep 和 CodeMender 上的合作。这些工具本地集成到我们的持续集成（CI）系统中，每 24 小时在所有 CL 中运行一次，主动检测安全缺陷。这种集成取得了显著的成果：仅在 5 月，我们就阻止了超过 20 个漏洞进入生产环境，包括一个关键的 S1+ 问题。
一旦修复被合并并在公开开源代码库中可见，攻击者就可以开始对缺陷进行逆向工程并在修复到达用户机器前进行利用——所谓的"N-day"攻击。这通常被称为"补丁间隙"。由于提交到主"树"的修复通常需要数周时间才能到达 Chrome 稳定版渠道（我们大多数用户运行的版本），最小化这个补丁间隙是我们策略的关键部分。
根据其严重性，安全修复从主"树"直接合并到活跃的 Chrome 稳定发布分支中，该分支受到持续监控以防止新的崩溃或回归。我们正在过渡到两周的 Chrome 主要里程碑周期，每周进行安全更新。然而，面对快速发展的 AI 驱动的攻击，我们的交付节奏必须加快。为了应对这一时刻，我们试图转向每周两次的安全发布。
即使有这样的速度，适当的公开披露仍然是首要任务。每一个进入 Chrome 稳定版的安全漏洞，无论是内部发现还是外部报告，都会作为标准最佳实践进行文档记录并公开披露。我们正在努力自动生成发布说明和来自安全漏洞修复的 CVE 描述，以消除手动瓶颈并缩短漏洞发现和公开披露之间的时间窗口。
2008 年，Chrome 开创了静默、后台软件更新的概念：新二进制文件会自动下载并在磁盘上暂存，用户干预最少。在浏览器下一次重启时，更新会被应用，用户就会得到保护。然而，相比修复、测试和发布所需的 1-2 天，等待用户重启 Chrome 所花费的时间可能会大幅增加 N 日漏洞利用的风险。
人们有充分的理由延迟重启 Chrome。重启可能会造成中断，需要在任务之间安排时间，而且很少是任何时刻的首要任务。为了消除这种摩擦，我们正在开创新的方式来转移用户的负担：
投资开发"动态补丁"，在大多数情况下消除完整浏览器重启的需求。通过利用 Chrome 的多进程架构，动态补丁可以按顺序动态替换后台子进程（如渲染器和 GPU）为更新的二进制文件。请继续关注我们在研究和开发此功能时的最新进展。
探索通过在本地保存更多状态，即使在复杂情况下也能确保无缝会话恢复的方式。
寻找在能够保证无缝会话恢复时自动重启的合适时机。例如，在 Chrome 150 中，我们推出了一项变更，利用 macOS 上的独特应用状态，其中应用通常即使在所有窗口关闭后仍在后台继续运行。现在，如果 Chrome 在这种无窗口状态下检测到待处理的更新，它会自动重启。
Zero window auto-restart on macOS
我们的长期愿景是一个始终保持最新的浏览器——持续动态补丁，并在最小中断时机自动重启。在我们开发此功能的同时，你可以通过点击右上角的更新消息来保持 Chrome 最新。
对于想要保持 Chrome 最新的企业客户，我们建议 IT 管理员：
应用 RelaunchNotification 策略，该策略提示用户重启 Chrome 以应用待处理的更新，在设定的时间框架内从温和提醒升级到强制重启。
为高度敏感的环境利用 Chrome Extended Stable Channel，其中软件变更必须经过审查。
利用 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 漏洞，故意用局部运行时性能换取时间安全。
Spanification。为了系统地消除越界（OOB）空间安全错误，Chrome 正在进行大规模"spanification"工作，将传统的指针和大小构造迁移到编译器强制的 std::span 类型。目前，97% 的第一方 Chrome 代码在严格的不安全缓冲区警告下编译得很干净。我们现在正在推动这些要求向下游，将 spanification 扩展到基础代码库，如 Skia、ANGLE 和 Dawn。
结构和分配加强。我们正在为与内存分配相关的计算集成检查数学以阻止整数溢出路径。同时，Chrome 正在实现额外的堆分区级别，以严格分离包含指针的类型和非指针类型，以增加利用 UAF 漏洞的难度。
虽然 C++ 安全增强提供了即时的保护，我们相信运行时缓解将在未来几年内遭遇递减边际收益。运行时检查本质上比编译时保证更昂贵，即使是大量缓解的 C++ 二进制文件也需要严格的、性能限制的沙盒来符合两条规则（Rule of Two）。
长期解决方案是将代码库转向内存安全的语言，如 Rust，专注于以下核心原则：
Rust 飞轮。不能期望开发人员完全吸收在新语言生态系统中工程的速度摩擦。因此，我们正在构建一个集中的 Rust SDK，将基础 Chromium API 和工具直接暴露给 Rust。我们的目标是将 Rust 转变为新组件的常规、无摩擦的工程选择。
有针对性的"漏洞窝点"消灭。Rust 正在战略性地部署，以替换表现出高历史漏洞密度的代码段（如复杂的数据解析器、图像编解码器和字体栈）。
启用高特权模块化。通过用 Rust 编写新的模块化组件，Chrome 可以在高特权进程（如浏览器进程）内安全地执行复杂功能，而无需沙盒的性能损失，打破传统 C++ 架构的约束。
除了 Rust，我们也在探索使用 HTML、CSS 和 TypeScript 实现浏览器的顶级用户界面等选项，以进一步减少对传统 C++ 框架的依赖。
代码库的批量扫描跟不上 Chrome 的高流量开发速度。为了解决这个问题，我们也在部署 AI 驱动的漏洞查找能力，以尽可能接近代码提交时间来识别和防止漏洞。作为 Chrome 持续集成（CI）和提交队列（CQ）管道的一部分，这些防御模型自动扫描差异以防止新漏洞，通过执行诸如建议 spanification 修复、标记悬挂指针和强制执行数值安全等操作。
此外，大规模软件工程中的一个主要挑战是"潜在安全问题"。在隔离状态下安全而强大的代码可能会被完全不相关的、树中其他地方的小逻辑变更转变为关键漏洞。通过在 CQ 内利用持续的、LLM 驱动的语义分析，Chrome 可以在这些复合风险着陆之前将其截获，捕捉传统静态分析遗漏的微妙或复杂交互。
保持网络安全不仅仅涉及保护 Chrome。谷歌长期以来一直是开源项目和社区的支持者，以确保所有用户获得更好的安全成果。最近，谷歌与其他公司一起向 Alpha-Omega 项目捐赠 1250 万美元，以支持使维护者能够获得他们需要的工具和支持，以快速响应漏洞报告。谷歌也是 Akrites 项目的创始成员，该项目旨在通过为漏洞报告和安全事件响应团队提供集中的交易所来降低上游维护者的负担。
在 Chrome 团队，我们深切地感受到这份责任——Chromium 项目是全球规模最大的开源项目。为了更直观地说明这项挑战的庞大规模，Chrome 在 Chromium 以及 V8 JavaScript 引擎、BoringSSL 加密库和 Skia、ANGLE、Dawn 等基础图形组件相关项目中，拥有超过 2,300 个第三方依赖。其中约 1,700 个会以某种形式交付给用户，并广泛融入从 Android 设备、边缘计算平台到大型云端企业技术栈的各种产品之中。
为了及时修补这些依赖，我们依靠自动化漏洞扫描流水线。这些流水线会从 Google 内部数据源以及多个外部监控数据源中摄取数据，其中包括美国政府的国家漏洞数据库（NVD）和专注于开源软件的 Open Source Vulnerabilities（OSV）数据库。
如今，仅依赖被动监控比以往任何时候都更容易留下危险的风险缺口。由于及时掌握漏洞及其补丁的最佳方式，是让第三方依赖始终保持最新，因此从今年开始，我们会逐步将 Chrome 的所有第三方依赖迁移至自动化更新流水线，主动将其滚动升级到最新的上游版本。自动化始终需要护栏，因此我们还将使用 Google Open Source Security Intelligence Platform（GOSSIP）等项目提供的安全信号，确保将第三方开源软件生态系统中的其他风险也纳入考量。
尽管 LLM 给软件安全带来的这种剧烈变化可能令人震惊，但发现并修复的漏洞数量增加并不意味着失败。每发现并修复一个漏洞，攻击者就少了一个立足点。然而，发现并修复漏洞只是战斗的一半——我们还必须赶在对手利用漏洞之前，更快地交付修复并为用户应用更新；同时投资于能够缓解或消除整类漏洞的项目。通过加快发布节奏、动态修补以及适时重启，我们正朝着打造一款能够持续获得保护、同时又不打扰用户的浏览器迈进。
不可否认，AI 时代加剧了软件安全领域的威胁态势，但通过将快速部署机制与深层结构性防御相结合，我们正在确保优势牢牢掌握在防守者手中。由此，Chrome 和更广泛的 Web 将随着每一次更新变得更加安全。