Google暂停OSS VRP新产品漏洞报告，验证成本压过提交成本
据 Tom’s Hardware 报道，Google 自 10 月 1 日起暂停 OSS VRP 接收新的产品漏洞报告，原因是大量无效的 AI 生成报告增加了审核负担。
作者：韩启明｜OC 政策与安全编辑
据 Tom’s Hardware 报道，Google 自 10 月 1 日起暂停 OSS VRP 接收新的产品漏洞报告，原因是大量无效的 AI 生成报告增加了审核负担。
一句话结论：自动生成报告越来越便宜，证明漏洞真实存在仍需要人力；奖励计划正在为这种成本失衡收缩入口。
暂停范围需要说清楚：此前提交的报告继续处理，供应链类报告不受影响，部分影响 Google Cloud 产品的仓库仍可能适用 Cloud VRP。Google 预计在 2027 年第一季度提供后续更新，这不能理解为已承诺届时恢复全部受理。
这并非突然转向。Google 在 3 月的规则说明及其 4 月更新 中，已经要求部分高优先级项目的内存破坏报告提供 OSS-Fuzz 复现步骤或已合并补丁，并收紧低优先级项目的奖励资格。筛选重心从描述得像漏洞，转向能够重现且具有安全影响。
一份报告可以准确指出代码错误，却无法证明攻击者能触达它。维护者仍要确认输入路径、权限条件、影响范围和修复方式。如果这些工作全部留给接收方，提交数量上涨并不等于软件变得更安全。
OC 判断，AI 辅助安全研究的价值应体现在证据链上：失败样例能否运行，触发环境是否明确，修复是否消除问题。生成更长的分析文本，无法替代这些步骤。研究者也需要重新确认当前项目的受理渠道，不能把其他奖励计划当成自动承接所有报告的兜底入口。
这次收缩还揭示了一项公共成本：开源项目的审核时间有限。低质量报告占用的并不是抽象的算力，而是原本可用于修复、代码审查和响应真实事故的维护时间。把验证前移到提交端，才可能让自动化研究的收益留在整个生态里。
关键事实
- 变更：10 月 1 日起暂停 OSS VRP 新的产品漏洞报告。
- 边界：存量报告和供应链报告继续处理；其他 VRP 有各自适用范围。
- 时间：2027 年第一季度预期提供更新，恢复日期尚不能据此确定。
OC 判断
不应把这件事简化成 Google 反对 AI 找漏洞。真正需要衡量的是，每份提交给维护者带来多少可验证的安全收益，以及多少额外调查时间。
为什么重要
- 对开发者：提交报告时带上可运行复现和影响分析，比增加生成文本更有价值。
- 对企业：安全自动化采购应统计有效发现与人工审核成本，不能只看报告总量。
- 对用户：减少报告噪声，有助于把维护资源留给实际可利用的缺陷。
评论
围绕这篇文章补充信息、提出问题或分享观察。