AI 报告淹没审查人员，Google 暂停开源漏洞赏金计划

由于自动化报告激增，Google 暂停了其开源漏洞赏金计划，并表示其中绝大多数报告无效。暂停自 2026 年 10 月 1 日起生效，影响向 Open Source Software Vulnerability Reward Program 提交新的产品漏洞报告。

这一决定凸显了 AI 辅助安全研究中的尖锐矛盾。模型如今能够以前所未有的速度检查更多代码，并生成看似可信的报告。然而，每一份提交仍需由人工判断所称漏洞是否存在、是否重要，以及能否复现。

Google 并非孤例。Curl 在 2025 年确认漏洞率降至 5% 以下后终止了现金赏金。Linux 维护者在收到一波又一波重复的 AI 发现后，也调整了漏洞披露做法。这些案例共同表明，漏洞发现的规模扩张速度已超过漏洞审查。

Google 开源漏洞赏金计划停止接收产品报告

由于自动化提交带来的审查工作多于有价值的安全发现，Google 暂时关闭了一条主要的报告接收渠道。

Google OSS VRP，即 Open Source Software Vulnerability Reward Program，奖励以负责任方式披露符合条件开源项目安全漏洞的研究人员。Google 于 2022 年推出该计划，覆盖其公开代码库中维护的软件以及部分外部项目。

该产品漏洞渠道于 10 月 1 日停止接收新报告。Google 表示，预计将在 2027 年第一季度期间发布进一步更新。

“此次暂停是由于自动化提交显著增加，其中绝大多数并不有效，”Google 在通知中表示。这一措辞很重要，因为它将自动化提交与经过验证的漏洞研究区分开来。

此次暂停不会取消截止日期前提交的报告，也不会关闭与更广泛计划相关的所有渠道。根据更新后的计划规则，供应链漏洞报告仍符合资格。

部分涉及 Google Cloud 代码库的漏洞仍可通过 Cloud VRP 获得奖励资格。Google 还建议研究人员在其审查开源接收流程期间，转向公司的其他奖励计划。

这一较窄的范围意味着，用“冻结”来形容比“关闭”更准确。Google 暂停的是 OSS 计划中的新产品漏洞提交，并非放弃全公司的外部安全研究。

该公司尚未公布受影响渠道的提交数量、无效报告比例或分流待处理总量。因此，关于审查人员收到特定数量不良报告的说法仍未经证实。

Google 披露的信息已足以构成决定性信号：自动化报告的数量和不可靠程度，已使现有流程难以为继。

这一流程并不只是接收一份写得漂亮的文档。审查人员必须检查代码路径、重现触发条件、判断可利用性、搜索重复报告，并确定负责的项目团队。

即使报告是错误的，只要看起来合理，也可能消耗大量时间。大型语言模型让这一问题更加棘手，因为它们能够生成详尽说明、代码片段和自信的严重性判断，却无法证明底层漏洞确实存在。

Google 在 2026 年早些时候观察到 AI 生成报告“激增”后，已收紧其规则。10 月的暂停表明，仅靠筛选要求不足以恢复可接受的信噪比。

因此，Google 的开源漏洞赏金计划已成为更广泛安全问题的一个试验案例：生成一项主张如今成本低廉，而证伪这项主张依然代价高昂。

AI 漏洞报告为何造成不对称成本

AI 改变了漏洞披露的经济模式，因为机器生成报告的速度快于维护者验证报告的速度。

传统漏洞挖掘对研究人员施加了实际成本。研究人员必须理解代码库、隔离异常行为、测试其是否会造成安全影响，并记录可复现的案例。

生成式 AI 降低了其中部分工作量。智能体可以扫描代码库、追踪函数、比较模式、起草概念验证代码，并将初步发现转化为看似专业的报告。

这些能力能够帮助合法研究人员，也可能让缺乏经验的用户提交他们并不理解、且无法在后续问询中为之辩护的主张。

这种不对称性在提交后显现。再生成一份报告可能几乎不需要额外工作，但分流审查仍会消耗稀缺的工程资源。

Open Source Security Foundation 首席技术官 Christopher Robinson 在 3 月的一份安全报告中描述了这一负担。他估计，热门项目过去平均每周收到两三份报告，后来有些项目却一次收到数百份。

Robinson 表示，单份报告可能需要维护者投入两到八小时的计划外工作。即便最终结论是不存在漏洞，这一成本依然存在。

误报并非唯一问题。自动化系统还可能发送重复发现、误读已有文档说明的行为、忽略威胁模型，或夸大低影响缺陷。

幻觉出来的漏洞尤其昂贵，因为报告可能在内部逻辑上自洽。审查人员可能会沿着详细的技术论证展开调查，才发现所引用的函数、控制路径或利用条件根本是凭空捏造的。

AI 安全公司 RunSybil 联合创始人 Vlad Ionescu 曾在一项AI slop 调查中描述过这种经历。他表示，报告起初可能看起来技术上站得住脚，直到审查人员深入调查，才发现模型编造了细节。

这造成了验证瓶颈。AI 扩大了潜在发现的供给，却不会自动增加可信审查人员的数量。

漏洞赏金还带来了提交不确定主张的经济动机。研究人员可以发送大量推测性报告，而维护者却承担了大部分验证成本。

声誉系统和速率限制能够减少滥用，但也会带来取舍。严格的门槛可能将缺乏平台历史、却拥有真实发现的新研究人员拒之门外。

身份要求可能阻碍面临法律、职业或地域风险的人进行负责任披露。提交费用则会形成更大的障碍。

自动化筛选又带来另一项复杂因素：如果筛选器仅因报告看起来由机器生成就将其拒绝，可能会丢弃借助 AI 发现或记录的真实漏洞。

关键区别不在于 AI 是否参与了报告，而在于提交者是否验证了相关行为，并能以可复现证据支持其主张。

当智能体能够大规模生成有说服力的文档时，这一标准更难执行。文本质量已不再是研究质量的可靠信号。

实际的应对方案很可能包括更严格的证据要求。计划可以要求提交者在分配人工审查前，提供最小复现案例、受影响版本详情、利用轨迹、测试用例或可运行的补丁。

这些要求将部分验证成本转回提交者，也更有利于真正理解代码、并愿意持续回答问题的研究人员。

Google 的 AI 漏洞报告难题也是 AI 安全领域的一项成功

制造低质量提交的同一项技术，也正在发现人类研究人员遗漏的真实漏洞。

将每一份 AI 辅助报告都视为垃圾，会误读现有证据。先进模型已在受控条件下展示出有意义的代码分析能力。

Anthropic 表示，Claude Opus 4.6 在内部测试期间于开源项目中发现了 500 多个此前未知的漏洞。据该公司称，每项发现均在披露前经人类或外部安全研究人员验证。

Mozilla 在两周内收到了该项工作提交的 112 份报告。它发布了 22 份安全公告，其中包括 14 项高严重性漏洞；其余许多发现则被归类为非安全缺陷。

这些结果展示了一种不同于大规模自动化提交的流程。Anthropic 将机器发现与人工验证、协调披露以及与维护者的重点沟通结合在一起。

据报道，在一个案例中，该模型创建了概念验证，以确认某个疑似漏洞确实存在。这一步将推测性模式转化为审查人员可以测试的证据。

Firefox 发现也表明，彻底禁止 AI 研究将适得其反。模型能够审查成熟、经过大量测试的代码，并仍然发现影响重大的缺陷。

因此，冲突并非人与 AI 的对立，而是经过验证的研究与不承担责任的报告生成之间的对立。

高质量的 AI 辅助工作流会保留一名人工负责人。此人检查输出、排除误报、理解影响，并负责与维护者沟通。

低质量工作流则将披露终点视为另一个自动化目的地。智能体识别某种模式、起草严重性叙述，然后在未独立复现的情况下提交。

两种工作流都能产出润色精良的文字，但只有一种能减轻接收方的工作负担。

这一差异解释了为何 Google 的暂停并不证明 AI 漏洞挖掘已经失败。它表明，其提交架构无法吸收当前有价值发现、重复报告和幻觉内容的混合输入。

AI 辅助安全最终或许能够改善这一架构的两端。计划可以使用模型对重复项聚类、将主张与已知问题比对、测试利用路径，并识别缺失的证据。

HackerOne 和其他平台已经开始引入基于 AI 的分流辅助工具。这类工具能够为报告排序，但其表现必须根据误拒率和漏洞漏检率来衡量。

自动化审查者同样可能产生幻觉。如果计划在研究人员和维护者之间置入模型，就需要为筛选器无法自信分类的发现提供升级处理路径。

最有力的模式很可能是分层模式：机器执行低成本检查，经验丰富的分流人员审查通过筛选的报告，项目维护者只处理可信发现。

这种方法类似于软件贡献的持续集成。测试会在维护者投入详细审查前拒绝显而易见的失败项。

安全主张仍比普通代码更改更难测试。可利用性取决于上下文、配置、信任边界和攻击者能力，而自动化检查可能误解这些因素。

不过，要求提供机器可验证的证据，仍能改善基线。一份附带失败测试、执行轨迹或可复现崩溃的报告，能为审查人员提供具体的评估依据。

组织同样需要为这类工作保留可长期留存的记录。可检索的工程知识库可以帮助团队将新发现与早期报告、决策和修复方案进行对比。

目标不是拖慢正当的发现工作，而是防止无限生成消耗有限的人工审查预算。

Curl 和 Linux 表明这是行业性问题

Google 的暂停延续了一种趋势：当 AI 压垮既有信任体系时，开源项目会收紧漏洞披露渠道。

Curl 提供了最清晰的先例。这一被广泛使用的数据传输项目在自 2019 年运营该计划后，于 2026 年 1 月 31 日终止了其现金漏洞赏金计划。

维护者 Daniel Stenberg 表示，该计划已确认 87 个漏洞。然而，在 2025 年，报告质量的趋势急剧恶化。

Curl 此前确认超过 15% 的提交为漏洞。该比例在 2025 年降至 5% 以下，意味着每二十份报告中不足一份被证明有效。

Stenberg 将原因归结为三个相互关联的趋势：AI 垃圾内容、其他提交的质量下降，以及报告者更关注奖励而非改进项目。

“管理这些没完没了的垃圾提交，会带来严重的精神负担，”他在宣布 curl 的决定时写道。

Curl 并未停止接受安全披露。它取消了现金奖励，仍将 HackerOne 作为推荐渠道，并引导研究人员通过私密 GitHub 报告或电子邮件提交。

这一回应针对的是激励机制，而非技术本身。Stenberg 认为，奖励吸引了正当发现，但也让投机性提交变得过于容易。

他承认其中存在取舍。取消付款可以减少噪音，但也可能削弱技术娴熟的独立研究人员的动力——他们会投入大量时间进行困难的调查。

Linux 内核社区则面临与重复发现相关的问题。多名研究人员针对同一代码运行类似的 AI 工具，并通过私密渠道提交了相同问题。

私密披露使研究人员无法得知是否已有其他人报告或讨论过某项发现。维护者不断将重复报告重新导向，或指出已经公开提供的修复方案。

Linus Torvalds 将私密安全邮件列表描述为“几乎完全无法管理”。他认为，除非确实需要保密，否则 AI 检测到的发现通常应通过项目公开渠道处理。

Linux 文档也提高了对提交者的预期标准。研究人员应提供简洁证据、联系相关维护者，并尽可能贡献补丁。

这一政策保留了人的问责责任。AI 可以协助发现问题，但必须由人理解报告，并对其后果负责。

Google、curl 和 Linux 选择了不同的干预方式，因为它们的计划结构不同。Google 暂停了一个提交类别。Curl 取消了奖励。Linux 则重新导向了许多报告，并强调公开处理。

它们的共同结论比各项政策细节更重要：当自动化代理能够制造几乎无限量的主张时，缺乏实质性提交成本的开放受理机制无法运作。

小型项目面临的风险最大。Google 可以分配工程师并重新设计基础设施，而志愿维护者可能没有专职分诊团队。

开源软件常常嵌入商业产品、云服务、开发工具和关键系统中。然而，审查安全报告的责任可能落在少数无偿贡献者身上。

AI 放大了这种失衡。它让外部人员可以持续扫描重要代码，却无需提供验证、修复和协调每一项潜在发现所需的劳动。

即使提交者本意良好，其结果也类似于拒绝服务问题。每一份报告都要求维护者投入注意力，而总量可能挤占对真实漏洞的处理空间。

更严格的门槛也可能掩盖真实漏洞

项目必须减少低质量报告量，同时避免建立一个只有资深研究人员才能进入的安全体系。

Google 的暂停在短期内保护了审查人员，但也移除了正当发现的一个报告路径。10 月 1 日之后发现的有效产品漏洞，可能需要通过其他符合条件的计划或披露渠道提交。

这种摩擦至关重要，因为研究人员并不总是了解一家公司的组织边界。开源代码库中的漏洞可能影响云产品、依赖项或下游应用程序。

复杂的分流规则增加了披露延迟或误投的风险。当研究人员无法确定可接受的私密渠道时，也可能促使他们公开发布。

基于声誉的访问机制带来另一种风险。资深研究人员更容易获得信任，但新参与者历来为赏金计划贡献过重要发现。

偏向既有身份的系统可能复制现有的准入鸿沟。它可能使独立研究人员、学生以及主要安全社区之外的人处于不利地位。

严格的概念验证要求同样可能带来风险。证明可利用性可能需要处理真实数据、绕过安全防护，或执行违反计划规则的测试。

因此，项目需要既严格又安全的证据标准。最小复现程序、受控测试或详细代码路径，都可以在无需进行有害利用的情况下建立可信度。

此外，并不存在可靠的 AI 生成文本检测器。即便底层工作完全正当，研究人员也常使用模型进行翻译、编辑、代码解释或格式化。

根据文风拒绝报告，会惩罚谨慎的披露行为，并促使人们隐藏 AI 的使用。它无法证明所报告的漏洞是否真实存在。

Google 的公开声明留下了几个未解问题。该公司尚未披露哪些筛选措施失效、激增期间捕获了多少正当发现，或正在考虑何种重新设计。

目前也不清楚，暂停最终是否会带来更多自动化、更高的证据门槛、受限访问，或不同的奖励模式。

缺少数据限制了外部评估。“绝大多数”传达了严重程度，但并未说明有效率是略低于既有门槛，还是几乎完全崩溃。

读者也不应将 Google 的经历视为普遍情况。Mozilla 此前表示，尽管行业担忧加剧，其无效报告拒绝率在较早时期仍保持稳定。

计划设计、项目可见度、奖励激励和提交规则都会影响报告的数量和质量。适用于一个项目的政策，可能在另一个项目上失效。

AI 系统本身也在快速变化。更强的模型能够生成更具说服力的误报，但也能生成更有力的证明并减少幻觉。

这种双向变化让静态规则变得脆弱。项目需要可衡量的质量控制机制，依据证据进行评估，而不是猜测由何种工具生成。

对安全负责人而言，核心指标不应是原始报告量。有用的衡量指标包括已确认漏洞率、重复率、分诊时间中位数、修复时间和审查人员工作负荷。

一个计划可能收到更多报告，却变得更低效。反过来，更严格的受理机制可以减少报告量，同时提高送达维护者的严重发现占比。

因此，应根据 Google OSS VRP 暂停之后的替代方案来评价它。关闭一个不堪重负的队列可以理解，但持久的安全成果需要为有效报告保留一条可信路径。

Google 开源漏洞赏金计划接下来会怎样

三个信号将揭示 Google 的暂停是会转变为更好的披露系统，还是会成为对开放参与的长期退缩。

第一个信号是 Google 承诺在 2027 年第一季度发布的更新。最重要的细节将涉及资格条件、证据标准、自动化筛选和申诉程序。

若重新开放时附带明确的复现要求，将强化这样一种判断：Google 利用暂停来重新设计受理流程。若无限期延长，则表明开放提交在经济上仍然难以维持。

关注 Google 是否要求报告者提供可执行测试、受影响的提交、利用轨迹或拟议修复方案。这类规则会将责任更多地转移给研究人员，同时不禁止 AI 协助。

第二个信号是重新开放后的已确认报告率。Google 尚未公布当前基准，因此，未来有效率和重复率的透明度将有助于评估新系统。

在披露访问保持稳定的情况下，更高的确认率将支持更严格的过滤。参与度大幅下降则可能表明，这些门槛在排除垃圾内容的同时，也排除了正当研究人员。

分诊时间同样重要。如果审查人员能够更快评估可信报告，Google 就能证明重新设计减少了隐性劳动，而不仅仅是减少了可见的报告量。

第三个信号是其他项目和平台如何回应。Curl 取消了奖励，Linux 重新导向自动化发现，Google 则暂停了一个提交类别。

如果更多计划采用经验证的复现、补丁要求或声誉门槛，这些做法可能成为 AI 辅助披露的默认标准。

平台也可能构建共享防御机制。跨计划的重复检测、标准化的机器可读证据以及可追责的代理身份，都可能减少重复劳动。

最具建设性的结果，是将发现规模与提交规模分离。研究人员可以广泛运行代理，但只有经过验证且去重的发现才会进入人工审查队列。

这一模式要求每次交接都有人负责。工具开发者必须为验证而设计，研究人员必须测试发现，平台必须谨慎筛选，维护者则需要明确的升级路径。

使用 AI 安全工具的开发者现在就应当按这些规则已经存在的方式行事。他们应复现每一项主张、理解受影响的代码、检查公开问题历史，并记录现实影响。

他们还应在提交后保持可联系状态。无法回答基本技术问题的报告者，会将全部调查成本转嫁给项目。

对企业而言，这一教训不止适用于漏洞赏金。任何公共受理系统都可能在 AI 让内容生成变得廉价、而评估依然昂贵时陷入过载。

支持队列、求职申请、资助计划、拉取请求和合规报告，都面临同样的基本失衡。稀缺资源不再是写作，而是可信审查。

Google 暂停开源漏洞赏金计划，让这种失衡在高风险场景中变得可见。一份虚假的安全报告会浪费时间，而错过一个真实漏洞则可能使数百万下游用户暴露于风险之中。

挑战不在于在 AI 与人类研究人员之间二选一，而在于设计一套披露系统，让自动化增加经过验证的安全工作，而非成倍扩大缺乏依据的主张。

Google 现在要在下次更新前展示这一系统的模样。它会以更强的证据门槛和有意义的访问渠道重新开放，还是随着报告量增长，开放参与会继续收窄？