Google OSS VRP 暂停凸显 AI 漏洞报告存在验证难题

据报道，Google 于 10 月 1 日暂停其开源漏洞项目中的一个类别，原因是无效的 AI 报告大量涌入，压垮了其审核流程。

Google OSS VRP 暂停意味着，在公司重新设计该项目的这一部分期间，将停止接收新的“产品漏洞”提交。Google 预计将在 2027 年第一季度提供更新。

这一决定并未关闭 Google 的所有漏洞项目，也并未禁止研究人员使用人工智能调查代码。

相反，它揭示了自动化发现与人工验证之间日益扩大的矛盾。AI 生成潜在发现的速度，远快于维护者复现、评估和修复它们的速度。

Google 的举措发生在开源安全领域压力持续升级数月之后。Linux 维护者及其他项目也面临着类似的大量重复、推测性或测试不充分的报告。

这一更广泛的趋势，比一个被暂停的提交表单更重要。安全项目历来通过奖励研究人员发现内部团队遗漏的问题。AI 改变了这一模式，因为它让候选问题的生成成本异常低廉。

稀缺资源不再是最初的怀疑，而是证明某个缺陷可达、可利用并与真实威胁模型相关所需的专家注意力。

Google OSS VRP 暂停实际改变了什么

Google 暂停的是一个报告类别，而不是放弃开源漏洞研究，也不是关闭整个漏洞赏金业务。

开源软件漏洞奖励计划，即 OSS VRP，涵盖 Google 自有开源代码库中符合条件的安全问题。Google 于 2022 年推出该计划。

产品漏洞报告用于识别项目代码、逻辑或设计中的缺陷。一份有效报告不能只指出可疑代码的位置。

研究人员通常需要展示受影响的版本、可达的执行路径、复现步骤以及具有实际意义的安全后果。这些要求将可被利用的漏洞与普通编程错误区分开来。

根据暂停详情，暂停措施于 Google 在 10 月 1 日宣布时生效。在该日期之前提交的产品漏洞报告仍有资格接受审核。

供应链报告仍然开放。这类报告涉及软件依赖项、源代码、构建或发布流程在到达用户前遭到破坏的情况。

影响 Google Cloud 产品的部分漏洞，仍可能通过独立的 Cloud VRP 获得资格。具体资格取决于代码库及其与受覆盖云产品之间的关联。

研究人员也仍可参与 Google 的其他奖励计划，包括覆盖 Chrome、Android、Google 设备、云服务和专门 AI 安全问题的项目。

这一范围上的区别很重要。将此举称为全面关闭，会夸大事件，并掩盖 Google 更具针对性的应对措施。

实际上，公司是在关闭一个高流量的接收通道，同时保留更狭窄的渠道。它计划在讨论该通道的未来之前，重新调整其形式。

具体的替代方案仍不得而知。Google 尚未公开说明是否会增加更严格的身份、复现、频率或证据要求。

在暂停前，Google 已收紧该计划。其 OSS VRP 规则要求研究人员验证 AI 辅助发现，并证明实际的安全影响。

规则列出了若干反复出现的问题。一些 AI 生成的报告包含错误的触发条件或虚构的技术细节。

另一些报告指出了真实的编码错误，却未能证明其安全后果。例如，缓冲区溢出可能只存在于不可达代码中，或处于有效安全边界之后。

Google 还取消了针对某些低等级产品漏洞及其他安全问题的现金奖励和公开致谢。2026 年 4 月的这一调整，旨在消除低影响提交的激励。

后续的暂停表明，这些较为有限的控制措施不足以显著减轻审核负担。Google 从劝阻低质量报告，转向暂时拒收该类别报告。

因此，Google OSS VRP 暂停是一项运营决策。项目审核人员已无法将每一种提交的可能性都视为可负担的起点。

AI 漏洞报告改变了提出主张的成本

AI 降低了声称存在漏洞的成本，却没有降低证明漏洞存在的成本。

传统漏洞研究要求研究人员在提交可信报告前投入大量人工工作。研究人员必须审查代码、理解执行路径并构建测试。

现代语言模型和自主代码代理可以更快地扫描代码库并生成假设。它们还可以生成看似经过审慎人工分析的精致报告。

这种表象造成了危险的不对称性。一份有说服力的文档可能只需几秒生成，而证伪其主张却可能耗费数小时的专业注意力。

报告可能识别出可疑的内存操作，并预测远程代码执行。模型随后可以围绕这一预测构建详尽的攻击叙述。

然而，受影响的函数可能从不处理攻击者可控的输入。编译器可能会消除该路径，或现有验证机制可能阻断所提议的触发条件。

项目的威胁模型也可能排除假定的攻击者权限。在每种情况下，报告听起来都很严重，却未能证明存在漏洞。

维护者无法仅凭一眼就安全地拒绝所有自动化报告。一份写得很差的提交仍可能包含真实缺陷，而一份打磨精美的提交也可能完全是推测。

审核人员必须检查代码、重建环境、测试所声称的输入，并评估现有防御措施。他们还可能需要联系报告者，以补充缺失的证据。

这一工作量会随着每一份报告增加，包括无效报告。自动化提交因此将验证成本从报告者转移给维护者。

这种影响更类似于电子邮件垃圾信息，而非传统安全研究。再发送一条消息几乎没有成本，但接收组织仍必须筛选每一项可能重要的主张。

经济奖励会加剧这种失衡。如果一项被接受的结果足以覆盖生成数千份提交的成本，那么对能力较弱的参与者而言，追求数量便成为理性策略。

这种行为损害了认真开展工作的研究人员。他们的发现进入同一队列，并争夺同一批审核人员的时间。

当维护者花费更少时间修复已确认漏洞时，用户也会受损。在补救工作甚至开始之前，分诊就成了瓶颈。

问题并不只是模型会产生幻觉。人类研究人员同样会犯错、夸大影响，并提交重复报告。

AI 改变了这些失败的规模、速度和呈现方式。它使一个人能够生成比其亲自验证的数量更多、且看起来合理的主张。

这一区别解释了为何禁止 AI 生成的文字几乎解决不了问题。研究人员可以改写未经验证的模型输出，并提交同样缺乏依据的主张。

相反，项目需要以证据为基础的门槛。关键问题在于报告者是否测试过结果，而非模型是否参与了发现过程。

Google 的暂停表明，其现有规则无法高效地落实这种区别。书面要求比在工业化报告量面前实际执行更容易。

Google 的 AI 安全战略如今面临自身的权衡

Google 推广 AI 辅助安全发现，但其奖励计划无法吸收同一波自动化浪潮产生的每一项发现。

Google OSS VRP 暂停并不意味着公司认为 AI 对安全毫无用处。Google 仍在投资于自动化漏洞发现和修复。

其安全团队使用包括 OSS-Fuzz、Big Sleep 和 CodeMender 在内的工具。这些系统将自动化分析与受控测试及专家审核相结合。

Google 还针对其所谓的 AI 时代，重新调整了 Android 和 Chrome 奖励计划。该公司预计，自动化将发现传统研究遗漏的漏洞。

这使暂停成为一次意味深长的转向。Google 并未退出 AI 安全研究，但正在限制一个受 AI 降低提交成本影响的外部渠道。

核心分野不是人类研究与机器研究之间的对立，而是内部验证的自动化与验证程度参差不齐的外部提交主张之间的区别。

Google 能够控制自身系统周边的环境。工程师可以定义目标、运行测试、收集崩溃数据，并衡量生成的补丁是否保持原有行为。

开放的奖励计划不具备这种控制力。参与者使用不同的工具、提示词、模型、代码版本以及对安全影响的不同定义。

审核人员只会收到最终主张，却看不到产生该主张的每一步。在决定发现是否重要前，他们必须重建缺失的假设。

这种差异使溯源成为一个实际的安全问题。团队需要知道测试的是哪个修订版本、什么输入触发了结果，以及是否有人类进行了复现。

Google 更广泛的奖励体系仍颇具规模。该公司表示，其项目在 2025 年向超过 700 名研究人员支付了逾 1700 万美元。

其年度 VRP 回顾将这一总额描述为历史新高。该金额较 2024 年增长超过 40%。

这些数据表明，Google 仍重视外部研究。它们也说明了维持可信提交渠道的重要性。

漏洞赏金计划依赖于相互信任。研究人员必须相信有效发现会得到公平关注，而公司则必须相信报告者已测试其主张。

未经筛选的自动化会削弱双方。审核延迟会令有能力的研究人员感到沮丧，反复出现的无效报告则会让审核人员更怀疑陌生贡献者。

Google 的应对措施保护了分诊能力，但也缩小了准入范围。独立研究人员目前无法通过被暂停的 OSS VRP 类别提交普通产品漏洞。

这一限制可能会连同噪声一起压制有价值的发现。一名发现有效问题的新研究人员，可能没有明显的替代计划可用。

因此，挑战在于开放性与验证之间的权衡。广泛准入会增加发现机会，严格门槛则保护有限的审核人员时间。

任何重新设计的计划都必须兼顾这两个目标。如果准入要求变得过于繁重，Google 将面临参与者集中于成熟研究人员和专业公司的风险。

如果要求仍然过于宽松，提交队列可能重回同样的过载状态。2027 年第一季度的更新将揭示 Google 如何划定这条界线。

AI 报告洪流是行业性问题

Google 的决定属于更广泛的转变：安全社区正在围绕自动化发现重写漏洞披露规则。

HackerOne 报告称，在更强大的 AI 工具于 2026 年 2 月出现后，行业报告量增长超过 100%。

其报告量分析发现，部分提交包含有价值的发现；另一些则是重复内容、无法验证的主张，或缺乏可操作深度的报告。

该平台并未因此禁止负责任地使用 AI 辅助工具。相反，它强化了研究人员验证发现并证明真实影响的义务。

HackerOne 的规则要求提供可复现的概念验证、准确的严重性评级，并考虑现有防御措施。大量未经验证的报告可能触发处罚措施。

这种做法将责任归于操作人员，而非工具本身。研究人员仍需对每一个生成的端点、攻击步骤和影响主张负责。

Linux 内核社区也采取了类似的证据优先做法。其安全报告规则如今直接涉及 AI 辅助代码审查。

文档指出，AI 报告往往过于冗长，并掩盖关键事实。它要求报告者提供简洁描述、受影响的修订版本、触发条件以及经过测试的复现程序。

Linux 还警告称，工具可能在不了解内核威胁模型的情况下虚构理论影响。它要求报告者改为陈述可验证的后果。

该项目对待可被广泛复现的自动化发现，与传统上私下发现的漏洞并不相同。多名研究人员经常会发现同一个问题，因为他们运行着相似的工具。

这会在原本为稀缺、独立发现的漏洞而设计的披露渠道内制造重复工作。自动化改变了这些渠道背后的前提。

Curl 维护者 Daniel Stenberg 在 2025 年描述了这一问题的另一种表现形式。他提出的“death by a thousand slops”论点，聚焦于审查低质量提交所累积的成本。

单份糟糕报告或许看起来尚可处理。但当这一成本在数百项生成式主张中反复出现时，足以耗尽一个由志愿者维护的项目。

这些案例共享同一种机制：AI 扩大漏洞假设供给的速度，快于合格分流人员供给的速度。

其影响因组织而异。Google 可以安排受薪安全工程师，而较小项目往往依赖时间有限的志愿者。

开源维护者面临的激励结构尤其艰难。公开代码易于被自动化扫描器摄取，但维护者并未获得相应的资源。

漏洞赏金还可能带来另一种失衡。公司可能奖励被接受的发现，而社区维护者却需在没有报酬的情况下处理初步讨论或上游修复。

这并不意味着自动化研究本质上有害。AI 可以检查冷门组件、翻译陌生代码，并帮助研究人员构建测试。

在完成验证后使用时，它也能提高报告质量。模型可以整理复现步骤，或更清晰地解释复杂控制流。

当这些能力取代验证时，情况就会变得具有破坏性。生成一个看似可信的叙述，并不等同于证明存在可利用条件。

因此，正在形成的行业共识是有条件地接受。只要人工操作人员能够复现并捍卫每一项重要主张，AI 辅助仍然受到欢迎。

Google 的临时关闭措施比这一原则更为严格。但它反映了对责任应由谁承担的同一判断。

提交报告的人必须承担足够的验证成本，以保护接收方。否则，该计划就会沦为针对推测性机器输出的外包测试队列。

更严格的关卡或有帮助，但也会引入新风险

重新设计的计划需要将验证成本纳入每一份提交，同时不排除合法的独立研究人员。

Google 尚未披露产品漏洞提交机制的最终替代方案。若干控制措施都契合其早期规则中发现的问题。

第一项是强制提交经过测试的复现程序。复现程序是能够稳定触发所声称行为的小型程序、输入或流程。

Google 可以要求报告者说明确切的代码库修订版本和环境。这些信息将减少测试过时或不兼容代码所浪费的时间。

报告还可以要求明确说明可达性论证。报告者需要展示攻击者可控数据如何到达存在漏洞的操作。

结构化威胁模型字段可以迫使研究人员识别所需权限、信任边界和现有缓解措施。缺乏依据的严重性主张将更容易被发现。

速率限制是另一种选择。Google 可以限制单个账户在固定期限内提交多少份尚未解决的报告。

这将抑制撒网式提交，同时为严谨的研究人员保留访问渠道。更高的限额可依据既往被接受工作的记录授予。

保证金或信誉要求能提供更强的过滤机制，但也带来更大的公平性风险。新研究人员可能难以进入该计划。

自动化预筛选也是可能的组成部分。Google 可以利用静态分析、沙箱执行或基于模型的审查来标记重复报告和缺失证据。

然而，自动化筛选不能安全地成为最终裁决者。它可能拒绝不寻常但有效的研究，或偏向常见漏洞模式。

一个模型审查另一个模型的报告，也可能复制相同的错误假设。独立执行证据仍比文本一致性更有价值。

隐私与保密性带来额外复杂性。研究人员在请求模型分析时，可能将尚未修复的细节暴露给第三方 AI 服务。

修订后的计划可以要求披露在处理保密发现时对外部模型的使用情况，也可以限制哪些敏感材料能够进入托管系统。

Google 还必须明确开源维护者如何参与分流流程。一份报告可能影响 Google 代码库，却将工作负担施加给更广泛的贡献者社区。

公司应避免通过将验证职责转移至上游来解决自己的队列问题。那只会转移负担，而不会减少负担。

暂停期间的透明度将十分重要。Google 尚未公开提供关于被接受、重复、无效和 AI 辅助报告的详细分类数据。

Tom’s Hardware 描述了工程师和维护者面对数千份低质量提交的情形。然而，Google 发布的公告并未提供确切的数量或接受率。

这一区别限制了外界能够得出的结论。现有证据支持存在严重质量问题，但不足以呈现完整的量化图景。

Google 应公布足够的汇总数据，以解释重新设计后的门槛。有效指标包括中位审查时间，以及缺少可用复现程序的报告占比。

误拒率同样重要。如果强有力的发现因自动化过滤器误分类而消失，更快的队列并不意味着成功。

该计划应区分发现辅助与自主提交。经人工审查的 AI 发现可能具有价值，而无人监管的报告流水线则会产生难以管理的风险。

Google 最有力的设计，是让证明的评估成本低于文字叙述。机器可读测试、受约束的模板和可复现环境都可支持这一目标。

公司还应为非常规发现保留升级路径。一些重要漏洞难以用简单测试用例证明，或涉及复杂攻击链。

没有单一关卡能平衡这些要求。更可能的答案是基于证据质量、研究人员历史记录和已证实安全影响的分层访问机制。

在 Google 2027 年第一季度更新前应关注什么

下一阶段将显示，Google 是否能以更高的证据标准重新开放提交，而不只是接纳更少的研究人员。

第一个信号是替代计划的范围。Google 必须说明，产品漏洞提交是全面重开，还是通过更狭窄的渠道恢复。

全面重开将表明新过滤机制恢复了对审查流程的信心。有限的邀请制度则意味着分流能力仍然受限。

第二个信号是对报告者所需证据的要求。经过测试的复现程序、受影响的提交记录和具体攻击路径，将直指 Google 已识别出的弱点。

如果这些要求仍然易于满足，它们将强化该计划；如果只有成熟研究人员能够满足不透明的审查标准，它们则会削弱该计划。

第三个信号是其他安全计划如何回应。HackerOne、Linux 和主要供应商都在尝试制定适应 AI 的提交规则。

若它们在可复现性和人工问责上趋于一致，行业可能形成共同基线。这可减少跨项目工作的研究人员面临的困惑。

若各计划转而采取彼此不兼容的限制措施，披露将变得更困难。研究人员可能需要针对每个目标准备不同的证据包、AI 政策和保密实践。

开发者还应关注工具本身。更强的智能体可以生成可运行的测试，但也能以更高的自信生成无效证据。

关键基准并非智能体发现了多少警告，而是有多少可独立复现、与安全相关的发现能够通过专家审查。

维护者应追踪每个被接受漏洞所花费的时间，而非原始提交数量。该指标能反映自动化是在改善安全，还是仅仅扩大队列。

研究团队可通过记录 AI 辅助工作的每个阶段来做好准备。保存经过测试的提交、配置、日志、输入，以及失败的复现尝试。

团队还需要一份可搜索的既有发现记录。结构化的工程知识库有助于在问题抵达维护者之前识别重复项。

研究人员应能在不依赖生成式文案的情况下解释漏洞。他们应了解代码路径为何可达，以及现有控制措施为何失效。

如果缺少这种解释，该发现仍只是一项假设。它尚未准备好进入漏洞奖励计划。

因此，Google OSS VRP 的暂停是对工作流设计的警告，而不是对 AI 安全研究的否定。发现速度加快了，但验证并未消失。

Google 在 2027 年第一季度的更新，将检验一家大型供应商能否围绕这一现实重建开放计划。最佳结果不应是最大化提交量。

它应最大化审查人员每小时注意力所带来的已验证安全价值。这一标准为严肃研究人员提供了明确目标，也保护维护者免受推测性数量的冲击。

在任何地方提交 AI 辅助发现之前，请问三个问题：其他人能否复现它、它是否跨越真实安全边界，以及你是否测试了每一项主要主张？

如果任一答案是否定的，继续调查。生成成本最低的报告，可能成为维护者证明其不成立时成本最高的一份。