Google OSS VRP 暂停揭示 AI 漏洞报告的隐性成本
10 月 1 日，在无效的 AI 报告淹没其审核流程后，Google 停止通过其开源漏洞赏金计划接受新的产品漏洞提交。Google OSS VRP 暂停并不意味着该计划的所有部分都将终止，但在 Google 完成重新设计之前，它关闭了一条重要的报告渠道。
眼前的问题并非人工智能无法发现软件缺陷。AI 系统已经在经过大量审查的大型代码库中发现了有效缺陷。问题在于，如今生成一份看似可信的报告，成本远低于证明其安全影响。
这种失衡使漏洞分诊成为稀缺资源。Google 必须从幻觉式攻击路径、不可达代码、重复报告和普通编程错误中筛选出真实发现。GitHub、Linux 维护者及规模较小的开源项目也面临同样的压力。
Google 表示，截止日期前提交的报告仍将得到考虑。供应链报告仍然开放，而某些 Google Cloud 代码库中的缺陷可通过 Cloud Vulnerability Reward Program 提交。该公司预计将在 2027 年第一季度前提供下一次更新。
此次暂停暴露出一个值得关注的矛盾。AI 有望扩大防御性安全研究的规模，但未经验证的自动化会消耗修复真实漏洞所需的人力注意力。AI 辅助漏洞挖掘的未来，如今更取决于证据质量，而非原始发现数量。
Google OSS VRP 暂停范围有限，但立即生效
Google 冻结的是一个提交类别，并未放弃与外部安全研究人员更广泛的合作关系。
受影响的计划是 Open Source Software Vulnerability Reward Program，通常称为 OSS VRP。Google 于 2022 年推出该计划，旨在奖励负责任地披露影响符合条件开源项目漏洞的研究人员。
该计划覆盖 Google 自有公共代码库中的软件，以及托管在其他地方的部分项目。其范围包括产品漏洞和供应链入侵。这两类问题应对不同风险，如今也遵循不同的提交路径。
产品漏洞涉及项目代码、逻辑或设计中的缺陷。一份有说服力的报告必须证明攻击者能够触达该缺陷，并造成有实际意义的安全后果。仅指出某个函数看起来不安全，并不能证明可以被利用。
供应链报告则涉及软件构建、打包、签名或分发方式面临的威胁。即使底层源代码看似正常，遭入侵的发布流水线也可能传播恶意代码。Google 已保持该报告类别开放。
此次暂停适用于 2026 年 10 月 1 日或之后提交的新产品漏洞报告。较早的提交仍可按此前流程接受审核。Google 还引导研究人员在适用情况下使用其其他漏洞奖励计划。
涉及 Google Cloud 代码库的部分报告，仍可能通过 Cloud VRP 获得资格。该例外取决于问题是否影响 Google Cloud 产品，而不只是源代码库是否属于 Google。
Google 通过其在 X 上的 Bug Hunters 账号宣布了这一变更。根据首份详细的公开报道，该公司将这一决定与大量无效的 AI 驱动提交联系起来。
此次暂停是在数月收紧措施之后推出的，并非突然逆转。Google 在一项 4 月规则更新中称，涌入 OSS VRP 的低质量和无效报告激增。
Google 指出了两种反复出现的模式。一些提交包含关于如何触发所谓漏洞的幻觉式解释。另一些则找到了真实的编码错误，却未能证明代码可达或具有实质性安全影响。
这一差别很重要，因为软件缺陷与安全漏洞不能混为一谈。无法触达的测试工具中发生崩溃，与生产服务中的远程代码执行，后果截然不同。
Google 此前已停止针对某些产品漏洞，以及优先级较低项目层级中的其他安全问题提供奖励或署名。该公司还强调，可执行的发现、经过验证的复现步骤和影响演示至关重要。
因此，10 月的行动延续了既有的降噪努力。Google 没有在报告持续涌入时调整资格规则，而是在更广泛的重新设计期间关闭了受影响的接收渠道。
该公司尚未披露被拒报告的确切数量、积压规模或接受率。关于数千份提交的说法仍只是报道数字，而非完整的计划统计数据。
这些缺失的数据限制了外部分析。然而，规则变更、公开警告和最终冻结这一连串事件表明，渐进式筛选并未解决工作量问题。
无效的 AI 漏洞报告为何会破坏安全分诊
AI 改变了报告的经济学，因为提交可以自动扩展，而验证仍需要稀缺的人类判断。
传统漏洞研究需要经过多个高成本步骤。研究人员必须理解目标、识别弱点、构建可复现的攻击、评估影响，并清晰传达结果。
大型语言模型可以加速其中部分工作。它们可以检查源代码、提出危险的数据流建议、起草测试用例，并将粗略笔记转化为流畅文字。自动化代理还可以在多个代码库中重复这些步骤。
同样的工具也可能生成自信却错误的解释。模型可能假定攻击者能够控制实际上仍受信任的输入；它可能忽略权限检查、误解部署配置，或虚构一条可达的执行路径。
这些失败在提交后会变得昂贵。安全工程师不能仅凭语气就驳回一份看似可信的报告。他们必须检查引用的代码、复现条件、追踪数据流，并测试所声称的影响是否存在。
因此，生成一份错误报告可能只需数分钟，驳回它却可能需要数小时。即使没有恶意意图，一千份类似报告也会将这种失衡转化为运营层面的拒绝服务。
报告的呈现方式会让问题更加严重。语言模型很容易生成冗长的漏洞叙述、严重性标签、攻击图和缓解建议。这些附加内容都不能替代可运行的复现。
润色过的语言实际上可能提高分诊成本。审核人员必须在数页生成的上下文中找到事实主张，还需要判断哪些陈述来自测试，哪些来自模型推断。
Google 早先的规则正聚焦于检测与验证之间的差异。静态分析器发出的警告可以识别可疑代码，但并不能自动证明该代码造成了可被利用的安全边界违规。
可达性是关键测试之一。审核人员需要证据证明，在现实条件下，不可信输入能够流向危险操作。报告还必须考虑净化处理、权限、配置和既有防御措施。
影响是另一项测试。缓冲区溢出听起来很严重，但其发生位置和周围控制措施决定了攻击者能够实现什么。一些故障只会终止一个隔离进程，并不会泄露数据或控制权。
新颖性同样重要。自动化系统可能重新发现已知问题、重复此前被驳回的理论，或针对同一根本原因生成多种描述。每一份重复报告仍会消耗接收和审核能力。
这类工作量落在专业人员身上。经验丰富的维护者和安全工程师了解模型经常忽视的架构假设。让他们反复投入验证，会延迟补丁、审计、设计评审和事件响应。
机会成本不止影响 Google。即使代码支撑着广泛使用的服务，开源项目往往也只有规模很小的维护者团队。一次自动化报告活动就可能超出其全部安全处理能力。
团队可以将决策、复现过程和既有发现保存在可搜索的工程知识库中，以保留上下文。这种做法能减少重复调查，但无法消除专家验证的需求。
Google 暂停漏洞赏金计划使这种人力约束变得可见。安全计划原本围绕着包含实质研究投入的提交而设计。AI 让提交者能够将其中很大一部分工作转移给接收团队。
AI 漏洞报告带来的是质量问题，而非禁止 AI
核心冲突在于经过验证的研究与未经验证的自动化之间，而非人类研究人员与人工智能之间。
Google 并未主张研究人员应完全避免使用 AI。其公开立场是，人们在开展研究时必须验证 AI 输出。这一要求将 AI 视为工具，而非应当承担责任的报告者。
一份有价值的 AI 辅助提交仍可包含直接证据。研究人员可以提供受影响版本、精确命令、最小化测试用例、日志、截图和观察结果，也可以解释被违反的安全边界。
决定性问题在于是否有人确认了该主张。当测试证明相关代码可达，且结果影响机密性、完整性或可用性时，模型生成的假设才会变得有价值。
这一标准保护了合法自动化。多年来，模糊测试工具通过发送意外输入并记录故障来生成安全发现。它们的价值来自具体、可复现的输出，而不是具有说服力的描述。
AI 代理可以扩展这一模式。它们可以推理源代码、创建测试框架、调查崩溃并提出补丁建议。更广阔的搜索空间能够发现传统工具遗漏的缺陷。
然而，推理系统带来了另一种失败模式：它们能用看似合理的语言填补缺失证据。传统扫描器通常会报告其检测到的模式，而语言模型可能虚构完整的攻击叙事。
这一区别解释了为何漏洞披露计划不能仅依据流畅度对报告评分。审核人员需要与可观察行为相关联的证据。相较于已演示的结果，关于理论后果的主张应获得更低信心。
反对一刀切拒绝 AI 的最有力证据，来自成功的 AI 安全研究。AI 系统已经在大型开源项目中发现真实漏洞，其中包括人类审核人员此前遗漏的缺陷。
这些结果说明，禁止所有 AI 辅助报告并不明智。防御团队希望获得更广泛的覆盖，特别是在大型依赖图和成熟代码库中。他们不希望面对无限制、未经测试的推测。
Google 自身也在防御性安全研究中使用 AI。其更广泛的安全工作包括 AI 辅助漏洞发现和开源模糊测试。该公司的异议在于报告边界上的验证质量。
这条界限带来了一个问责问题。当自主代理提交报告时，谁来回答后续问题？必须有人澄清假设、修改复现步骤，并区分观察到的行为与预测的行为。
没有可问责研究人员的报告，会将这些任务转移给维护者。接收方最终要负责完成提交者发起的调查。
清晰披露 AI 的使用情况会有帮助，但仅靠披露无法证明质量。人工撰写的报告同样可能出错。AI 生成的报告也可能正确、简洁且经过充分测试。
因此，项目需要基于证据的准入门槛，而非文风检测器。AI 文本分类器可能误判技术写作，尤其是在研究人员使用模板或以第二语言写作时。
更好的接收系统应检验报告的实质内容。它可以要求提供最小复现、环境细节、受影响的提交、可达性证明，以及对攻击者能力的直接说明。
Google 暂停 OSS VRP，为公司设计这类准入机制争取了时间。风险在于，更严格的系统也可能排除那些没有声誉、却发现了有效漏洞的优秀新研究人员。
这种权衡无法消失。开放项目之所以能吸引意想不到的发现，正是因为任何人都可以参与。限制访问能提高平均质量，却也会降低陌生研究人员找到正确团队的可能性。
GitHub 和开源维护者也在收紧同一道门槛
Google 的决定属于行业范围内的转变：从开放接收，转向声誉、证据和更狭窄的提交渠道。
GitHub 在 2026 年也面临大量低投入和 AI 生成报告积压的问题。作为回应，它重组了赏金计划，并为公开研究人员和受邀研究人员分别设立了不同路径。
公开计划新增了 HackerOne 信号要求，该要求以研究人员此前在平台上的记录作为资格衡量标准。受邀计划则为已建立信任的研究人员提供了独立渠道。
GitHub 表示，其目标是在保留严肃外部研究的同时减少低投入报告量。其重组公告将新结构应用于 2026 年 7 月 27 日起提交的报告。
更早的指南说明了平台认定为有用证据的内容。一份高质量报告需要简洁摘要、附有支持性材料的复现步骤，以及对攻击者可实现影响的清晰说明。
GitHub 还警告称，理论叙述和 AI 生成的填充内容会拖慢分诊。问题不只是内容不准确。过多解释可能掩埋实际发现并延误审核。
Google 和 GitHub 选择了不同的即时应对措施。GitHub 保留了公开渠道，但设置了更严格的声誉和质量门槛。Google 则暂停了一个 OSS VRP 类别，同时保留其他漏洞计划。
两种做法都在保护审核人员的注意力。但它们也为尚未建立平台声誉的新研究人员增加了阻力。一份出色的首份报告，可能来自没有长期漏洞赏金历史的人。
开源维护者面临的是这个问题更尖锐的版本。许多项目没有专职安全人员、付费分诊团队或正式的提交基础设施。维护者可能只能在个人时间审阅报告。
行业指南正越来越多地将责任置于双方。Open Source Security Foundation 建议研究人员验证发现、了解项目政策，并清楚披露 AI 对工作作出的贡献。
其维护者指南也承认，AI 可以支持正当的防御性分析。建议的应对方式聚焦于安全整合与人工审查。
更广泛的模式类似于垃圾信息控制。当发送几乎没有成本时，接收方必须引入过滤器、声誉信号、速率限制或提交成本。否则，低质量信息量将淹没有价值的沟通。
漏洞赏金计划不能完全照搬普通垃圾信息过滤器。安全报告包含新颖的技术细节，而且常常来自未知研究人员。过于激进地拒绝异常内容，可能掩盖最重要的发现。
计划很可能会组合多种控制措施。结构化表单可以强制给出具体答案。自动检查可以验证必需材料是否存在。声誉可以决定提交限额，而非绝对资格。
速率限制对于自主代理可能尤其重要。一个人可以审阅若干机器生成的候选项，只提交其中最强的报告。无人值守的系统则可能在维护者给出反馈前淹没一个计划。
保证金或可退还的提交押金会提高成本，但也会引发准入担忧。低收入地区的研究人员可能面临不成比例的障碍。法律和行政复杂性也会增加。
私有或仅限受邀的计划能够避免公开渠道的数量压力，却会失去广泛参与。它们将信任集中在已知研究人员身上，可能错过对特定组件拥有专业知识的外部人士。
因此，Google 的重设计影响不止于一家公司。其他计划运营者将观察它是否能恢复有效信号，同时不向新人才关闭大门。
更严格的过滤器也可能掩盖真实漏洞
减少 AI 噪音是必要的，但每个过滤器都可能让一份有效却陌生的报告永远无法抵达正确的工程师。
Google 已说明暂停的原因，但尚未公布完整的性能数据。外部人士无法比较 AI 采用前后的误报率，也无法衡量积压问题的实际严重程度。
缺少这些数据时，仍存在多种可能的解释。AI 生成的提交可能主导了队列，也可能是较小一群重复报告者造成了大部分负担。不同原因需要不同控制措施。
底层模型的质量同样重要。围绕当前幻觉率设计的政策可能很快过时。更好的代理可以产出更强的复现，但也可能生成更大量的报告。
计划设计必须区分置信度与证据。一个代理即使认为漏洞可被利用的概率很高，也并未证明其可利用性。反过来，一份不完整的报告仍可能描述值得跟进的严重缺陷。
新研究人员常因缺乏披露经验而提交不完善的报告。即便底层观察真实，他们的写作也可能看起来像低质量的自动化输出。
语言和无障碍问题带来类似风险。要求精炼的英语表达可能使拥有深厚技术知识的研究人员处于不利地位。表单应要求具体证据，而不应把文风当作可信度的替代指标。
声誉门槛还会强化既有准入。成熟研究人员获得更多建立信号的机会，而新来者则难以进入。封闭循环可以提高效率，却会削弱多样性。
接收端的自动化也带来另一层不确定性。Google 可能使用模型来汇总、去重或排序报告。这些系统需要审计，因为漏报带来的后果与误报不同。
误报会浪费审核人员的时间。漏报则可能让漏洞一直未被发现。因此，接收系统应更积极地自动化路由和证据检查，而不是自动作出最终拒绝。
申诉提供了一项保障。被拒绝的研究人员应了解哪个要素不合格，以及补充证据是否能重新开启报告。笼统的拒绝信息会鼓励重复提交和公开的不满情绪。
透明的示例也能改善行为。计划可以发布匿名案例，展示不可达代码、缺乏依据的影响声明、重复根因，以及可接受的复现方式。
Google 已在其各漏洞计划中提供报告指南。其质量框架强调目标信息、可复现性、影响和沟通。
重设计必须决定这些标准是否会成为机器强制执行的前置条件。它还必须确定，尽管缺少正式字段，哪些报告仍值得人工酌情处理。
将每一份不受欢迎的提交都称为 AI 垃圾内容，还有另一种危险。这个标签可能掩盖了围绕威胁模型的真实分歧。研究人员和厂商对可利用性的评估往往不同。
一家公司可能因为攻击者需要用户交互而拒绝某个问题。研究人员则可能认为这种交互仍具现实性。这类争议早于生成式 AI 出现，无法通过作者身份检测解决。
同样的谨慎也适用于普通代码缺陷。有些错误没有即时影响，却可能在另一项产品变更后变得危险。计划需要边界，但不应将这些边界误认为是关于严重性的普遍判断。
因此，这次暂停是一项分诊干预措施，而不是受影响仓库变得更安全的证明。在一条报告路径保持关闭期间，漏洞仍会继续存在。
研究人员必须找到另一条合适渠道，或直接联系相关项目。碎片化的披露路径可能增加延误、意外公开和重复工作的风险。
Google 可以通过清晰地为被排除的报告提供路由来降低这一风险。其公开计划目录已区分 Google、Cloud、Chrome、Android、AI、滥用和开源范围。
只有当有效研究人员能够预测正确的投递目的地时，这次重设计才算成功。如果严肃报告在重叠的计划规则之间消失，更小的队列意义不大。
Google 重新开放产品报告前值得关注的事项
下一项考验在于，Google 能否用一个验证证据、但不让陌生研究人员失声的系统，取代开放式提交框。
第一个信号是承诺在 2027 年第一季度前发布的更新。Google 应澄清产品漏洞提交是否会重新开放、转移至其他渠道，还是通过限制访问的流程恢复。
若以结构化证据要求重新开放，将支持此次暂停只是临时分诊措施的判断。若无限期关闭，则意味着 Google 不再认为旧有公开模式可持续。
第二个信号是接收门槛的设计。强制要求复现、受影响版本、已测试提交、执行跟踪和简洁的影响说明，将直接应对已记录的失效模式。
仅以声誉为基础的限制则代表另一种选择。它们可能迅速减少数量，却会更看重研究人员的历史，而非每份报告中的证据。
Google 对自主代理的处理将尤其重要。该公司可以要求一名具名人员证明每份提交均已复现。它也可以对机器辅助报告施加速率限制。
有意义的政策应区分 AI 辅助与无人值守的批量提交。研究人员日常使用自动化工具、调试器、模糊测试器、扫描器和语言模型。决定性问题是谁验证并对主张负责。
第三个信号是，积压是否在不减少已确认发现的前提下得到改善。Google 尚未发布足够的数据来进行这种比较，但未来的透明度将帮助其他计划从这次重设计中学习。
有用的指标包括提交量、验证时间、重复率、被接受的发现、报告者申诉，以及包含可运行复现的报告占比。汇总数据可以保护敏感细节。
研究人员还应关注 Google 的其他 VRP。如果无效的 AI 漏洞报告流入 Cloud、Chrome 或 Google 的通用渠道，那么暂停措施只是转移了工作量，而非解决问题。
该公司更广泛的漏洞赏金体系仍在运行。Google 的项目目录仍会将符合条件的安全问题分流至多个专业项目。
Google 以外的维护者不应等待最终政策出台。他们可以明确可接受的证据标准，发布威胁模型，限制自动化提交，并创建模板，将观察结果与推断出的影响区分开来。
研究人员同样可以调整做法。在提交报告前，他们应复现相关行为，最小化测试用例，确认受影响的版本，并说明攻击者所需的访问权限。
他们应删除与发现无关的生成式背景内容。与围绕不确定前提精心包装的长文相比，附有直接证据的简短报告更容易验证。
AI 辅助安全研究将持续扩展，因为其正当收益十分可观。模型可以检索更多代码，生成有针对性的测试，并帮助调查人员关联陌生组件。
但发现数量已不再是衡量进展的最佳标准。只有在为维护者提供足够可靠的行动证据时，一份报告才真正有用。
Google OSS VRP 的暂停标志着这一差异已到了无法忽视的时刻。下一代项目设计必须奖励经过验证的洞见，保留访问渠道，并让人工注意力聚焦于真实风险。
在提交下一项 AI 辅助发现之前，不妨问一个比“模型是否发现了可疑代码”更难的问题：其他工程师能否依据所提供的证据复现其安全影响？
