随着 AI 帮助修复 1,072 个 Chrome 漏洞，Amazon 与 Google 的安全竞赛出现转向

Google 表示，AI 辅助安全工具帮助 Chrome 在 149 和 150 版本中修复了 1,072 个漏洞，为自动化防御树立了一个引人注目的新标杆。该总数超过了 Chrome 此前连续 23 个里程碑版本修复的安全漏洞总和。这一跃升让更广泛的 Amazon 与 Google 竞争不再只是云端模型之争，而变得更具现实意义。

真正的重点并不在于某个 AI 模型发现了大量可疑代码模式。Google 已组建了一套智能体体系，可协助发现、复现、分类、分配、修复、测试、发布和记录漏洞。人类开发者仍会审查候选修复方案，但自动化如今已触及流程的几乎每一个环节。

这改变了软件安全中的核心约束。过去，发现缺陷是一项成本高昂、专业性极强的工作，只能由规模有限的团队完成。如今，AI 生成发现结果的速度，已经超过组织能够安全验证、发布和部署相应修复的速度。

Amazon、Microsoft、Anthropic 及其他大型科技公司都面临同样的变化。它们的优势将越来越少地取决于是否拥有强大的模型，而更多地取决于能否围绕模型运行一条可信的安全流水线。

Google 修复 Chrome 1,072 个漏洞，重新定义补丁规模

Chrome 创纪录的修复数量表明，AI 辅助漏洞处理已从零散实验走向生产级工程实践。

Google 于 2026 年 7 月 30 日在对其 Chrome 安全流水线的详细说明中披露了这些数据。该公司称，Chrome 149 和 Chrome 150 共修复了 1,072 个安全漏洞。

此前连续 23 个 Chrome 里程碑版本的修复总数更少。一份独立报道将此前的数量定为 1,036 个，这意味着这两个版本的激增超过了约两年间的既有产出。

这些数字需要谨慎解读。它们并不意味着每个已修复漏洞都是由语言模型独立发现的，也不意味着全部 1,072 个漏洞都具有同等严重性或同样容易被利用。

不过，Google 更为有限的说法依然意义重大。如今，大语言模型会为进入其流程的大多数漏洞生成候选修复方案。AI 还支持发现、分类、复现、测试生成和问题路由。

这种区别很重要，因为漏洞管理是一条链路。当工程师无法从重复项、噪声或低风险加固机会中区分可被利用的缺陷时，一个产生数千条警报的检测器几乎无法提供有效保护。

Google 表示，其自动分类系统会先检查报告是否相关、完整且不重复，随后尝试在受影响的浏览器和操作系统配置上复现问题。

该流水线会补充元数据，包括预估严重程度以及缺陷首次进入代码库的时间点，最后将报告分配给负责的人类所有者。

开发者可以修订自动化的严重程度评估，也会审查智能体生成的候选补丁及其支撑材料。

这种结构让 1,072 这一数字比独立代码扫描器的输出更有意义。这些是进入稳定版 Chrome 发布渠道的修复，而不只是堆积在内部队列中的模型生成警告。

Google 估计，自动分类每月可节省数百个开发者工时。该公司还表示，测试编写智能体能够将涉及 Chrome 众多支持平台和配置的工作缩短数周。

一项发现展现了这种方法可能达到的深度。据报道，一套早期的 2026 年 Gemini 智能体框架发现了一个沙箱逃逸漏洞，该漏洞已在 Chrome 代码库中存在超过 13 年。

沙箱逃逸会让已被攻陷的浏览器内容跨越隔离边界，访问本应受到保护的资源。Google 表示，该漏洞可能诱使浏览器读取本地文件。

这个缺陷存在的时间之久，并不能证明 AI 始终优于经验丰富的安全研究人员。它表明，模型可以凭借不同的搜索策略、更广泛的历史上下文和更多次重复尝试，重新审视成熟代码。

Google 还报告称，其集成工具在 5 月阻止了超过 20 个漏洞进入生产环境，其中包括一个属于该公司最高严重性类别的问题。

因此，Amazon 与 Google 这一关键词背后的比较，远不止标题中的总量。它关乎哪家公司能够将模型接入真实代码库、测试、问题历史、审查系统和发布基础设施。

模型可以在数秒内提出补丁。但一个可靠的安全组织仍必须确认，该补丁修复的是正确的问题，同时不会破坏无关行为。

这一运营层面正是 Google 此次公告最具分量之处。它将 AI 安全呈现为受管理的生产系统，而不是一个生成推测性代码的聊天机器人。

Amazon 与 Google 的安全竞赛为何关乎流水线

竞争优势属于那些能在攻击者利用同一漏洞之前，将模型输出转化为经过审查并已部署的保护措施的组织。

Google 的系统建立在多年不断专业化的安全研究基础之上。2023 年，Chrome 工程师使用语言模型改进模糊测试，即向软件输入异常数据以暴露崩溃和不安全行为。

2024 年，Google Project Zero 开发了 Naptime，这一框架为语言模型提供了漏洞研究所需的工具。随后，Google DeepMind 和 Project Zero 推出了 Big Sleep，这一智能体发现了 Chrome V8 引擎和图形栈中的缺陷。

最新工作流已扩展到发现之外。修复智能体会生成多个候选补丁，另一个独立的评审智能体则评估这些选项，并为开发者准备材料。

修复智能体和评审智能体在审查循环中协作。随后，测试编写智能体会在开发者批准变更前，创建旨在覆盖 Chrome 支持环境的检查项。

这种分工更像一个安全工程团队，而非单一助手。每个智能体承担更狭窄的职责，而流水线在人类影响重大的节点保留人工审查。

Google 还建立了一个 Chrome 知识库，其中包含此前发现的漏洞和项目的 Git 历史。这些上下文有助于模型进行超越原始训练数据中模式的推理。

代码库级的 SECURITY.md 文件描述了信任边界和本地威胁假设。评审智能体会单独读取这些说明，从而降低对修复智能体原始推理的依赖。

由于模型输出具有非确定性，该公司会对同一代码反复运行模型。不同的运行可能探索另一条路径、发现另一种交互，或推翻此前的结论。

规模在 Chrome 中尤为重要。Google 表示，Chromium 及相关项目包含超过 2,300 个第三方依赖项，其中约 1,700 个会以某种形式触达用户。

这些依赖项包括 V8 JavaScript 引擎、Skia 图形库、ANGLE 图形转换层和 BoringSSL 加密库。浏览器漏洞可能源于这些边界之间的交互。

Google 计划将所有 Chrome 第三方依赖项纳入自动化更新流水线。这些流水线将使用内部信息源和公开资源（包括漏洞数据库）来识别可获得的上游修复。

正是在这里，Amazon 与 Google 的竞争演变为基础设施竞赛。两家公司都运营着大型云平台、庞大的软件产品组合，以及充满开源组件的供应链。

Amazon 与 Anthropic 也存在重大的战略关联，后者的模型和安全计划通过云基础设施触达开发者。然而，拥有模型访问权并不会自动带来 Google 在 Chrome 内部的集成深度。

Google 掌控着浏览器代码库、持续集成系统、发布流程、遥测数据、测试环境以及大量漏洞历史。这种组合提供的上下文，是外部模型供应商难以轻易复刻的。

DeepMind 更新近推出的网络安全模型进一步强化了这一点。Google 表示，Gemini 3.5 Flash Cyber 针对通过重复、低成本的模型调用来发现、验证和修复漏洞进行了优化。

该公司称，在一次固定调用次数的评估中，该模型确认发现了 55 个独特的 V8 问题。在 Google 的测试条件下，其主线 Gemini 模型发现了 47 个，而 Claude Opus 4.6 发现了 36 个。

这些是公司自行报告的基准测试结果，并非独立审计。Google 还指出，供应商的安全政策影响了哪些竞争对手版本能够完成评估。

不过，这一机制仍值得关注。规模更小的专用模型可以在广阔的搜索空间中重复运行，再通过智能体系统整合其工作成果。

这一方法将关注点从模型的最高智能水平，转向每单位计算和审查投入所带来的有效发现。安全团队需要的是广泛覆盖、可复现证据和可控的报告数量，而非优雅的解释。

Amazon 和其他云服务提供商将面临向企业客户提供可比流水线的压力。买家会询问一项服务能否发现缺陷、验证可达性、提出修复方案，并生成可靠测试。

他们还会询问源代码会流向何处、模型会保留什么，以及智能体能否联系外部系统。一种扩大代码暴露面的安全工具，可能会制造它承诺降低的风险。

Google 表示，其内部扫描模型运行在没有通用互联网访问权限的锁定机器上。网络请求会被拦截，并通过应用程序和目标地址允许列表加以控制。

子智能体无法修改本地系统，也无法访问指定源代码目录之外的文件。这些控制至关重要，因为自主安全分析将宝贵源代码与能够探索弱点的工具结合在一起。

因此，Amazon 与 Google 安全竞赛的下一阶段将取决于隔离与证据。仅凭模型分数无法回答一家企业是否应信任在敏感代码库中运行的智能体。

AI 改变发现和修复漏洞的经济学

核心变化在于经济性：自动化发现正让安全发现变得充裕，而人类判断仍然稀缺。

Chrome 工程总监 Doug Turner 告诉 TechCrunch，语言模型已经将漏洞发现转变为工业规模的自动化操作。报道的修复总量为这一说法提供了可见证据。

传统漏洞研究需要理解编程语言、操作系统、利用技术和目标架构的专家。这些技能仍然不可或缺，但模型如今可以以极低的边际成本重复执行部分搜索工作。

它们可以检查旧提交、比较组件间的模式、构造测试用例，并重新审视先前被排除的区域。它们也可以持续运行，而无需等待预定审计。

由此带来的生产力提升并不均衡。发现环节会率先扩展，因为生成一条可疑发现比证明该发现确实重要更容易。

可信的报告必须证明受影响的代码在现实条件下可达。报告应指出被违反的安全边界，并在相关构建版本上复现该行为。

随后，团队必须决定严重性和优先级。技术上有效的内存错误可能影响有限，而一个小型逻辑缺陷在与另一项弱点串联时，可能变得危险。

补丁生成提出了另一项证明标准。改动必须封堵漏洞路径，同时不能引入回归、削弱其他防御措施，或只是掩盖可观察到的症状。

随着软件规模增长，测试也变得更加困难。Chrome 运行于多种操作系统、处理器架构、设备类别和企业配置之上。

在一个测试环境中表现正确的补丁，可能会在其他环境中失效。自动化测试生成有所帮助，但生成的测试也可能固化模型的错误假设。

这正是 Google 使用相互独立的修复代理和审查代理的重要之处。独立上下文能够暴露单个代理可能从诊断阶段一路带入拟议修复方案的矛盾。

不过，多个代理并不等同于独立的人类审查者。它们可能共享训练偏差、误解同一套架构，或收敛于看似合理但并不完整的解释。

因此，这种经济变化带来了新的队列。安全组织过去拥有的代码量超过研究人员能够审查的范围；如今，它们越来越多地面对超出审查者能够有把握批准的发现和候选修复方案。

Google 的经历已经显示出这种压力。其 Chrome 安全团队表示，截至 2026 年 3 月收到的漏洞报告数量已超过整个 2025 年。

该公司调整了漏洞奖励计划，以便外部研究人员提交能够在内部发现之外带来额外价值的成果。它还寻求更容易进入自动化处理流程的报告。

这项政策转变向独立研究人员传递了一个重要信号。AI 可以承担常规模式发现工作，但创造性的利用方式与跨组件推理仍然很有价值。

人类研究人员可能会专注于复杂攻击链、非同寻常的信任假设，以及产品预期行为与实际行为之间的差距。这些领域更难被简化为反复的代码仓库扫描。

安全领域的劳动力市场也可能随之变化。初级分析师将减少手动补充普通工单的时间，而高级工程师则要对审查标准和架构决策承担更多责任。

开发者生产力将与信息管理同样依赖于模型访问能力。团队需要可搜索的记录，将发现结果、代码历史、威胁假设、测试结果、责任归属和发布决策关联起来。

缺少这些上下文时，AI 代理只能产出孤立的建议。有了这些信息，系统就能判断某项发现是否重复了旧报告，或是否与先前的设计选择冲突。

这一机制解释了为什么 amazon google 的比较不能被简化为哪家公司提供最强的通用模型。安全表现取决于能以机器速度使用的机构记忆。

最善于组织这些证据的公司，能让每一次模型调用都更具相关性。它也能为人工审查者提供更清晰的依据，以接受或拒绝自动化工作。

创纪录的修复数量并不能证明什么

大量已发布的修复令人鼓舞，但这并不能证明补丁质量、利用风险下降，或形成了持久的防御优势。

Google 已发布对其工作流程的详细说明，但一些重要指标仍不可得。该公司尚未披露这 1,072 个漏洞的完整发现来源构成。

它尚未公开区分由模型发现的漏洞、人类报告、传统模糊测试结果、依赖项更新或既有积压事项。它也未为总数设定统一的严重性分布。

这种缺失之所以重要，是因为漏洞数量可能汇集了截然不同的安全结果。封堵一条严重的远程代码执行路径，并不等同于修正一项影响较低的验证错误。

当团队改变分类或报告方式时，修复总数也可能上升。一个组织可能将同一项底层缺陷拆分为多个工单，或将相关发现合并为一次修复。

已发布的总数在有限意义上仍然真实，因为这些修复已进入 Chrome 里程碑版本。不过，它无法独立揭示究竟消除了多少风险。

Google 自己的表述也恰当地保留了互补方法。该公司表示，模糊测试仍然擅长发现由代码库不同部分之间的长距离交互所产生的缺陷。

人类研究人员仍通过 Chrome 的漏洞奖励计划参与这项战略。架构防御、内存安全语言和运行时保护仍然必不可少，因为发现单个缺陷从来无法保证完整覆盖。

最深层的担忧在于虚假的信心。AI 生成的补丁往往看起来逻辑严密，尤其是在附带看似可信的解释和通过的测试时。

补丁仍可能留下另一条可利用路径。它也可能引入现有测试未能覆盖的细微回归。

Google 仍让人类参与批准流程，但审查能力是有限的。如果候选修复方案的增长速度快于有经验审查者的供给，接受自动化工作的压力可能会削弱这一保障。

使用审查代理在一定程度上解决了这个问题。然而，Google 尚未发布涵盖误报、漏报漏洞、补丁回归和人工审查时间的独立比较。

其 Gemini 3.5 Flash Cyber 的结果同样为自行报告。该基准设计使用私有漏洞以减少训练数据污染，但外部研究人员无法完全复现这些私有测试。

部署限制揭示了另一项尚未解决的权衡。Google 最初通过 CodeMender 仅向政府和可信合作伙伴提供这款专用模型，理由是网络能力具有双重用途性质。

同一款为防御者发现漏洞的模型，也可以帮助攻击者定位并利用漏洞。DeepMind 报告称，该模型曾在一次内部演练中生成可靠的远程代码执行利用程序。

这种能力使广泛开放存在风险。然而，对其加以限制也会使先进的防御工具集中于大型组织，而较小的维护者仍在持续收到日益复杂的报告。

Google 正在支持开源响应能力，但维护者依然面临不对称局面。自动化代理可以持续搜索数千个项目，而一个小项目可能只有一名兼职审查者。

因此，更多发现可能暂时让生态系统变得更不安全。在每个下游用户获得更新前，公开修复可能已经暴露了底层弱点。

这一时期被称为补丁缺口：攻击者会逆向分析已发布的改动，并瞄准尚未修补的系统。更快的发现速度提升了缩短这一窗口的重要性。

Chrome 的公开安全更新表明，交付、内存安全和依赖项新鲜度仍是持续存在的工程问题。AI 并不能消除其中任何一项。

这一纪录也不意味着 Chrome 在发布前异常不安全。更高的修复数量可能反映出对早已存在的缺陷拥有了更好的可见性。

反过来，发现大量长期存在的漏洞也应防止人们自满。这个存在 13 年的沙箱问题表明，即便是成熟且经过严密审查的软件，也可能保留危险的假设。

这一教训不止适用于 Google。Amazon、Microsoft、Apple、Mozilla 以及企业软件供应商都维护着与较新组件相互作用的旧代码。

合理的解读既不是庆祝，也不是恐慌。AI 提升了可修复安全工作量的可见规模，但有关净风险降低的证据仍不完整。

更快的发现速度让发布速度成为新的战场

安全如今取决于补丁能否在对手重构并利用底层缺陷之前抵达正在运行的浏览器。

Google 将漏洞生命周期描述为五个阶段：发现、分流、修复、发布和安装。AI 加快了早期阶段，但只有最后一个阶段完成后，用户才会获得保护。

Chrome 的开源开发模式使发布时间尤其敏感。一旦安全修复进入公开代码，攻击者就可以检查改动，从中寻找有关漏洞行为的线索。

Google 表示，修复通常需要数周时间才能从主开发树进入稳定版渠道。严重修复则可以直接合并到活跃的稳定分支中。

Chrome 正在转向每两周发布一次主要里程碑版本的节奏，并配合每周安全更新。Google 还在试行每周两次安全发布。

更快的节奏缩短了暴露时间，但也给测试和企业变更管理带来更大压力。管理员通常需要在大规模设备部署浏览器改动前评估兼容性。

频繁发布也可能造成更新疲劳。当用户正在保留标签页、表单、通话或进行中的工作时，可能会推迟重启浏览器。

Chrome 会在后台下载并准备更新，但许多改动只有在重启后才会生效。Google 表示，当分流、修复、测试和发布仅需一两天时，这种延迟可能变得显著。

该公司正在研究动态补丁技术，即无需重启整个浏览器即可替换某些子进程。渲染器和图形进程是潜在目标，因为 Chrome 已通过多进程架构将它们分离。

Chrome 150 还引入了一项 macOS 行为：当有待处理更新且没有窗口保持打开时，浏览器会自动重启。目标是在干扰较小的时刻应用保护。

这些交付改进比表面上看起来更重要。一个能产出优秀修复方案的 AI 系统，无法在受保护的软件仍静置于磁盘上时胜过攻击者。

因此，企业团队应通过部署数据，而非仅凭发布公告来评估浏览器安全。它们需要了解哪些设备运行的是过期版本，以及这些设备落后了多久。

amazon google 的安全竞争同样延伸至这一运营层面。两家公司都服务于拥有分布式终端、云工作负载、软件依赖项和严苛可用性要求的组织。

胜出的平台将帮助客户把发现结果与责任归属、补丁验证、分阶段推出和可验证安装连接起来。缺少部署证据的发现，是一项尚未完成的安全任务。

Microsoft 的经验表明，这一趋势不限于浏览器。其 2026 年 7 月的大型安全发布受到关注，因为 AI 辅助流程与已解决漏洞数量的显著增加有关。

一篇Associated Press 分析也描述了大型 AI 公司日益努力将先进网络模型交给防御者。Amazon、Apple、Google 和 Microsoft 加入了一项与 Anthropic 相关、聚焦关键软件风险的倡议。

这并不是企业安全部门之间的简单竞赛。攻击者同样可以利用模型研究补丁、生成利用变体，并在相关产品中寻找相似弱点。

防御者保有若干结构性优势。它们掌控源代码仓库、测试基础设施、部署系统、历史漏洞记录和内部架构文档。

攻击者则拥有不对称的目标。防御者必须保护每一条重要边界，而攻击者只需要一条可用路径。

发布速度可以缩小这种失衡，但无法消除它。结构性预防仍然必不可少，因为没有任何组织能够可靠地在漏洞被利用前发现并修复每一个缺陷。

因此，Google 的长期战略包括用 Rust 替换高风险的 C++ 组件。Rust 是一种旨在于编译阶段避免多种内存错误的语言。

它还在扩展指针保护机制，并将不安全的“指针加长度”模式转换为由编译器检查的 span。Google 表示，如今 97% 的 Chrome 自有代码可在严格的不安全缓冲区警告下编译。

这些措施能够减少整类漏洞，而非逐个处理。AI 可以加快迁移进程，但持久的保护来自架构层面的变革。

下一个有意义的衡量标准将结合这两种方法。企业必须证明，智能体能够提升修复速度，同时结构性工作能降低进入生产环境的缺陷数量及其影响。

三个信号将表明 AI 安全是否真正有效

下一阶段应以补丁质量、部署延迟和持续的风险降低来评判，而不是又一个创纪录的漏洞数量。

第一个信号是 Google 每周发布两次安全更新的实践。这项试点将检验 Chrome 能否缩短补丁窗口，同时不会引发不可接受的崩溃、回归问题或管理员抵触。

成功的试点将强化 Google 的说法，即其整条流程能够随漏洞发现能力一同扩展。不断增长的积压或不稳定的发布则会表明，自动化只是把约束转移到了下游。

应关注从确认漏洞发现到稳定版更新被安装所需的时间。这一指标将分诊、审查、测试、发布及用户重启行为整合为一个实际结果。

第二个信号是关于 AI 生成补丁质量的独立证据。Google 已介绍了大量防护措施、批评智能体、测试系统和人工审查流程，但外部验证仍然有限。

有价值的披露应包括误报率、回归率、审查者耗时、严重性分布，以及模型提出的修复方案无需重大修改便获接受的比例。

这些数据将帮助企业采购方根据结果而非演示来比较安全智能体。它们也会揭示，专用网络安全模型究竟是在减少总工作量，还是只为专家生成更多待检查材料。

比较还应涵盖成功的补丁和遗漏的缺陷。一个能够发现常见模式、却忽视异常信任边界违规的系统，可能取得亮眼总数，却未覆盖最危险的攻击路径。

第三个信号是 Amazon、Microsoft、Anthropic 及其他供应商如何回应。它们的产品需要在模型推理、私有代码、测试、问题跟踪器、依赖关系情报和受控部署之间建立可比的连接。

Amazon 的立场尤其值得关注，原因在于其云服务覆盖范围及与 Anthropic 的关系。如果 Amazon 将先进的网络安全模型转化为面向日常开发团队、可审计的服务，amazon google 之间的竞争将更加激烈。

访问政策也将构成回应的一部分。高能力网络安全模型确实存在双重用途风险，但过于严格的分发可能使较小的开源项目缺乏足够的防御能力。

可信的行业应对方案必须将受控访问与对维护者的支持结合起来。否则，资金更充裕的攻击者和大型供应商将获得自动化能力，而关键社区项目则要承担报告负担。

读者还应关注漏洞总量是否最终下降。短期上升符合智能体发现多年累积缺陷的情况。

持续上升则可能有多种解释：模型可能不断发现更深层的问题，新代码引入缺陷的速度可能更快，或分类实践仍在持续扩大。

最有力的证据将是早期高发现率与进入生产环境的严重漏洞减少同时出现。Google 已开始在其持续集成和提交队列系统中扫描代码变更，以实现这一目标。

这些模型会在代码合入前标记悬空指针、数值安全问题和不安全的缓冲区模式。它们还利用语义分析识别传统静态检查可能遗漏的交互关系。

Google 表示，Big Sleep 和 CodeMender 每 24 小时对代码变更运行一次。将检测前移到提交阶段附近可以降低修复成本，因为开发人员仍然了解相关变更的上下文。

预防也能避免公开的补丁窗口。一个在进入生产环境前被拦截的漏洞，永远不需要紧急更新，也无需与逆向工程展开竞速。

对开发者而言，眼下的教训很实际。不要把模型生成的安全报告当作证据，也不要因为人类最先没有发现它就将其忽视。

应要求提供复现、明确的信任边界、影响评估、有针对性的测试、独立审查和部署证据。保留这些材料，以便后续智能体能够基于组织历史进行推理。

对于企业采购方，应询问智能体在哪里运行，以及它们可以访问哪些文件。还应询问网络请求是否被阻止、记录，或按目标地址加以限制。

还要询问服务如何处理源代码保留、模型训练、密钥暴露、生成的漏洞利用代码和智能体权限。围绕模型的安全控制应受到与模型本身同等严格的审查。

Google 的 1,072 项修复表明，AI 能够提升成熟安全组织的处理能力。但这并不能证明自主系统可以安全地取代该组织。

这一差异将决定 amazon google 安全竞赛的下一阶段。模型正变得充足，但可信审查、架构知识和快速部署能力仍然稀缺。

团队现在应审视自身从发现到安装的整条流程。他们能否复现自动化报告、审查候选修复方案、测试受影响环境，并证明用户已获得修复？

这个问题比下一个头条数字更重要。如果答案仍不清楚，AI 只是加快了发现速度，却没有完成防御。