DW446
科技公司一直在悬赏寻找软件漏洞；AI加入以后，这套机制似乎应该运转得更快？10月1日，Google Bug Hunters宣布，暂停开放源代码软件漏洞奖励计划。原因？与你想象的不一样
当生成能力远远超过验证能力，AI提高的可能不是生产率，而是整个系统的审查成本。
【作者 杰罗姆】
一、寻找漏洞的人多了，收报告的门却关了一家科技公司悬赏寻找软件漏洞，原本是一件容易理解的事。
公司不可能发现所有问题。外部研究人员帮助检查，找到真实风险，提交证据。公司修复漏洞，研究人员获得奖金。软件更安全，双方都有收获。
AI加入以后，这套机制似乎应该运转得更快。
机器能够阅读代码，寻找可疑位置，整理分析，写出报告。更多人可以参与，同一个人也可以检查更多项目。
但谷歌最近作出了一个方向相反的决定。
10月1日，Google Bug Hunters宣布，暂时不再接收开放源代码软件漏洞奖励计划，也就是OSS VRP中的产品漏洞提交。原因是自动化提交显著增加，其中绝大多数无效。供应链漏洞报告和已有报告不受影响，谷歌鼓励研究人员参与其他奖励计划，并承诺在2027年第一季度提供更新。
需要把边界说清楚：谷歌没有全面停止接收安全漏洞报告，也没有宣布放弃开源安全。它暂停的是一个计划中的一类提交渠道。承诺明年第一季度更新，也不等于已经确定届时恢复。
但这个局部暂停，仍然提出了一个足够大的问题：
为什么帮助寻找错误的机器，反而让接收错误报告的人难以继续工作？
标题里“发现的漏洞越来越多”，恰恰需要拆开看。
增加的可能是被机器标记的疑点，是声称发现漏洞的报告。它们距离经过验证的真实漏洞，还有一段需要有人走完的路。
二、AI能写出一份报告，却未必完成一次发现想象一名工程师打开一份漏洞报告。
标题醒目，风险等级很高，代码片段齐全，攻击步骤分条列出。甚至连修复建议都有。
问题在于：报告描述的攻击，真的能发生吗？
软件里有一段可疑代码，不等于攻击者能够调用它。某个函数可能出错，不等于外部输入能够抵达那里。程序崩溃，也不自动意味着有人可以窃取数据或控制系统。
这些差别，决定了一份报告究竟是在指出危险，还是在描述一个无法成立的故事。
谷歌今年3月19日发布的规则调整说明，已经明确提到AI生成报告激增。公司列出了两类问题：一类包含错误信息，甚至凭空描述漏洞的触发方式；另一类虽然指出代码错误，但相关执行路径无法到达，或者在项目的安全模型下几乎没有实际安全影响。
两类报告的外观都可能很专业。
前者需要证明它为什么错。后者需要说明它为什么不构成所声称的风险。
接收者无法仅凭文风判断。真正的漏洞也可能写得粗糙，错误的报告却可能结构完整。
因此，机器降低了表达专业判断的门槛，却没有保证判断本身成立。
过去，写出一份详细报告，往往意味着提交者至少做过一部分调查。现在，这种联系变弱了。
报告看起来像研究成果，背后却未必有相应的研究劳动。
三、一个人的提效，可能是另一个人的加班这里最容易出现的误判，是只看提交端。
以前一个人一天写一份报告，现在借助AI可以写十份。因此我们宣布：效率提高了十倍。
但漏洞奖励计划的目标，不是收到更多报告。
它要识别真实风险，完成修复，让软件更安全。
为此，每份报告都可能需要分类、查重、搭建环境、复现问题、评估影响，再与提交者沟通。即使最终判定无效，前面的工作也未必能省掉。
提交者少花的时间，可能被转移给了接收者。
可以做一个纯粹用于说明机制的假设：过去收到十份报告，其中五份有效；现在收到一百份，其中仍然只有五份有效。真实发现没有增加，等待核实的疑点却增加了九十个。
这不是谷歌公布的数据，而是一种可能的成本结构。
它提醒我们，评价AI生产率，必须把整条工作流程算进去。生成、验证、修正、交付，任何一段都不是免费附送的。
特别是在安全工作中，接收者不能轻率地说“这大概又是AI乱写的”。
漏掉一份真实报告，可能留下严重风险。认真核查每一份报告，又可能消耗大量有限的人力。
生成省下的时间，如果变成了别人的验证劳动，就不能全部记为生产率收益。
AI把工作做快了多少，需要与它给别人增加了多少工作放在同一本账里。
四、被占满的，不只是邮箱漏洞奖励计划之所以有价值，是因为它把企业外部的研究能力接入了自己的安全体系。
一个没有正式职位、没有机构背书的研究者，只要发现真实问题，也有机会得到回应和奖励。
这种开放性是一种优势。它让公司有机会听见原本听不见的警报。
但开放渠道也有一个共同限制：接收能力不是无限的。
当提交成本迅速下降，核查能力没有同步增长，队列就可能不断变长。错误报告会与真实报告争夺同一批人的时间。
后果不只是一群工程师更累。
真实问题可能等待更久。认真研究的人也可能收到更迟的回应。如果平台进一步收紧渠道，新参与者证明自己的机会就可能减少。
这里存在一种制度损失：为了保护审核能力，系统可能不得不牺牲部分开放性。
因此，无效报告并非总是“反正删掉就好”的无害噪声。它使用了共同的注意力，也影响其他报告被处理的速度。
当然，谷歌没有公开一套足以计算这次暂停全部损失的数据。我们不能据此断言，究竟多少真实漏洞被耽误，或者整个计划的净收益下降了多少。
但暂停本身已经显示：原有接收方式需要调整。
当机器能够无限制造待办事项，人类的注意力就成了需要重新分配的基础设施。
邮箱没有坏，通向判断的路却堵了。
五、为什么不能再派一个AI审核？很自然的解决方案是：既然AI制造报告，就让AI筛选报告。
这当然有用。
机器可以查重，检查材料是否齐全，运行测试，排除一部分明显错误。能够在隔离环境中自动复现的报告，也可以减少人工工作。
真正的问题是，筛选的目标不能只是判断文字是否可信。
一份漏洞报告需要证明某种行为能够发生，以及这种行为在具体系统里意味着什么。版本、配置、权限、输入路径，都会改变结论。
让另一个模型阅读报告后回答“看起来成立”，仍然只是增加了一次判断。
它可能正确，也可能被同一组错误前提说服。
更可靠的方向，是把判断接到可观察的证据上：攻击步骤是否真的运行，异常是否稳定出现，是否越过权限边界，修复后问题是否消失。
AI越能完成这些工作，它就越可能提高安全生产率。
因此，这篇文章不是在否定AI寻找漏洞的价值。AI完全可能找到人类漏掉的问题，也可能帮助研究人员更快完成验证。
关键在于，它交付的是什么。
如果交付的是一份需要别人从头调查的怀疑，收益就容易停留在提交端。
如果交付的是可以独立复现、能够确认影响的证据，收益才更有机会延伸到修复端。
安全体系需要的不是更多机器点头，而是更多问题经得起实际检验。
六、奖励发现，就得先定义什么算发现谷歌的调整并不是从10月才开始。
今年3月的规则变更，已经要求部分高等级项目的内存破坏报告提供精确的OSS-Fuzz复现步骤，或者已合并的补丁；随后4月更新又调整了较低等级项目的奖励范围。
方向很清楚：减少含糊线索，把有限资源投向可采取行动的结果。
这也是漏洞奖励机制需要面对的激励问题。
如果提交疑点很便宜，而潜在奖金足够有吸引力，参与者就可能愿意大量尝试。即使多数报告失败，只要少数成功，个人仍然可能觉得划算。
接收者承担的核查成本，却不会自动进入提交者的计算。
这不意味着每个使用AI的人都在投机。认真研究者同样会使用AI，工具来源也不能代替质量判断。
问题在于，规则必须让“认真验证”比“批量发送”更有价值。
证据门槛、查重机制、提交频率管理、按质量建立信誉，都可能帮助系统恢复平衡。但门槛不能只剩机构身份，否则真正有能力的新研究者也会被挡在外面。
最值得维护的原则，是让资格尽量跟证据走。
你可以借助AI，可以没有名气，可以第一次提交。重要的是，你能否让别人重现问题，并说明真实影响。
悬赏机制原本就不是购买安全术语。它购买的是对未知风险的有效发现。
AI普及以后，这个区别需要写得更明确。
七、AI生产率，需要一张完整的账单谷歌遇到的问题，有一种超出软件安全的普遍结构。
一端能够迅速生成材料，另一端需要认真核实。
新闻编辑部收到线索，期刊收到论文，企业收到申请，公共机构收到投诉，都可能面对这种结构。它们不必发生相同的事故，也不意味着所有领域已经出现同样的后果。
但只要“提交很便宜、判断很昂贵”，就值得提前审视接收能力。
未来，许多机构引入AI时，可能都需要追问三件事：有效结果增加了多少，核查时间减少了多少，处理错误的成本由谁承担。
只展示生成速度，越来越不够了。
一份完整的生产率账单，应当记录从提出疑点到解决问题的总成本。机器多写了多少页、多发了多少封邮件，并不能直接回答这个问题。
谷歌暂时收起一类报告入口，是一个具体信号：AI的产出增长，已经可能快过某些制度的消化速度。
这也是AI时代一个值得提前准备的变化。
当初，我们担心机器不能产生足够多的答案。接下来，越来越多系统需要处理的，可能是答案太多，而能够确认它们的人、工具和流程还不够。
最稀缺的能力，会逐渐从“把材料做出来”，转向“把事情证明清楚”。
当生成能力远远超过验证能力，AI提高的可能不是生产率，而是整个系统的审查成本。
判断一项AI应用有没有真正提效，最终要看它是否帮助人们完成工作。
包括那些接到它的报告以后，才开始工作的人。