Google 因自动化提交激增冻结其开源漏洞奖励计划

Google froze its open source bug bounty program due to a ‘significant rise’ in AI submissions — techcrunch.com · 2 小时前 · 🔒 安全

Google 已暂停其开源软件漏洞奖励计划对外接收新报告，触发因素是提交量出现显著上升，而其中相当比例被判定为质量低下、内容重复或缺少可复现步骤。该计划覆盖 Go、Angular、Protocol Buffers 等由 Google 主导的开源项目，针对严重漏洞给出的最高奖金为 31337 美元，是少数把现金直接付给外部安全研究者的激励通道之一。维护者一侧的抱怨已持续多时：批量产出的报告把真实线索淹没，甄别一条无效提交所耗费的时间常常超过修复一个真实缺陷，而审核工作往往由志愿者承担。文章还提到，这类压力并非 Google 独有，curl 等项目此前已因类似原因终止或收紧奖励渠道，安全众测平台上的无效报告比例也在同步走高。冻结意味着在计划重启之前新提交不会被受理，已提交但尚未完成审核的报告如何处理、何时恢复，官方均未给出明确时间表。作者的核心结论是：当提交的边际成本趋近于零、审核成本却保持不变时，奖励机制会被自身规模压垮，平台需要重新设计准入、验证与分级机制，而不是简单提高奖金或长期关闭通道。

核心信息

计划定位与奖金规模：该计划面向 Go、Angular、Protocol Buffers 等 Google 主导的开源项目，严重级别问题最高奖励 31337 美元，是把现金直接交给外部研究者的少数通道之一。对许多独立研究者而言，这类奖金是持续投入开源代码审计的主要经济来源，通道一旦关闭，他们的时间分配会立刻改变，部分人可能转向商业众测平台或改为私下披露。恢复时间未公布，新提交在重启前不会被受理。
冻结的直接原因：提交总量显著上升，且大量报告由自动化手段批量产出，共同特征是描述笼统、缺少可复现步骤、指向早已公开讨论或属于预期行为的现象。对维护者来说，判断一条报告是否有效的时间成本，常常高于修复一个真实缺陷本身，而承担这份工作的人多是志愿者。审核负担被成倍放大，最终挤压的是真实漏洞的处理速度。
行业对照与可行对策：curl 等项目此前已因同类原因终止或收紧奖励通道，安全平台上的无效提交比例同步上升。可选的改进方向包括提高提交门槛、要求提交方附带可运行的复现验证、对重复报告自动去重、给首次提交者设置冷却期，以及按被确认的有效发现而非提交数量结算报酬，用信誉分级替代一刀切开放。
潜在影响：对研究者而言，一条发现严重缺陷后获得回报的路径被暂时切断，可能促使其转向其它平台或直接联系厂商；对企业而言，短期内省下了审核人力与奖金支出，长期则可能削弱外部社区对开源依赖项的持续审视。值得观察的是 Google 会不会采用分级准入与自动化审核，其它厂商是跟进冻结还是把审核能力做成差异化优势。

💡 为什么值得读: 自动化提交泛滥之后，开源安全协作最脆弱的一环其实是审核而非发现，这篇文章记录了一个头部厂商在保护维护者与维持外部激励之间的真实取舍。

✍️ 小编看法: 真正被卡住的不是发现漏洞的能力，而是确认漏洞的能力。过去十年，安全众测的瓶颈在于谁能找到问题，于是奖金水涨船高；如今批量脚本把提交量抬高了一个量级，瓶颈转移到了阅读、复现与排序上，而这部分工作几乎没有规模效应，也无法靠加钱解决。冻结计划是一个诚实但粗糙的回应：它保护了维护者的时间，同时也切断了少数认真研究者唯一的现金回报路径。更合理的做法大概是分级准入，首次提交者先走低门槛通道，积累若干条被确认的发现后再解锁高额奖励；或者要求提交方自带可运行的复现脚本，把验证成本前移到提交者一侧。还有一个常被忽略的机会：既然批量灌水已经能被工具识别，那么去重、复现与相关性排序同样可以交给工具，审核侧的自动化程度，直接决定了奖励计划能承受多大规模。另一种隐性代价是误杀——当无效提交占据大多数时，审核者容易形成惯性怀疑，真正严重的问题反而可能被草率归档，而这种损失不会出现在任何统计报表里。接下来值得盯两件事：Google 会不会公布具体的恢复方案，以及其它厂商是选择跟进冻结，还是把审核能力本身做成护城河。

🏷️ bug bounty, open source, AI slop, Google