2026 年 10 月 1 日,Google 旗下针对自家开源项目的漏洞赏金计划 OSS VRP 正式冻结「产品漏洞」提交入口,给出的理由非常直白:涌入的 AI 生成报告太多,绝大多数无效,处理它们本身成了负担。这是全行业被「AI slop」反噬的又一个典型场景——去年还在帮安全研究员提效的工具,今年开始把研究员本身淹没。
OSS VRP 暂停的是什么、保留的是什么
按 Google 的官方说明,暂停范围明确限定在「产品漏洞」一类,10 月 1 日之前已经提交的报告不受影响,供应链攻击报告继续接收,Cloud VRP 与 Patch Rewards Program 仍然开放。换句话说,Google 没有停掉整个开源安全协作,只是把最容易被低质 AI 报告灌水的入口暂停,承诺在 2027 年一季度给出调整方案。从规则页直接拿掉的「产品漏洞」奖励等级看,OT0 到 OT3 四个项目层级目前都没有金额显示,等于是把这个口子直接关闭。
为什么 AI 报告变得不可承受
OSS VRP 覆盖的项目包括 Go、Angular、Protocol Buffers 等核心开源仓库,过去的研究员要做出能被采纳的提交,需要在代码层真正定位缺陷、设计错误或供应链组件漏洞,这是需要技巧的苦活。而大模型和自动化挖洞脚本的普及,把提交的「成本-技巧」比几乎压扁——任何人都可以让 LLM 扫一遍代码、产出一份格式上看似合理的报告。Help Net Security 在 5 月就对这类问题做过专题,Google 这次暂停实际上是对当时已蔓延数月的工程师抱怨的官方回应。
维护者们要花大量时间人工甄别报告,判断「这是个真漏洞」还是「模型在不熟悉的边界情况上产生的幻觉」。后果是,真正严重的漏洞反而被排队等处理,开源安全协作的核心信任机制被消耗。
不只是 Google 一家
行业里被同一波冲击的还有另外两家值得注意:
- arXiv 在同一天 10 月 1 日开始执行「每月两篇提交上限」的措施,理由是「高密度、近乎自动化的投稿大量涌入」。
- Internet Bug Bounty (IBB) 由 HackerOne 代管的公共漏洞池早在今年 3 月 27 日就暂停了新提交,该计划覆盖 curl 等核心项目的赏金发放,在 HackerOne API 里截至 10 月 6 日仍标为 paused。
- Linux 内核本月公开表示维护者「完全不堪重负」,在新版本里一次性推进到的 CVE 数量达到创纪录的 2000 个,主要是 AI 辅助挖洞脚本的产物。
- Intel 早些时候暂停了单个漏洞最高付 10 万美元的漏洞赏金,未官方确认 AI 报告是原因,但行业普遍持此推测。
这意味着「AI 改造科研与工程流程」的反噬已经从「模型写简历写错学历」这种低级失误,蔓延到了「耗散关键行业的人工审核资源」层。
几个值得记住的判断
一是「AI slop」并不是一个孤立的趣味词——它是已经成为基础设施运营成本的噪声。Google 这类公司每年要消耗数千万美元在漏洞奖励支出上,而无效报告把预算和工程师注意力双重锁死,这是单纯加钱无法解决的。
二是开源协作最核心的资产是「提交者信誉」,AI 让零信誉的提交瞬间伪装成有信誉,这个伪造不是技术问题,是社会协议问题。Google 用暂停作为短期止血、承诺 2027 年一季度给出系统性方案,这本身就说明现有 anti-spam 机制(lint、CWE 比对、人工审核)在 LLM 面前不够用了。
三是这次冻结的反向推力会回灌到上游——AI 安全工具厂商接下来要回答的问题不是「能不能更快挖到洞」,而是「怎么在报告层面证明这个洞是我认真挖出来的」。这意味着 AI 安全赛道的产品形态会被迫从「发现」转向「可审计地报告」。
对 AI 行业普通从业者来说,这件事离自己没那么远:你今天用的某个 LLM 工具也许不是漏洞源头,但是当一个 npm 包被无效 CVE 报告灌水后,真正修复该包的维护者反而没时间做他本来该做的事——这种延迟会以一种看不见的方式,沿依赖链传到下游。
一个还没人回答的问题
暂停产品漏洞提交之后,Google 会用什么机制替代原来的人工筛查?单纯加 CAPTCHA 把研究员挡回去是不可能的,这种机制会被真正有能力的白帽视为不友好;而完全依赖 LLM 评分又会回到同样的幻觉问题。Google 说 2027 一季度会更新,但愿那时候给出的不是另一种形式的「暂停就是把问题藏起来」。