Google Agentic Code Security 将漏洞检查前移至提交之前

Google 表示，其智能体安全系统现会扫描数亿行基础设施代码中的每一项变更，在存在漏洞的变更进入生产环境之前完成检查。Google 的 agentic code security 流程结合了 AI 扫描、结构验证、夜间测试以及人工审查的补丁。Google 称，这一流程每月可阻止数百个漏洞进入其代码库或生产系统。

关键变化不只是 Google 使用 Gemini 寻找漏洞。Google 已将 AI 辅助安全检查纳入每项拟议代码变更所必经的流程。这挑战了开发者汇集大量变更后再进行大范围安全扫描的既有模式。

随着 OpenAI、Anthropic、Cisco、Microsoft 和 Google 不断扩展用于发现或修复软件漏洞的 AI 系统，这一消息随之而来。这些系统能够提升防御能力，但也带来棘手的运营问题：只有团队能够验证、排序并安全修复漏洞，发现更多漏洞才有帮助。

Google Agentic Code Security 在代码落地前启动

Google 正以由单项代码变更触发的精细审查，替代部分滞后的、覆盖全代码库的安全工作。

Google 于 2026 年 9 月 18 日披露了这一系统。该公司称，该系统覆盖支撑其全球网络、AI 系统及面向用户服务的基础设施。

每项拟议变更都会在 Google 工程师已使用的开发工具中接受提交前扫描。提交前扫描指的是在代码成为共享代码库一部分之前进行检查。该系统将安全反馈更视为编译器警告或可读性审查，而非一次独立审计。

这一时点很重要，因为单项变更所包含的内容少于整个代码库。智能体可以检查被修改的代码、其直接依赖项及相关威胁假设，而无需处理每个无关组件。

精细审查也让扫描器获得一个更有价值的问题。系统不再询问庞大代码库中是否存在可疑内容，而是询问某一项变更是否引入了可被利用的安全弱点。

Google 对该流程的描述分为若干阶段：

• 轻量级智能体检查每项拟议代码变更。

• 局部威胁模型为受影响组件提供安全上下文。

• 分诊智能体检查疑似攻击路径在结构上是否可达。

• 夜间集成测试寻找由多项变更相互作用引发的问题。

• 修复智能体准备拟议修复方案及支持证据，供人工审查。

该公司称，这一流程覆盖数亿行已部署的基础设施代码，并表示系统每月可拦截数百个漏洞。这些数字来自 Google，尚未经独立审计。

“发现”与“阻止”之间的差别值得关注。如果工程师忽略扫描器的许多警告，或将其中大多数认定为误报，扫描器即使产生大量警告，也未必能改善安全性。

Google 表示，其建议在内部被广泛采纳。不过，公告并未公布采纳比例、严重性分布，或与传统扫描器的对比结果。

该公司披露的最强性能指标涉及其分诊阶段。Google 表示，该智能体的准确率超过 92%，且响应时间不足一分钟。

准确率衡量的是报告发现中有多少真实存在，而不是工具发现了多少已有漏洞。一个系统可以发出准确的警报，同时仍然漏掉难以发现的漏洞。Google 未披露召回率，而该指标有助于衡量后一问题。

Google 还称，在某些情况下，其误报率低至 3%。但“在某些情况下”这一表述限制了读者对该数字的普遍适用性。不同语言、组件、漏洞类别和威胁模型可能产生显著不同的结果。

尽管如此，这一架构指向软件安全领域的一项重要变化。Google 正将 AI 审查视为持续性的生产控制措施，而非独立安全团队偶尔使用的助手。

这使得该公告比又一项模型基准测试更具意义。该系统的价值取决于它能否在开发者提交代码前的短暂窗口内作出可信判断。

更快的漏洞发现让修复团队承压

AI 正在降低漏洞发现的成本，但补救工作仍受测试、审查和部署能力限制。

安全团队长期以来一直在应对发现与修复之间的不平衡。静态分析器、模糊测试器、研究人员和事件报告能够识别的问题，往往多于维护者可以立即调查的问题。

AI 加剧了这种不平衡。智能体能够反复检查代码库、形成攻击假设并生成概念验证输入，而不需要为每次尝试投入等量的人力时间。

然而，每项可信发现都会带来工作量。团队必须确定其可利用性、识别受影响版本、评估严重程度、设计安全修复方案、进行测试并协调部署。

Google 自己的安全组织也承认这一瓶颈。该公司在描述自动化 OSS-Fuzz 补丁时表示，纯智能体扫描器可能产生较高的误报率。它还指出，对许多项目而言，持续使用前沿模型扫描的成本仍然过高。

这一自动化补丁流程将 OSS-Fuzz 与 Google DeepMind 开发的智能体 CodeMender 相结合。OSS-Fuzz 提供可复现的崩溃案例，而 CodeMender 则调查原因并提出修复方案。

这种配合表明，单纯的模型能力并不足够。相比在大范围代码审查中生成的不受约束的怀疑，可复现的崩溃能为修复智能体提供更有力的证据。

Google 的基础设施系统在提交前应用了类似原则。其扫描智能体提出问题，但另一分诊智能体会检查代码结构和可达性。

调用图映射哪些函数能够调用其他函数。抽象语法树解析则将源代码表示为结构化程序元素，而非纯文本。这些工具结合起来，有助于判断攻击者控制的数据能否到达危险操作。

这一确定性层面给传统应用安全产品带来压力，因为它改变了人们对用户体验的预期。相比仅在仪表板中堆满潜在问题的扫描器，一个能够验证路径并提出补丁的系统显得更有价值。

压力同样落在开发者身上。直接置于代码审查流程中的安全系统必须快速返回有用结果。扫描缓慢会打断工作，而嘈杂的发现会让开发者习惯性忽略警报。

Google 称，其快速验证阶段可在一分钟内完成。如果这一性能能够在不同代码库中保持，将支持高频扫描，而无需迫使开发者进入独立工作流程。

这种方法也改变了集中式安全团队的角色。专家可以编写领域规则和威胁假设，而智能体则将这些上下文应用于日常代码变更。

这并不会消除人工安全工作。它会让专家更多转向设计控制措施、检查异常发现，以及审查潜在影响最高的变更。

竞争对手也在推进相关模式。OpenAI 推出了 Codex Security，这是一种可分析代码库、在沙箱中测试疑似漏洞并提出修复方案的智能体。该公司称，其在测试中发现了近 800 个严重问题和超过 10,500 个高严重性问题。

这些是 OpenAI 的数据，并非经独立确认的测量结果。不过，其工作流程与 Google 对上下文分析、漏洞利用验证和拟议补救措施的组合高度相似。

Anthropic 也在推动 AI 辅助漏洞发现，而 Cisco 已在其产品中采用多模型扫描。Cisco 向 Axios 表示，其在八周内扫描了覆盖 25 种编程语言的 18 亿行代码。

Cisco 还将安全披露从每月一次改为每月两次。这一变化说明了更广泛的约束：更强的发现能力迫使组织加快披露和补救流程。

因此，主要竞争并非 Google 与某一家特定供应商之间的竞争，而是持续、具备上下文感知能力的审查，与将检测和开发分离的滞后大范围扫描之间的竞争。

传统扫描器不会消失。特征检查、依赖关系分析、模糊测试和人工审查各自能发现不同的失效模式。Google 的系统则在这些能力之外增加了一层新的编排机制。

最终胜出的方式可能是将概率型智能体与确定性证据相结合。智能体能够针对陌生代码形成假设，而结构化工具和测试可以排除缺乏支持的结论。

这一组合是 Google 主张的核心。该公司并非要求单一模型充当不受质疑的安全审查员，而是将扫描、分诊、测试、修复和人工批准分解为不同的控制环节。

Google AI 漏洞扫描如何缩小搜索范围

该系统通过赋予多个专用智能体有限职责及代码专属上下文来提升准确率。

通用模型在审查大型代码库时面临上下文问题。代码本身很少能说明哪些资产重要、信任边界位于何处，或哪些调用方能够提供不可信输入。

Google 通过局部威胁模型解决这一弱点。威胁模型会记录系统受保护的资产、预期攻击者、信任边界及可能的滥用路径。

该公司表示，这些模型从实时代码库元数据中提取信息，而非依赖彼此脱节的文档。这种关联很重要，因为过时的威胁模型可能会基于已不存在的架构，产生看似自信的发现。

Google 对其开源多智能体审查框架 Mantis 进行了演进，使扫描智能体能够连接这些局部模型。框架围绕底层模型协调提示词、工具、证据和交接流程。

Mantis 审查框架之所以重要，是因为它将系统架构与任何单一模型版本分离开来。Google 表示，设计良好的框架可以补偿模型之间的性能差异。

第一个智能体利用相关安全上下文检查拟议变更。它可以识别可疑数据流、缺失的授权检查、不安全的内存操作或其他潜在弱点。

随后，第二个智能体利用程序结构验证该假设。它会遍历调用图、解析语法，并应用索引化安全规则，以确定易受攻击的路径是否可达。

这一阶段充当可信度过滤器。它询问攻击者是否能够触发疑似漏洞，而不只是代码是否看起来符合某种脆弱模式。

这种区别有助于解释所报告的准确率。许多静态分析警告描述的是理论上不安全、但无法通过攻击者控制输入运行的代码。可达性分析能够移除其中一部分警报。

然而，可达性并不能证明可利用性的所有环节。运行时配置、权限、部署拓扑和隐藏的环境假设，同样可能决定攻击能否成功。

Google 增加了每晚运行的提交后扫描，以发现跨越多次变更的弱点。提交前扫描器能够清晰审查单项贡献，但可能遗漏不同变更相互作用后产生的行为。

这形成了一种双速模型。快速检查保护开发流程，而较慢的集成工作则在低峰期寻找更广泛的系统性影响。

当流水线验证出漏洞后，修复代理会收到发现结果和生成的证明。该证明是一段代码示例，展示了如何触发存在漏洞的行为。

随后，代理会按照 Google 的编码标准构建补丁。它会将该建议附加到原始变更请求中供审核，而不是未经批准就直接部署。

人工审核是一项重要保障。补丁可能会阻止一种利用方式，却破坏有效行为、削弱另一项控制措施，或引入更隐蔽的漏洞。

Google 先前的工作提供了有用背景。一份 2024 年技术报告称，Gemini 生成的修复解决了单元测试中发现的 15% 消毒器漏洞。该结果涵盖 C++、Java 和 Go，并促成了数百个补丁。

这项 AI 补丁研究 将这一不算高的成功率视为有价值的成果，因为消毒器发现的问题数量庞大。它并未宣称自主修复已经解决了通用软件安全问题。

这条新的基础设施流水线扩大了目标。它将发现、验证和修复纳入常规开发生命周期，而非仅将模型应用于已知的消毒器失败案例。

其架构也在各阶段之间形成了有益的独立性。Google 建议将开发、扫描和分诊代理所使用的规则、上下文和测试工具彼此分离。

这种分离能减少关联性错误。如果一个代理编写代码后，再利用完全相同的上下文评判自己的输出，它可能会重复同一个错误假设。

独立的分诊系统更有可能挑战原始推理。确定性检查则进一步降低了对单一模型解释的依赖。

这一原则类似于金融和安全工程中的既有控制机制。做出变更的一方不应是唯一决定该变更是否可接受的一方。

对于考虑采用类似系统的公司而言，隐藏的要求是组织记忆。本地威胁模型、依赖关系图、安全规则和历史审核标准必须保持最新。

AI 无法利用组织从未记录下来的上下文。碎片化文档和未记录的架构会限制代理区分危险行为与合理例外的能力。

这也为可搜索的工程知识库带来了相邻的角色。在自动化审核能够有效利用这些信息之前，团队需要可靠访问架构决策、代码所有权和安全假设。

因此，其技术机制并不像“智能体”这一标签暗示的那样神奇。Google 将模型与结构化代码分析、维护中的上下文、异步测试和审核关卡结合起来。

其优势来自于将这些要素围绕每一次变更进行部署。模型只是一个组件，整个系统旨在将安全假设转化为可执行的证据。

自动化 AI 补丁仍面临验证问题

Google 的内部结果令人鼓舞，但已公布的证据尚不足以证明召回率、语义正确性，或其向普通公司迁移的可行性。

最明确的不确定性在于衡量方式。Google 披露了准确率和部分误报数据，但并未提供独立评估数据集。

它也没有说明检测到的漏洞中有多少属于关键漏洞、可在生产环境中利用，或是智能体扫描独有的发现。防止数百个漏洞可能涵盖严重程度和可信度差异很大的情况。

另一个缺失指标是召回率。一个扫描器即使报告了十个真实漏洞且没有误报，看起来很精准；但如果还有一百个漏洞未被发现，它仍然并不完整。

召回率难以衡量，因为漏洞总数未知。研究人员通常使用植入漏洞或历史案例，但这两种方法都可能扭曲结果。

历史基准存在数据污染风险，因为训练数据可能包含公开漏洞报告和开发者补丁。代理可能只是复现记忆中的修复方案，而非推理一个陌生漏洞。

新研究说明了这一问题。PatchBench 通过移植和修改后的漏洞评估代理，这些漏洞的修复方案更难从已记忆的公开示例中检索出来。

其作者发现，25% 的代理补丁与历史开发者修复方案存在显著相似性。他们还发现，仅依靠概念验证进行确认，会将解决率平均放大至原来的 1.83 倍。

在更严格的安全和语义检查下，即便领先的代理也只能解决大约一半的基准任务。全部 11 个受评估代理都未能解决其中 67 项任务。

这项 PatchBench 评估 还发现，代理有时会压制已报告的崩溃，却未修正其根本原因。这样的补丁可能通过狭窄的测试，同时让底层弱点依然存在。

这些发现并不直接反驳 Google 的内部主张。Google 的环境使用真实代码变更、本地化威胁模型、结构性验证和人工审核，而非仅依赖历史基准。

不过，这项研究表明，单次通过的证明不能作为完整证据。补丁必须在阻止更广泛漏洞类别的同时，保留有效功能。

Google 的每晚测试有助于应对这一风险，但测试套件永远不可能穷尽所有情况。生成的补丁可能会改变现有测试未覆盖的行为。

该系统也可能继承其威胁模型中的盲点。精确且最新的模型能够改善上下文，而不完整的模型则可能排除最关键的攻击路径。

维护这些模型会产生持续性工作。随着服务演进，团队必须更新边界、依赖关系、权限和滥用案例。

Google 可以凭借广泛的内部工具和安全专业能力支撑这项工作。较小的组织可能缺乏复现这些结果所需的代码索引、威胁建模纪律和计算资源。

成本仍是另一个悬而未决的问题。Google 没有披露推理支出、加速器使用情况，或运营该流水线的工程成本。

扫描一次小型变更比反复扫描整个代码库更便宜。然而，若将代理应用于多个代码库中的每一次变更，仍可能产生可观的累积需求。

Google 在自有 TPU 基础设施上运行 Gemini，包括 Trillium 和 Ironwood 系统。大多数组织将从外部供应商购买推理服务，或在更严格的预算下运行较小模型。

数据治理同样可能使采用过程复杂化。将专有源代码和威胁信息发送给托管模型，会引入合同、隐私和供应链方面的问题。

公司需要为代码保留、模型训练、访问控制、审计日志和跨租户隔离设定明确边界。高度受监管的团队可能需要私有部署选项。

其中还存在利益冲突问题。同一家 AI 供应商可以同时提供代码生成、安全审核、云基础设施，以及评估这三者的模型。

当一家供应商占据多个层面时，独立控制机制就变得重要。Axios 报道称，安全高管预计企业将保留多家供应商的组合，而非依赖单一平台同时承担创建和防御职责。

这一担忧支持 Google 关于分离代理和验证上下文的建议。不过，单一供应商技术栈内部的逻辑隔离，并不等同于组织独立性或供应商独立性。

人工审核仍是应对这些不确定性的最后防线。只有当审核人员拥有足够的时间、专业能力和证据来质疑生成的补丁时，这项保障才能发挥作用。

大量看似合理的修复方案，与大量嘈杂的发现一样，都可能压垮审核人员。自动化可能只是转移瓶颈，而非消除瓶颈。

Google 已承认，开源维护者已经收到缺乏审核价值的 AI 生成贡献。因此，其 CodeMender 项目在测试阶段采用隔离测试和 Google 工程师审核。

这一教训同样适用于企业内部。修复代理应减少总体审核工作，而不只是产出更多拉取请求。

因此，对 Google 公告最可信的解读应当是有限的。该公司构建了一条复杂的内部流水线，并披露了令人鼓舞的运营指标。

这项公告并不能证明自主代理可以取代安全工程师、形式化验证、模糊测试或独立评估。Google 也未明确提出这样的主张。

相反，该系统试图让可信发现更接近漏洞出现的时刻。它的成功取决于证据质量和安全修复，而非 AI 输出的数量。

Google 智能体代码安全下一步将走向何方

下一项考验是，Google 能否公布更广泛的衡量数据、将工作流程迁移至自身环境之外，并让修复质量始终领先于发现数量。

三个信号将决定 Google 的智能体代码安全是否代表一种可持续的运营转变。

第一个信号是衡量质量。Google 应披露不同语言和基础设施层面的召回率估算、严重程度分布、采用率以及补丁回归结果。

外部评估将增加可信度。独立研究人员可以测试该流水线能否发现新型漏洞，而不是复现已知补丁或利用狭窄的基准条件。

更精确的报告也将澄清“每月数百个”这一说法。读者需要了解，如果没有该系统，其中有多少发现会进入生产环境，以及其严重程度是如何确定的。

如果 Google 公布了针对陌生漏洞的可复现结果，人们对其方法的信心将会提高。如果报告仍仅限于部分准确率数据，不确定性将持续存在。

第二个信号是 Mantis 在 Google 之外的实际采用情况。开源测试工具能让其他组织获得编排逻辑，但无法获得 Google 的内部元数据或运营成熟度。

外部团队必须自行提供威胁模型、代码索引、安全规则、评估数据集和审核流程。他们的结果将显示，Google 的表现有多少来自测试工具本身。

成功采用不仅意味着安装量或 GitHub stars。团队应报告更少的漏网漏洞、可接受的误报率，以及更短的修复时间，同时不增加回归问题。

失败同样具有参考价值。如果用户难以维护上下文或控制模型成本，这种方法可能仍将集中在工程体系异常成熟的公司中。

第三个信号是竞争对手的反应。OpenAI、Anthropic、Microsoft、Cisco 和成熟的应用安全供应商，正在向经过验证的发现与自动化修复方向汇聚。

重要的比较将不在于哪个模型发现的问题最多，而在于哪个系统能够证明可利用路径、生成语义正确的修复方案，并融入日常开发流程。

Cisco 提高披露频率的决定表明，AI 驱动的发现方式已经在改变下游运营。更多供应商将需要调整发布节奏、验证能力以及客户沟通方式。

攻击者同样会获得更强大的分析工具。能够帮助防御者追踪存在漏洞的调用路径的智能体，也能为检查暴露软件的人提供类似助力。

这种对称性缩短了漏洞发现与被利用之间的时间间隔。防御价值将越来越取决于修补速度，而不只是检测能力。

Google 的预提交策略通过在攻击者检查已发布制品之前消除漏洞来应对这一变化。即便事件响应速度很快，这也比部署后才发现缺陷占据更有利的位置。

然而，预提交扫描无法覆盖所有弱点。配置错误、运行时状态、被入侵的依赖项、社会工程攻击以及架构失误，都可能在单次代码变更之外出现。

组织应将智能体代码审查视为防御体系中的一层。模糊测试、依赖项控制、渗透测试、运行时监控、访问限制和事件响应仍不可或缺。

对于开发者而言，眼下的问题是安全反馈能否变得更具相关性、干扰更少。一项在一分钟内给出、包含可达路径并附带经过审查补丁的发现，能够同时提升速度与信任。

对于安全负责人而言，问题在于智能体能否降低总体风险，而不是增加告警产出。这要求同时衡量遗漏缺陷、修复时间、审查人员投入以及回归问题。

对于企业采购方而言，关键在于证据的可移植性。Google 的内部规模证明，该架构能够在一个高度工程化的环境中运行，但并不保证在其他环境中取得相同结果。

更大的转变已经显现。应用安全正从定期检查转向嵌入开发工作流、持续且以证据驱动的干预。

Google 的智能体代码安全方案提供了这一模式最清晰的实现之一。其智能体会在代码进入生产环境前进行扫描、质疑、复测并提出修复建议。

未来几个月将揭示 Google 是否会发布更广泛的验证结果，以及外部 Mantis 用户能否复现其成果。这些结果比又一个引人注目的发现数量更重要。

工程团队应先审视自身基础：威胁模型是否仍然有效？依赖项是否已完成映射？测试是否真正有意义？审查职责是否明确？

如果这些要素缺失，引入智能体只会暴露问题，而无法解决问题。如果这些要素已经具备，持续的智能体审查便能将制度性知识转化为更早作出的安全决策。

真正的问题已不再是 AI 能否识别可疑代码，而是组织能否建立一套受控流程，将每一项发现转化为安全、及时的修复。