随着 AI 垃圾报告激增，Apple 与 Google 的漏洞赏金规则趋同并加强整治

在低质量、AI 生成的漏洞报告以前所未有的规模涌入后，Apple 与 Google 的漏洞赏金规则都走到了相同的转折点。

据报道，Apple 限制了研究人员可通过其安全门户维持的活跃报告数量。当研究人员达到该上限后，Apple 还引入了等待期。该公司的公开规则如今警告，对于反复提交无效报告的研究人员，将延长暂停期限，最终可能将其移出项目。

这一对比很重要，因为 Google 此前已在其称为 AI 生成报告“大规模激增”后，收紧了开源漏洞项目。GitHub 随后也提高了参与要求，并重新设计了奖励结构。这些举措共同表明，自动化漏洞发现已经撞上了一种稀缺资源：专业人员的人工审查。

这场冲突并非简单的 AI 与安全研究人员之争，而是可规模化的发现能力与可验证证据之间的较量。AI 系统可以提出数百个看似可信的弱点，但安全团队仍必须逐一复现这些主张，并判断攻击者是否能够触及它们。

这种失衡带来了令人不安的反转。AI 原本应帮助防御者更快发现严重缺陷，未经验证的提交却可能淹没那些应被立即处理的报告。

Apple 为其安全处理队列设置了新门槛

Apple 的应对措施针对提交量，但其公开规则更直接地聚焦于验证与研究人员行为。

根据最初的配额报道，Apple 为活跃漏洞报告设置了上限，并对达到上限的研究人员实施冷却期。据称，若其工作证明需要更多容量，研究人员可以申请提高上限。

这一运营限制不同于 Apple 现行 Security Bounty 指南中公布的处罚措施。Apple 表示，若研究人员反复提交不符合资格的发现，公司可暂停处理其报告 180 天。

经历超过两次暂停期后，研究人员可能被永久移出该项目。暂停期间，研究人员通常将失去获得奖励、公告署名以及常规报告处理的资格。

Apple 提供了有限的例外。一名被暂停的研究人员仍可提交能够捕获适用 Target Flag 的证据，或包含完整封装的 iOS 或 macOS 虚拟化环境。

Target Flag 是放置在 Apple 系统中的受保护值，用于证明某项利用已抵达指定的安全边界。它将理论性主张转化为可衡量的证据。

Apple 的报告指南如今列出了有效提交应具备的若干特征。报告需要提供准确说明、可运行的利用程序或可靠的概念验证，以及简明的复现步骤。

该公司明确要求研究人员避免使用 AI 工具生成冗长描述。它还将未经适当验证的理论性 AI 发现归类为不符合资格。

这些规定并未禁止 AI 辅助研究。它们划定了在调查过程中使用 AI，与将 AI 模型未经测试的输出直接转入 Apple 处理队列之间的界线。

Apple 单独的项目条款进一步强化了这一区别。对于反复提交垃圾内容、虚假主张或未经审查的 AI 辅助提交内容的研究人员，公司可以终止其参与资格。

这一组合为 Apple 提供了多层执行手段。门户配额限制了同时进行的提交量；180 天暂停期针对反复出现的低质量行为；对于未能改进的研究人员，永久排除仍是可选措施。

这一差异很重要，因为仅靠配额无法识别质量。一名谨慎的研究人员可能同时有数项正在积极调查的合法发现；而垃圾提交者可能提交较少报告，却依然消耗大量工时。

因此，Apple 允许更有力的证据成为例外条件。可靠的利用、可复现的行为以及目标确认，可以让报告绕过数量控制。

这一变化也收紧了“有用的漏洞发现”的定义。仅发现可疑代码已不再足够。研究人员必须解释攻击者如何触及该代码，以及攻击者由此获得何种控制权、数据或权限。

这一标准对经验丰富的漏洞研究人员并不陌生。变化在于，面对 AI 生成内容带来的规模压力，现在有必要将它直接写明。

Apple 与 Google 的应对为何此时出现

Apple 与 Google 的整治反映了一种经济上的不对称：机器可以低成本生成安全主张，而工程师必须逐一证伪它们。

生成式模型可以扫描代码、描述不安全模式、起草攻击叙述，并排版出看似专业的报告。但这些能力都无法证明某项漏洞能在受支持的产品配置中实际生效。

模型可能在无法触及的代码中识别出缓冲区溢出；它可能误解权限边界，或虚构一个并不存在的函数。它也可能夸大普通软件缺陷的影响。

每一项主张乍看之下仍可能颇具可信度。安全工程师必须检查相关代码、配置测试环境、复现行为，并评估真实世界的暴露风险。

Google 在 2026 年 3 月修改其 Open Source Software Vulnerability Reward Program 时，正是这样描述这一问题的。该公司表示，其在数周内经历了 AI 生成报告的大规模激增。

Google 观察到虚构的触发条件、微不足道的安全影响，以及位于无法触及代码路径中的发现。因此，其OSS 规则更新要求项目部分领域提供更强的证据。

根据代码库层级，可接受的证据可以包括 OSS-Fuzz 复现结果或已合并的补丁。OSS-Fuzz 是 Google 面向开源软件提供的持续模糊测试服务。

Google 后来取消了部分较低层级产品漏洞及其他安全问题的现金奖励和公开署名。这一变化调整的不只是报告格式，也包括激励结构。

Apple 则采取了不同的运营路径。其据报道实施的上限控制与单个研究人员关联的活跃案件数量；其书面政策则警告，若反复提交仍属理论性或无效的报告，将予以暂停。

两种方法都会在稀缺的分流资源耗尽前引入阻力。两者都不认为措辞精致就等于经过验证的漏洞。

“垃圾内容”一词可能掩盖真正的机制。问题不在于 AI 写出了一句话，而在于自动化生成消除了过去限制推测性报告的自然成本。

在生成式 AI 出现之前，构造一份令人信服的漏洞提交需要大量人工工作。研究人员通常必须检查目标、触发异常行为，并记录可复现的结果。

AI 降低了生成文档的成本，却未必降低生成证据的成本。这导致更多报告的外观超出了其技术实质。

漏洞赏金可能会放大这种行为。当哪怕一份被接受的提交也可能获得奖励时，自动化系统便可能生成许多推测性尝试。

提交者为每一项额外主张付出的成本很低，而接收方每次都要承担专业审查成本。

这是一个典型的队列问题。若无效提交的到达速度快于审查能力，无论质量如何，合法案件都将等待更久。

增加审查人员只能提供部分答案。经验丰富的产品安全工程师难以招聘，而分流工作还要与修复、威胁分析和事件响应争夺资源。

自动化分流可以帮助确定报告的优先级，但它会引入另一层验证。分类器可能压制一份表述不佳、却描述了真实利用的非典型报告。

因此，Apple 与 Google 的应对将人工验证视为关键检查点。AI 可以辅助发现，但提交前仍应由人来负责证明该主张。

真正的权衡在于访问机会与信号质量

更严格的门槛可以保护安全团队，但也可能令新研究人员处于不利地位，并延误不寻常的发现。

开放的漏洞赏金项目可以扩大公司的防御覆盖范围。独立研究人员会测试内部团队可能忽略的配置、组件和攻击路径。

这种开放性之所以有效，是因为参与不需要受雇关系、机构身份或与供应商既有的合作关系。一名只拥有一项强有力发现的研究人员，也可以与成熟安全公司进入同一个处理队列。

提交限制改变了这一平衡。它们保护审查能力，但也让访问机会取决于既有报告质量或可用配额。

当多项合法发现同时出现时，风险会更加明显。审计大型平台的研究团队，可能在一次集中项目中识别出多项相关漏洞。

如果先前案件仍处于开放状态，即使新证据可靠，团队也可能达到活跃报告上限。申请提高上限提供了可能的补救方式，但决定权仍在项目运营方手中。

Apple 有正当理由保护其处理队列。其安全项目覆盖了在庞大设备用户群中使用的产品和面向公众的服务。

该公司表示，只有第一份完整且可操作的报告才有资格获得奖励。当多名研究人员调查同一弱点时，这项规则让及时提交变得重要。

因此，配额可能造成一种意外的竞争。研究人员可能优先处理最可能获得奖励的报告，而非对用户影响最大的议题。

Apple 试图通过强调完整证据来抵消这种压力。即使最先送达，缺乏可靠复现的仓促报告仍不符合资格。

该政策面临的关键问题是，Apple 能否持续地区分提交量与滥用行为。公开文档说明了什么使一份报告具有可操作性，但并未披露每项分流阈值或升级决定。

研究人员也无法独立衡量有多少无效 AI 报告进入 Apple 的系统。该公司描述过这一问题，但尚未公布按月细分的详细数据。

这种信息缺失并不会使 Apple 的应对无效，但它限制了外界评估配额是否适度，以及它是否改善了处理时间的能力。

围绕供应商响应时间的历史担忧，使透明度尤为重要。研究人员需要知道，沉默是源于报告质量不足、调查时间漫长，还是处理队列被无关提交淹没。

执行不当的门槛可能打击负责任披露。无法私下提交的研究人员，可能推迟报告、转向其他协调方，或在对流程失去信心后公开披露。

在修复之前公开披露可能增加用户风险。Apple 的规则也规定，过早披露将失去获得漏洞赏金的资格。

因此，公司既控制被接受的渠道，也控制维持资格的条件。当研究人员能及时获得具体反馈时，这种安排最能发挥作用。

最站得住脚的标准是基于证据设置阻力。反复提交虚构发现的研究人员应受到限制；拥有可复现利用的研究人员则应有明确的升级路径。

Apple 的 Target Flag 例外条款正体现了这一方向：它优先看重可验证的影响，而不只是声誉。

不过，Target Flag 并未覆盖所有漏洞类别。一些重要的逻辑缺陷难以通过简单的标记式证据来证明，有些报告也需要结合上下文作出判断。

这种权衡无法通过单一政策消除。Apple 必须足够严格地过滤，以保护分诊流程，同时也要保持足够开放，才能捕捉意料之外的研究成果。

Google 和 GitHub 表明这是一场行业转变

Apple 并非独自行动，正在形成的行业模式更看重已证实的影响，而非自动化发现的数量。

Google 于 2026 年 3 月发布的更新提供了最清晰的对照。该公司承认 AI 能加速漏洞研究，同时坚持要求研究人员在调查过程中验证其输出。

Google 并未仅因 AI 参与其中就拒绝报告。它提高了特定代码库层级的证据要求，并降低了低价值类别的激励。

其更广泛的漏洞奖励计划如今纳入了报告质量因素，例如技术精确性、响应度和事实准确性。公开规则将“AI slop”列为负面质量信号。

这种表述反映出评判标准的转变：不再只评估所称漏洞，也评估提交过程。研究人员必须证明自己理解目标，并能够支持后续问询。

GitHub 在 2026 年 7 月采取了另一种做法。它重组了公开漏洞赏金计划，并为选定研究人员设立了长期的仅限邀请通道。

该公司还为公开计划新增了 HackerOne Signal 要求。Signal 是一项声誉指标，依据研究人员报告获得正面结果的频率计算。

GitHub 表示，这一要求旨在减少低投入和 AI 生成的提交。自 7 月 27 日起提交的报告均纳入修订后的结构。

GitHub 的变更显示，开放计划如何能够逐步演变为由声誉把关的体系。新研究人员获得建立有效履历的机会有限。

Apple 当前的模式看起来较少依赖第三方声誉评分，而是结合报告标准、活跃案件上限和逐步加重的惩罚措施。

三家公司正以不同控制手段解决同一个资源分配问题。

Google 提高证据要求并收窄符合资格的类别。GitHub 调整访问权限、声誉与奖励。Apple 则限制队列占用，并惩罚反复提交无效报告的行为。

这些做法可以提升有效信号，但各自带来不同的排除风险。证据要求更有利于拥有成熟工具的研究人员。声誉门槛更有利于既有参与者。配额则更有利于此前案件能够快速结案的人。

这一趋势不止存在于大型科技公司。开源维护者也报告称，AI 生成的漏洞声明正在消耗志愿者的时间。

这些项目面临的失衡更为尖锐。一个热门库可能只有少数维护者，而自动化扫描器却能持续产出报告。

漏洞赏金平台已通过更严格的规则应对未经验证的 AI 假设。有些平台要求研究人员在提交发现之前进行人工测试和确认。

这种趋同说明了一点：行业并未禁止机器辅助的安全研究，而是在撤回对缺乏可追责人工验证的机器生成声明的奖励与关注。

这一差异将塑造未来的安全代理。只能产出看似可信报告的工具将失去价值。能够复现利用、收集追踪信息并解释可达攻击路径的工具仍将有用。

竞争机会在于证据自动化。安全代理不应在识别出可疑代码后止步。

它应构建测试用例，确认受影响版本，隔离前置条件，并记录由此产生的权限或数据暴露。随后，人类研究人员必须在披露前审查这些证据。

因此，Apple 与 Google 的对比不只是一个政策故事。它定义了下一代自动化安全工具的产品要求。

AI 能发现真实漏洞，但证明仍是瓶颈

反对全面禁止 AI 的最有力理由很简单：自动化系统已经在真实安全发现中作出贡献。

Google 通过 Big Sleep 等项目推广 AI 辅助的漏洞研究。Big Sleep 是由 Google DeepMind 和 Project Zero 开发的代理。该项目将模型推理与成熟的安全工具结合起来。

这项工作说明了企业为何避免直接禁止。AI 可以探索大型代码库、生成假设，并帮助研究人员调查复杂交互。

Apple 的规则保留了这种区分。它针对的是未经适当验证的 AI 发现，而非所有借助 AI 开发的发现。

研究人员可以使用模型检查源代码或改进报告。但最终提交仍必须描述观察到的行为、预期行为、被绕过的机制，以及可信的攻击结果。

可靠的概念验证仍居于核心地位。概念验证是在特定条件下展示漏洞的最小测试。

对于复杂攻击链，Apple 要求提供编译版本和源代码版本、所需载荷，以及执行该攻击链所需的一切材料。这一要求将可复现性置于叙述性信心之上。

Apple 有理由保留高质量的外部研究。在此前一份赏金计划更新中，该公司表示，自 2020 年向公众开放计划以来，已向 800 多名研究人员支付超过 3,500 万美元。

它还报告了多笔单项 50 万美元奖励。这些数字表明，外部提交并非 Apple 安全流程的边缘部分。

挑战在于，随着自动化扩展，如何保持这一渠道可用。如果分诊团队花费过多时间去证伪虚构场景，整个计划的价值都会下降。

不过，自动化分诊不能被视为绝对可靠。一个不同寻常的利用方式可能看起来像误报，因为它跨越了审查人员未曾预料的边界。

基于模型的过滤器也可能偏向传统的报告结构。使用不那么娴熟英语或不熟悉方法论的研究人员，即便拥有有效证据，也可能获得较低评分。

Apple 表示，其报告会接受人工审查，而 AI 协助确定传入案件的优先级。这样的分工可以减少行政工作，而不会将最终决定完全交给分类器。

细节依然重要。研究人员需要知道，自动化优先级排序是否会影响响应时间、资格认定，还是只影响队列顺序。

漏报带来的风险与垃圾信息不同。一份被拒绝的无效报告只会浪费研究人员的时间。一份被拒绝的有效报告却可能让数百万设备持续暴露。

解决方案不是接受每一项生成的声明，而是让申诉、升级路径和证据标准足够清晰，使强有力的发现能够从最初的错误分类中恢复。

安全团队也应衡量结果，而不只是减少的数量。一项成功的政策应缩短验证关键报告的时间，同时不压低被接受的高影响发现数量。

研究人员同样负有责任。他们应复现模型输出，测试受影响版本，说明前置条件，并删除缺乏实验支持的推测性表述。

AI 生成的文字可能让不确定性听起来像确定性。人工审查必须通过区分观察结果与假设来扭转这一倾向。

一份有用的报告应回答四个具体问题。什么输入会触发该行为？哪些受支持配置受到影响？哪个安全边界失效？攻击者能获得什么？

当这些答案缺失时，更多文字并不会改善报告，反而会增加寻找缺失证据的成本。

AI 漏洞报告整治后值得关注的事项

接下来的考验在于，更严格的规则能否在不赶走可信研究人员的前提下提升响应质量。

第一个信号将是 Apple 的报告处理表现。更短的初步审查时间将支持该公司的说法，即无效提交正在消耗关键处理能力。

Apple 目前并未公开发布涵盖队列规模、拒绝原因和响应时间中位数的详细仪表板。更高的透明度将使该政策的效果更容易判断。

研究人员仍可提供间接证据。更快的确认回复、更清晰的状态更新，以及更少长期未结案件的报告，都将表明这些控制措施正在发挥作用。

相反的模式将削弱 Apple 的解释。如果在实施数量限制后，合法报告仍被延迟，瓶颈可能涉及人员配置、内部协调或修复能力。

第二个信号将是对高产研究人员的处理。据报道，Apple 允许申请提高配额，这为拥有经验证发现的团队提供了重要的缓冲机制。

观察者应关注这些请求是否得到及时决定，以及决定批准的依据是否是证据，而非仅仅是声誉。

运作良好的例外流程将使严肃团队能够继续开展集中审计。不透明的流程则会让活跃报告上限显得武断。

Google 提供了一个有用的外部基准。其更高的证据要求应能减少无效报告，但也可能降低低层级开源项目的参与度。

如果两个计划都能在削减低价值队列流量的同时保持较高发现率，Apple 和 Google 的政策将显得更具合理性。仅凭提交总量下降并不能证明成功。

第三个信号将来自安全工具供应商和 AI 代理。市场如今拥有明确动力去产出可复现的工件，而不是润色完善的漏洞猜测。

有用的工具将整合执行追踪、版本信息、测试环境和利用前置条件。它们还会标注不确定的推断，而不是将其呈现为已确认行为。

计划运营方可以通过机器可读的提交模式来支持这种转变。必填字段可将观察到的结果、推断的影响、环境细节和人工验证步骤分开。

标准化证据可以改善自动化路由，而无需取代专家判断。它也会让批量提交更容易审计。

更难的问题在于，攻击者是否能获得同样的自动化优势，却不必面对披露规则。他们在利用漏洞前无需向供应商证明漏洞存在。

因此，防御者不能通过全面拒绝自动化来应对糟糕的自动化。他们需要更好的代理、更强的验证流水线，以及对可信发现更快的人工升级处理。

Apple 的即时政策保护了其赏金计划的前门。它并未解决机器规模漏洞发现带来的更广泛挑战。

对研究人员而言，实际信息很直接：使用 AI 扩大搜索空间，但只提交你能够复现、并能在技术质询下为之辩护的内容。

对工程领导者而言，这一教训超越了漏洞赏金。任何接收外部生成 AI 输出的工作流程，都需要一道与证据、可追责性和审查成本挂钩的关口。

Apple 和 Google 的政策转变最终将由过滤后抵达工程师手中的内容来评判。队列中的报告是更少了，还是更好了？

这一差异应指导下一阶段。跟踪响应时间，关注例外请求的运作方式，并寻找能够产出证据而非自信文字的安全代理。