필사 모드: AI 如何在 6 月一个月内修复两年份的 Chrome 漏洞 —— 读懂 1,072 这个数字

• 引言 —— 1,072 对 1,036
• 一条谱系 —— 从 2023 年的模糊测试目标生成到 2026 年的智能体测试框架
• 为什么偏偏是庞大 C++ 代码库里的内存安全漏洞
• 这个数字说明了什么，又没说明什么
• 瓶颈从发现转移到了部署
• 没有 Chrome 规模的团队真正能照搬的东西
• 结语 —— 发现得多，说明它们一直都在
• 参考资料

引言 —— 1,072 对 1,036

2026 年 7 月 30 日，谷歌发布了一篇题为 Stronger with every update 的安全博客。核心数字有两个。6 月发布的 Chrome 149 和 150，仅这两个里程碑版本修复的安全漏洞就有 1,072 个。而在此之前的两年里，23 个里程碑版本合计修复的是 1,036 个。

其中一个漏洞是沙箱逃逸 —— 被攻陷的渲染进程可以骗过浏览器读取本地文件 —— 而且是一个在代码库里潜伏了 13 年以上的漏洞。Chrome 工程总监 Doug Turner 对 TechCrunch 表示，团队正在"应用 Gemini 这类模型来主动修复漏洞，并抢在攻击者之前行动"。

面对这样的数字，通常会出现两种错误反应：要么全盘照收，得出"AI 解决了安全问题"的结论；要么一概斥为营销话术。这两种反应对实际工作都没什么帮助。本文想做的是三件事 —— 弄清楚背后真正在运转的机制是什么，厘清这个数字对代码质量说明了什么、没说明什么，以及没有 Chrome 那种规模的普通团队究竟能照搬其中哪些部分。

一条谱系 —— 从 2023 年的模糊测试目标生成到 2026 年的智能体测试框架

这个结果不是凭空出现的，而是四年积累的结果。按照谷歌公告里给出的顺序梳理如下。

2023 年，编写模糊测试目标。 Chrome 安全团队开始用 LLM 扩大模糊测试(fuzzing)的覆盖范围。思路很简单 —— 模糊测试的产出不取决于 fuzzer 本身，而取决于测试框架(harness)，而手写测试框架既枯燥又因项目而异，于是干脆交给 LLM 来做。OSS-Fuzz 一方公开的结果 相当具体：应用到 300 多个 C/C++ 项目后，覆盖率提升了 30%，272 个项目新增覆盖了 37 万多行代码，并且发现了 26 个若没有 LLM 生成的测试目标就不可能被发现的漏洞。其中之一是 OpenSSL 的 CVE-2024-9143，一个在 20 年、数十万小时的模糊测试中都幸存下来的越界读写漏洞。

这一阶段的循环以四个步骤的形式公开，可以直接照搬 —— 编写测试框架初稿，编译并让模型修复编译错误，运行并修复运行时问题，持续运行的同时让模型对崩溃进行分类。

2024 年，Naptime。 与 Project Zero 合作，转向让 LLM 拥有漏洞研究工具(调试器、代码浏览器、执行环境)的方向。这是"阅读代码并进行推理"的路线。

2025 年，Big Sleep。 DeepMind 与 Project Zero 合作，实际在 V8 JavaScript 引擎和图形栈中发现了漏洞。

2026 年初，Gemini 智能体测试框架。 一套扫描整个 Chrome 代码库、同时着重降低误报的测试框架上线。公告里描述的设计颇有意思：只在纯静态状态下分析代码，在断网的隔离机器上运行，网络请求通过严格的白名单拦截。模型的不确定性靠对同一代码库多次扫描来抵消，并把全部历史 CVE 和 git 提交记录作为知识库接入，让模型能参考"这个项目里的漏洞过去长什么样"。随后由处于独立上下文中的评审智能体对发现结果进行评估。

发现之后的流程也是自动化的。分诊(triage)分四个阶段 —— 过滤垃圾信息和重复项以确认与安全相关，用概念验证进行复现，填充引入时间和严重程度等元数据，再自动分配给对应组件的负责人。修复阶段同样由修复智能体和评审智能体跑一个模拟代码评审的循环，测试编写智能体则在开发者评审之前就编写好跨平台测试并附上。谷歌估计仅分诊自动化这一项每月就节省了数百个开发者工时，同时也自己加了一句保留意见 ——"精确测量很困难"。

为什么偏偏是庞大 C++ 代码库里的内存安全漏洞

要判断这个成果是否可复现，得看问题本身的性质。内存安全漏洞的搜寻恰好占了四个对 LLM 格外有利的条件。

第一，判定是机械化的。 只要在经过 ASan、MSan、UBSan、LeakSanitizer 插桩的二进制文件上出现崩溃报告，那就是一个无可争辩的漏洞，不需要人工判断。这一点之所以关键，是因为基于 LLM 的自动化最大的弱点就在于对自身输出的自我评判。而消毒器(sanitizer)是模型之外的裁判，不管模型的说辞多么有说服力，都改变不了结果。

第二，复现用例很便宜。 在模糊测试中，漏洞的证据就是一段字节流。可以保存、自动最小化，并原样附加为回归测试。不需要像逻辑漏洞那样描述"某个特定账户在特定时刻以特定顺序发起请求"这种场景。

第三，漏洞的形态是局部且重复的。 缺少边界检查、释放后使用(use-after-free)、类型混淆，这些都是在几行代码范围内就能辨认的模式。而且 Chrome 有 20 年的 CVE 和提交历史，"这个项目里这一类漏洞长什么样"的训练素材早已积累起来。这也是谷歌把历史上全部 CVE 和 git 记录整个塞进知识库的原因。

第四，攻击面极其庞大。 Chrome 要解析这世界上所有不可信的输入 —— 图片、字体、视频编解码器、网络协议、JavaScript。解析器越多，意味着模糊测试能发挥作用的面就越多。

反过来说，在不具备这四个条件的领域，同样的方法就不会那么好用。权限检查缺失、违反业务规则、消毒器抓不住的竞态条件、设计层面的缺陷 —— 这些都没有机器 oracle 可用。所以把这次公告解读成"AI 让安全实现了自动化"是错的。准确的说法应该是：在机器能够评分的漏洞类别里，搜索成本骤降了。

这个数字说明了什么，又没说明什么

1,072 是一个真实的数字，也确实有意义。每发现并修复一个漏洞，攻击者手里就少一个立足点。不过，这个数字究竟衡量的是什么，需要精确地界定清楚。它是一个发现率指标，而不是缺陷密度指标。

这张表的右列，与 Hacker News 讨论里提出的质疑几乎完全重合。被反复提起的问题是"自动修复中有多少被回退、又有多少引入了新漏洞"，有条评论把这份公告总结为"把一切顺利的都数了一遍，一切可能出岔子的一个都没数"。Chrome 团队的工程师没有在那个帖子里回应。

这里我想再补充一条方法论上的提醒。比较单位是里程碑版本，而里程碑版本的长度正在变化。 之前两年的 23 个里程碑大致是每月一次的节奏，而 6 月一个月就出了两个。而且谷歌在同一份公告里还宣布，要把主版本发布节奏压缩到两周一次，推行每周一次的安全更新，并试点每周两次的安全发布。发布越频繁，"每个里程碑修复数"这个分母就会持续变动。如果想做时间序列上的比较，需要的是按单位时间归一化后的数值，而这份公告里没有这个数字。

还有一条最重要的解读。发现了很多漏洞，恰恰意味着这些漏洞一直都在那里。 那个 13 年历史的沙箱逃逸就是证据。这份公告与其说是"Chrome 的代码在 6 月变好了"的证据，不如说更接近于"我们此前究竟有多少东西没找出来"的证据。而且，同样的工具攻击者也能用。

瓶颈从发现转移到了部署

这份公告里对从业者最有用的部分，其实并不是 1,072 这个数字本身，而是谷歌接下来改动了什么。

漏洞发现成本一旦下降，瓶颈会立刻向下游转移。发现的速度超过修复的速度，修复的速度又超过部署的速度。在 Chrome 里，一个修复从主分支流到稳定分支需要数周时间。就算发现速度提升 10 倍，只要这一段时间不变，用户实际获得保护的时点几乎不会提前。

所以谷歌的应对措施集中在发布流水线这一侧 —— 把主版本周期缩短到两周、推出每周安全更新、试点每周两次的安全发布、把 CVE 和发布说明的生成自动化(这说明此前人力正是瓶颈所在)，以及研究无需完整重启就能替换后台进程的动态补丁技术。谷歌自己也承认最后这一项还处于研究阶段。

与此同时，结构性防御也在持续推进 —— 让 97% 的一方 Chrome 代码在开启严格 unsafe-buffer 警告的情况下编译的"span 化"(spanification)工作、在分配计算中应用 checked math、把指针和非指针分离的堆分区(heap partitioning)、让释放后使用失效的 MiraclePtr 与 MiracleObject，以及在解析器、编解码器、字体这类漏洞密度高的区域有选择地引入 Rust 的计划。这里谷歌写下了一句相当坦诚的话 ——预计运行时缓解手段会在几年内触及收益递减。这正是它转向语言层面解决方案的原因。

没有 Chrome 规模的团队真正能照搬的东西

谷歌的资源没法效仿，但这条流水线里确实有些便宜又可移植的片段。顺序很关键。

1. 先上消毒器，再上 LLM。 这一切的前提是要有一个机器 oracle。如果是 C/C++ 项目，在 CI 里加一条 ASan 和 UBSan 构建，要排在接入任何 AI 工具之前。没有裁判就接上智能体，抓不到什么东西，只会让误报越堆越多。

# 先建立 oracle。没有它，后面的一切都没有意义。
cmake -B build-asan -DCMAKE_BUILD_TYPE=RelWithDebInfo \
  -DCMAKE_C_FLAGS="-fsanitize=address,undefined -fno-omit-frame-pointer" \
  -DCMAKE_CXX_FLAGS="-fsanitize=address,undefined -fno-omit-frame-pointer"
cmake --build build-asan -j

# 光是把现有测试跑一遍消毒器构建，通常就能跑出点东西
ASAN_OPTIONS=detect_leaks=1 UBSAN_OPTIONS=print_stacktrace=1 ctest --test-dir build-asan

2. 不要让模型去找漏洞，而是让它写测试框架。 这正是谷歌在 2023 年实际做的事，也是投入产出比最好的一点。把解析器、解码器、序列化代码这类"接收字节流的函数"列成清单，对每一个都让模型生成一份测试框架初稿，再跑那个由模型修复编译错误和运行时错误的四步循环即可。这里模型的输出会立刻被编译器和 fuzzer 验证，幻觉很难存活下来。

3. 分诊自动化要排在修复自动化之前。 谷歌节省时间最多的地方就在这里。去重、复现、严重程度估计、负责人分配的判定标准都很明确，自动化一旦出错造成的损失也小。相反，补丁自动生成一旦出错就会变成新的漏洞，所以应该放到后面再接入。

4. 对自动生成的补丁强制要求回归测试。 这正是 Chrome 流水线里测试编写智能体扮演的角色。把补丁和测试绑定在同一次改动里，加入一道机械化检查步骤，确认测试在没有补丁的情况下会失败。没有这一步，就没办法区分"号称修好了的补丁"和"真正修好的补丁"。

5. 让评审角色处在独立的上下文中。 让同一个会话去评判自己的输出，确认偏差会原样保留下来。谷歌是这么做的，前面提到的大规模迁移案例用的也是同一种结构。

6. 不要把指标定为发现数量。 应该看回退率、误报率、从发现到部署的时间，以及严重程度分布。发现数量在工具上线的第一个月必然飙升，之后必然回落。把那条曲线当成成果来汇报，第二个月就没什么可交代的了。

7. 部署路径要同步改进。 这才是 Chrome 案例真正的教训。把发现量提升 10 倍而发布节奏原地不动，增长的不是安全性，而是尚未部署的补丁库存。

结语 —— 发现得多，说明它们一直都在

1,072 既是 Chrome 在 6 月变得更安全的证据，也是这些漏洞在此之前一直存活着的证据。那个 13 年历史的沙箱逃逸漏洞把这句话总结得最到位。而降低了发现成本的工具，并非只有防守方能用。

把要带走的东西压缩成三行。

• 这个成果之所以成立，不是因为模型聪明，而是因为消毒器这个机器判定 oracle 早就在那里了。没有 oracle 的漏洞类别，同样的方法用不上。
• 最便宜、最能照搬的部分不是漏洞检测，而是测试框架生成和分诊自动化。两者的输出都能被机器立刻验证。
• 发现成本一旦下降，瓶颈就会转移到部署环节。这正是谷歌把发布周期压缩到两周、并研究动态补丁的原因，也是这份公告里最有实操价值的部分。

一旦把漏洞数量当成成功指标，这个指标就只会在刚上线工具的那个月好看。如果想让它经得起时间考验，不如去数回退率和部署耗时。

参考资料

• Stronger with every update —— 谷歌 Chrome 安全公告原文 (2026-07-30)
• TechCrunch — Google says it fixed more Chrome bugs in June than over the past two years (2026-07-30)
• BleepingComputer —— 对 1,072 个修复与工具谱系的梳理
• OSS-Fuzz — Fuzz target generation using LLMs(覆盖率提升 30%，四步循环)
• Hacker News —— 针对该公告的怀疑论讨论
• 用 AI 迁移代码库的实操流程 —— 评审智能体与机器判定结构(相关文章)