10 月 1 日，Google 调整了开源软件漏洞奖励计划 OSS VRP：暂时不再接收“产品漏洞”类报告，并承诺在 2027 年第一季度更新后续安排。已经在 10 月 1 日前提交的报告不受影响，部分涉及 Google Cloud 产品的漏洞仍可转向 Cloud VRP。相关范围可以在 Google 官方规则页核实。
这不是 Google 关闭了整个漏洞悬赏计划。供应链攻击、源码或构建流程被篡改、发布凭证泄露等报告仍在范围内，其他 Google 漏洞奖励计划也继续运行。
真正值得讨论的，不是“Google 受不了 AI，所以关门”，而是另一个更具体的问题：
当 AI 把发现和撰写漏洞报告的成本降到接近零，安全协作机制还能不能继续默认每一份报告都值得由人来验证？
暂停背后，是一个失衡的成本结构
Google 给出的解释是，自动化提交显著增加，其中“绝大多数”并不有效。TechCrunch 的报道还提到，这些报告可能包含无法复现的问题，甚至由模型幻觉拼出的漏洞描述。
这里最麻烦的部分，不是低质量内容本身，而是它越来越像高质量内容。
传统的垃圾报告通常不难识别：描述含糊、缺少代码位置，没有复现步骤，也说不清实际影响。生成式 AI 却能迅速补齐一份安全报告的表面结构：漏洞摘要、攻击路径、严重性评级、示例代码、修复建议，一项不少。
问题在于，“格式完整”与“漏洞存在”是两回事。
模型可以根据常见漏洞模式写出非常顺畅的解释，却没有真正运行代码；可以推断某个输入可能造成越界，却没有确认相关分支是否可达；可以生成一段看似合理的利用代码，却没有验证编译条件、运行环境和权限边界。
提交者只需几分钟生成报告，维护者却可能要花几个小时阅读源码、搭建环境、追踪调用链，最后才能证明报告从一开始就不成立。
这是一种典型的成本转移：
- 生成者承担的是推理和提交成本；
- 维护者承担的是验证、排除和响应责任；
- 报告越像真的，排除成本反而越高；
- 即使最终判定无效，维护者付出的时间也无法追回。
AI 在这里并没有消灭工作。它只是让一方制造待办事项的速度，超过了另一方消化待办事项的能力。
这不是突然发生的
早在 Google 此次调整之前，开源社区已经出现过类似预警。
2025 年，TechCrunch 对安全行业的调查描述了一类越来越常见的报告：技术表述看上去合理，但深入检查后会发现，漏洞细节是模型编造的。CycloneDX 的一个项目曾因收到的报告“几乎全部是 AI 垃圾内容”而撤下漏洞悬赏；HackerOne 也观察到缺少真实影响的 LLM 误报。
不过，证据并不支持把所有 AI 辅助报告一概判为垃圾。
同一篇调查中，Bugcrowd 表示其每周整体报告量增加约 500 份，但当时没有看到低质量 AI 报告出现同等规模的激增；Mozilla 也称，其无效或低质量报告的拒绝量保持稳定，每月约五到六份、不到月度报告总数的 10%。
这组反差很重要。它说明问题未必是“AI 必然制造误报”，而更可能取决于三件事：
- 提交者有没有完成最低限度的人工验证；
- 平台是否要求可执行的复现证据；
- 奖励机制是否鼓励批量撒网。
如果提交一百份报告几乎没有成本，其中只要一份拿到奖金就可能获利，那么即使模型准确率很低，批量提交对个人仍然是理性的。对维护者而言，这种策略却会让整个系统失效。
真正稀缺的已经不是“发现”，而是“证明”
过去，漏洞悬赏的基本逻辑是：发现高质量安全问题需要稀缺技能，因此企业愿意用奖金吸引更多研究者。
Google 推出 OSS VRP 时，覆盖 Google 所属公开仓库、部分第三方依赖以及供应链风险，重点项目包括 Bazel、Angular、Go、Protocol Buffers 和 Fuchsia。项目启动时公布的奖励范围最高达到 31,337 美元。详情见 Google Security Blog 的项目公告。
AI 改变了这个模型中的稀缺性。
它擅长扫描模式、解释代码、补全攻击假设，也能帮助经验不足的研究者进入原本门槛很高的领域。真正有效的 AI 安全工具确实可能发现人工容易忽略的问题。否认这一点，只会把正常的工具进步误判成作弊。
但当“提出一个漏洞假设”变得极其便宜，系统不应再把假设本身当成高价值产出。新的稀缺资源是：
- 能否稳定复现；
- 能否给出最小化测试用例；
- 能否证明攻击路径在真实配置中可达；
- 能否说明对机密性、完整性或可用性的实际影响；
- 能否提交补丁、回归测试或上游修复记录。
Google 现有规则已经体现这种方向。例如，对重要项目中的部分内存安全问题，报告者需要提供精确的 OSS-Fuzz 复现步骤，或者已经合并的修复补丁；涉及第三方依赖时，还必须证明问题能在 Google 的项目中实际触发。
这比要求提交者勾选一句“我没有使用 AI”更合理。后者几乎无法核实，也会误伤合法工具；前者不关心报告是人写的还是模型写的，只关心证据能不能运行。
“再用一个 AI 审核”不是完整答案
最直接的解决方案，似乎是让防守方也部署 AI：自动去重、检查代码位置、运行概念验证，再把少数高分报告交给人。
这确实能缓解压力。HackerOne 已经尝试用 AI 系统识别重复报告、过滤噪声并对威胁排序，再由人工分析人员完成验证。
但这不能成为唯一答案。
如果生成器和审核器都依赖相似模型，它们可能共享盲点：同样误读一段代码，同样高估某种攻击路径，也可能被一份写得很专业的假报告共同说服。更现实的问题是，自动审核仍然要消耗算力、沙箱和工程维护成本。垃圾报告没有消失，只是其处理成本从安全工程师的时间转移到了另一套系统。
因此，更稳妥的设计不是让两个模型无限对话，而是增加可验证门槛：
第一，报告必须提交机器可执行的复现材料。
对于适合自动测试的漏洞，仅有自然语言描述不够，还应包含最小样例、环境信息、具体版本和预期结果。
第二，让提交者承担少量但真实的责任。
账号信誉、提交频率限制、重复无效报告的冷却期，都能改变批量撒网的经济账。其目的不是排斥新人，而是让“生成一千份再说”不再是最优策略。
第三，把奖励从发现描述转向验证产物。
可复现测试、补丁、回归用例和明确影响分析，应比一篇结构漂亮的报告更有价值。
第四，不要用“是否使用 AI”作为质量标准。
AI 可以参与代码审计、漏洞解释和报告润色。真正应该拒绝的是未经验证的结论，而不是工具本身。
开发团队也该重新理解 AI 代码审查
Google 的调整不仅是漏洞猎人的行业新闻。它同样提醒所有正在部署 AI 代码审查、自动测试和安全 Agent 的团队：告警数量不是安全能力。
一个工具每天发现 500 个“潜在高危问题”，听起来比只发现 5 个更强。但如果工程师必须花大量时间排除误报，它可能降低整体安全性——真实风险会被埋在噪声中，团队也会逐渐形成告警疲劳。
采购或自建这类系统时，至少应该追踪四类指标：
- 被确认并修复的问题比例；
- 从告警到可复现证据的时间；
- 每个有效问题消耗的人工审核时间；
- 工具是否能生成回归测试，而不只是生成解释。
我的判断是，下一阶段的 AI 安全竞争不会只看谁能发现更多问题，而会看谁能交付更短的“证据链”：从可疑代码到触发条件，从触发条件到真实影响，再从真实影响到可验证的修复。
Google 这次暂停接收部分报告，不足以证明 AI 漏洞研究失败了。恰恰相反，它说明 AI 已经足以改变安全协作的供需关系。
只是当发现能力被大规模复制之后，真正昂贵的部分才暴露出来：不是提出一种可能，而是负责地证明它。
主要资料：Google OSS VRP Rules；TechCrunch：Google pauses OSS bug bounty submissions；TechCrunch：AI slop and fake bug reports；Google Security Blog：OSS VRP announcement。
评论
发表评论