随着 AI 漏洞报告压垮 Apple，Apple 与 Google 的安全分歧不断扩大

尽管自动化漏洞发现的价值日益增长，但在 AI 辅助的漏洞报告开始压垮其安全受理流程后，Apple 已实施新的限制。Apple 与 Google 在安全上的分歧如今暴露出一个更大的矛盾：AI 能更快识别潜在缺陷，但厂商无法自动判断哪些发现应得到紧急处理。

据报道，Apple 于 2026 年 6 月引入了提交数量上限和 30 天冷却期。达到上限的研究人员必须通过 Apple 的安全门户申请更高配额。该公司尚未公开默认上限、报告量、拒绝率或审核积压规模。

与此同时，Google 将 AI 漏洞研究定位为防御者的力量倍增器。其 Big Sleep agent 已发现此前未知的软件缺陷，而人工专家仍负责监督披露流程。这种对比并不只是 Apple 对阵 Google，而是在检验 AI 安全项目能否像扩展发现能力一样快速扩展其判断能力。

Apple 在漏洞处理管道前设置了闸门

Apple 的新限制表明，漏洞发现能力已超出该公司现有受理控制机制的承载范围。

据报道，这项变更影响通过 Apple 内部安全门户提交的报告。上限限制一名研究人员可提交的报告数量，而冷却期则阻止其立即追加提交。研究人员可以向 Apple 申请更多容量，但这会增加一个审核环节。

Apple 的公开文档已显示出其对 AI 生成材料日益担忧。其赏金指南要求研究人员避免使用 AI 工具生成冗长描述。它还排除缺乏适当人工验证的理论性问题或 AI 发现的问题。

这一差异至关重要。AI 模型可以识别可疑代码，却无法证明攻击者能够触及它。它也可能生成一段看似合理、却经不起测试的解释。安全团队必须复现行为、评估可利用性、查找重复报告、估计影响范围并协调修复。

因此，每份提交都会带来审核成本，包括错误报告。一项包装精美但无效的发现，可能比一份明显不完整的报告耗费更多时间。审核人员必须将自信的措辞与技术证据区分开来。

Apple 表示，反复提交不符合条件的报告可能触发 180 天的处理暂停。超过两次暂停期可能导致被永久移出漏洞赏金计划。其条款还将大量提交虚假或未经验证的 AI 辅助声明视为不可接受的行为。

这些政策旨在遏制垃圾信息。新的上限更进一步，因为它在 Apple 尚未判断每份报告之前就限制了数量。这使其成为一项紧急受理控制措施，而非最终质量判定。

该机制可以迅速减少队列增长。但它对待拥有有效发现的高产研究人员，与对待提交推测性模型输出的人几乎没有区别。Apple 可以批准例外，但该公司尚未说明其标准或预期响应时间。

这带来了一个严重的边缘情况。一名研究人员可能在一次集中审计中使用 AI 发现多个相互独立、可复现的漏洞。如果该研究人员达到上限，一份有效报告可能要在冷却期内等待，而攻击者则在研究同一段代码。

Apple 尚未表示这种情况已经发生。它也没有公布证据表明，该上限曾延误关键漏洞披露。但这种可能性仍说明，配额是一种粗糙的筛选机制。

该公司的安全风险敞口使问题尤为重要。Apple 表示，其技术保护着超过 23.5 亿台活跃设备。因此，共享组件中的缺陷可能影响庞大已安装基数中的手机、平板电脑、电脑、手表和服务。

Apple 的计划还为高级利用链承诺提供丰厚奖励。该公司表示，自 2020 年向公众开放该计划以来，已向超过 800 名研究人员支付逾 3500 万美元。这些数字表明，尽管限制发现进入队列的方式，Apple 仍重视外部研究。

重要变化不在于 Apple 拒绝低质量报告。每个成熟的赏金计划都会这样做。Apple 已承认，受理速率本身如今也需要节流。

为什么 AI 漏洞报告在节省时间前会制造更多工作

AI 降低了发现可疑行为的成本，但并未消除确立安全影响所需的高成本工作。

传统漏洞研究存在自然限制。研究人员必须理解目标、检查代码或系统行为、设计测试并开发概念验证。这些步骤需要时间，因此会限制提交量。

AI agents 压缩了这一过程的部分环节。它们可以检查大量文件、生成测试工具、变异输入、追踪执行路径并提出利用假设。多个 agents 可以针对同一公开代码库并行运行。

这会形成两种不同的规模。有效规模会产生更多真实漏洞；浪费性规模则会产生重复报告、不可触及的崩溃、预期错误，以及技术上正确但没有实际攻击路径的观察结果。

两者都会进入同一个队列。

概念验证是一种可重复的演示，能够显示报告中的行为在既定条件下出现。Apple 要求研究人员提供可运行的利用程序或可靠的概念验证。它还要求说明攻击者所绕过的安全边界。

这一要求会过滤掉许多薄弱发现，但生成式 AI 可以模仿完整报告的外形。它可以提供技术术语、代码片段、影响声明和修复建议。这些要素没有任何一个能保证问题真实存在。

人工审核人员必须测试证据。他们还需要判断另一位研究人员是否通过不同症状提交了同一底层缺陷。当许多 agents 独立扫描同一代码时，重复分析会变得更加困难。

GitHub 发布了关于更广泛报告量变化的异常清晰证据。其平台上的私有漏洞报告从 2026 年 1 月每周约 550 份，上升到 5 月大部分时间每周超过 3000 份。其咨询团队当月发布了 1560 份经审核的安全公告，超过其典型产出的五倍。

然而，GitHub 表示，即使是这一创纪录的处理速度仍无法跟上。它对漏洞激增的说明显示，仅靠加快审核无法解决无限制受理的问题。

核心瓶颈是判断。安全团队必须确定哪些报告代表可触及、可利用的条件，哪些只是描述异常的程序状态。这项工作往往需要了解架构、部署、缓解措施和攻击者能力。

AI 可以协助这些决策，但让自动化系统拒绝报告会带来另一种风险。模型可能因陌生的利用方式与过去的误报相似而将其驳回。如果新颖发现消失在自动化过滤器中，攻击者将从中获益。

因此，厂商团队面临不对称的错误问题。接受一份错误报告会浪费审核人员时间；拒绝一个真实漏洞则可能让用户暴露于风险中。

提交上限通过减少流入量来控制第一种风险。当它们延误可信研究人员时，可能加剧第二种风险。更好的系统必须评估证据质量，而不能假定数量等同于滥用。

有用的信号包括可复现性、可触及的攻击路径、sanitizer 输出、受影响版本、利用前提条件和明确的安全影响。研究人员历史记录可以有所帮助，但不应永久排除新人。每一位成熟研究人员都曾默默无闻。

本事件所揭示的 AI 漏洞报告并非普通支持工单。它们是不受信任的技术声明，可能同时包含有价值的发现和具有说服力的虚构内容。Apple 的队列问题反映了区分这两类内容的成本。

Apple 与 Google 的模式分歧在于验证，而非发现

Apple 与 Google 的对比，实质上是在 AI 辅助安全管道中，验证工作应放在哪里的分歧。

Google 的 Big Sleep 将 Google DeepMind 的模型与 Project Zero 的漏洞专业知识结合起来。该 agent 搜索未知缺陷，但 Google 公布的流程在对外披露前保留了人工监督。

Google 于 2025 年宣布，Big Sleep 发现了一个被追踪为 CVE-2025-6965 的关键 SQLite 漏洞。该公司表示，威胁情报显示攻击者可能已知晓该缺陷，并正准备加以利用。

这一说法来自 Google，应被视为该公司的评估。不过，它展示了 AI 辅助发现的最佳情形：agent 足够早地发现高影响漏洞，使防御者能够进行干预。

Google 后来报告称，Big Sleep 在开源软件中发现了首批 20 个漏洞。人工专家在将这些发现报告给维护者之前进行了审核。这一步骤降低了维护者收到原始模型推测的可能性。

Google 的Big Sleep 概览也强调人工监督和既定披露流程。该公司并未将自主发现视为允许自主大规模提交的理由。

这为接收方创造了更清晰的接口。Google 在自身研究计划内部吸收第一轮验证。维护者收到的是已通过专家检查的发现。

Apple 的门户则面对这一接口的另一端。它接受独立研究人员的报告，而他们的方法、工具、激励机制和技能水平差异很大。Apple 无法假定每位提交者都进行了相当程度的验证。

因此，看似存在的 Apple 与 Google 分歧包含一个重要的结构性差异。Google 控制 Big Sleep 的工作流。Apple 并不控制外部研究人员指向其产品的 agents。

即便如此，Google 的模式仍提供了一个有用标准。当运行 agent 的一方也承担验证其结果的责任时，AI 发现的效果最佳。发送原始发现会将这一成本转移给从未选择运行扫描的维护者。

当存在赏金奖励时，这一标准会更难执行。自动化使研究人员能够检查更多目标并提交更多报告。这可能带来有价值的工作，但也会鼓励一种基于提交量的抽奖策略。

Apple 的规则试图抵消这种激励。报告必须完整、可操作、可利用且为首次提交。该公司排除缺乏可靠复现路径或描述不可行场景的发现。

然而，上限衡量的是数量而非质量。Google 的流程侧重于提交前验证。Apple 的紧急控制则是在验证前限制提交。

最强大的未来系统将结合两种思路。研究人员将提供可由机器验证的证据，而厂商将使用自动化聚类和复现工具。人工专家将专注于新颖发现和影响不明确的情况。

这一流程无法完全取代人工。漏洞严重程度取决于具体情境，包括部署方式、权限、缓解措施以及可串联的攻击机会。模型可以分析这些因素，但其结论仍需由可追责的人员进行审查。

Google 也承认，仅靠人工将难以跟上节奏。其 CodeMender 项目旨在利用 AI 发现并修复漏洞，将自动化从发现环节推进至修复环节。专门的评审代理会在最终人工批准前审查拟议补丁。

这揭示了 Apple 面临的真正竞争压力。更快的漏洞发现需要更快的确认与修复，而不只是更严格的受理机制。如果 Apple 的审查能力仍主要依靠人工，AI 辅助提交将持续考验其极限。

Apple 无需照搬 Google 的内部工具，但确实需要为整条流程提供答案。这包括发现、身份验证、去重、复现、优先级排序、修补，以及与研究人员的沟通。

最终胜出的不会是 AI 产生告警最多的公司，而是能以最少无效投入，将可信发现转化为已部署修复的公司。

行业内的安全项目正在收紧入口

Apple 的限额是行业整体从开放提交转向重视声誉、证据和受控访问的一部分。

GitHub 在面临不断增长的处理队列后，于 2026 年 7 月重组了其漏洞赏金计划。它在公开渠道之外推出了一项永久性的邀请制计划。公开计划现在采用 HackerOne 信号要求，以减少低投入和 AI 生成的报告。

缺乏所需声誉的新研究人员可获得四次提交机会，以建立记录。GitHub 将这一设计描述为通往邀请制计划的入口，而不是围绕安全研究设立的永久壁垒。

该公司的赏金计划调整适用于 7 月 27 日或之后提交的报告。此前提交的报告仍适用旧有结构。

GitHub 的做法不同于统一限额，因为它将过往提交质量作为信号，并且创造了获得更高访问权限的路径。不过，声誉系统可能会让技术娴熟的新手，或在主流赏金平台之外开展工作的研究人员处于不利地位。

curl 项目采取了更严厉的措施。在维护者难以应对 AI 生成的报告后，它终止了 HackerOne 赏金计划。这个规模较小的安全团队表示，虚假或低价值提交带来了难以持续承受的心理和运营负担。

Linux 维护者也报告了来自重复 AI 发现的类似压力。多个人可以对同一代码运行相近的工具，并私下提交相同结果。由于私有队列不会显示已有报告，每位提交者都可能认为自己的发现是原创的。

这些案例表明，Apple 并非唯一准备不足的公司。漏洞报告的经济模式变化速度，快于接收这些报告的机构适应速度。

过去，发现漏洞往往占据研究人员大量精力。如今，AI 代理可以在大量目标上自动执行代码审查和测试，但分诊能力并未得到同等程度的扩张。

开源项目面临的失衡最为严重，因为维护者可能没有专职安全人员。大型厂商拥有更多资源，但它们也有更多产品、研究人员、用户和潜在攻击面。

错误的结论是，AI 辅助报告价值不大。Google 的结果恰恰表明相反：AI 系统能够在成熟软件中识别真实缺陷，包括传统审查遗漏的问题。

正确的结论是，未经验证的输出会产生负外部性。运行模型的人以低成本获得线索，而接收方则要付出代价，判断每条线索是否重要。

行业计划正通过将这部分成本更多地转回提交者来应对。它们要求更有力的证据、设置配额、考量研究人员历史记录，或为受信任参与者保留高级访问权限。

这一转变带来了治理问题。受信任的研究人员仍可能出错，而不知名的研究人员也可能发现关键缺陷。声誉评分应当为分诊提供参考，而不能取代技术证据。

项目还需要透明的申诉渠道。如果自动化系统将一份报告标记为重复或不可行，研究人员应能够提供新的证据。否则，筛选机制可能掩盖真正的失效问题。

披露时间表又增加了一层压力。研究人员通常期望厂商在公开前，于规定期限内修复漏洞。漫长的受理延迟会在工程师甚至尚未评估报告前，就耗去这一期限的一部分。

Apple 的赏金流程通常在问题解决后才作出奖励决定。这可以鼓励谨慎评估，但也意味着研究人员依赖公司的内部处理速度和沟通质量。额外的受理延迟可能会加剧这种关系的紧张。

独立研究人员仍是厂商安全工作不可或缺的外部监督力量。限制过严的计划，可能会将他们推向公开披露、私下漏洞利用市场或其他目标。

因此，Apple 必须保护两种稀缺资源：其一是审查人员的注意力，其二是研究人员私下报告严重漏洞的意愿。

限额能够立即保护第一种资源。它是否会损害第二种资源，将取决于例外情况的处理、响应速度，以及对提交多项有效发现的研究人员的对待方式。

Apple 的限额并未告诉我们的事

这项被报道的政策证明 Apple 看到了受理问题，但并不能证明该公司正在遗漏关键漏洞。

Apple 尚未公布其收到的 AI 辅助报告数量，也未披露其中有多少有效、重复、理论上存在，或完全捏造。没有这些数据，外界无法衡量积压队列的规模或质量。

该公司也未解释其默认限额是否会因研究人员声誉而有所不同。目前仍不清楚 Apple 审查配额请求的速度，以及紧急报告能否绕过冷却期。

这些缺失的细节使人无法对运营风险作出确定结论。若限额配合快速的例外审查，对可信研究人员的影响可能很小；缓慢且缺乏弹性的流程则可能延误重要发现。

“AI 生成报告”这一表述还掩盖了多种不同做法。一名研究人员可能仅用模型润色文字；另一名可能用代理定位缺陷，随后手动复现和分析；第三名则可能根本未打开受影响的软件，就直接提交原始输出。

将这些工作流视为同一类别，会把辅助与失职混为一谈。Apple 已公布的规则通常侧重于验证，而不是禁止使用 AI 本身。这一区别应始终居于核心位置。

同样也没有经过验证的证据表明，Google 的工具可以直接解决 Apple 的受理问题。Big Sleep 在由 Google 专家支持的受控研究环境中运行，而公开赏金门户接收到的材料多样得多。

Google 的结果部分来自自我报告。该公司提供了问题跟踪和披露细节，但其关于防御优势的广泛主张仍值得独立审视。一个受控代理的表现并不代表所有 AI 安全工具。

自动化补丁还带来了更多不确定性。补丁可能会阻止明显的崩溃，却保留底层漏洞；也可能引发兼容性问题，或关闭一条攻击路径的同时打开另一条。

人工签核仍然重要，尤其对于部署在数十亿台设备上的操作系统。Apple 不仅必须评估修复是否有效，还必须评估其是否影响性能、隐私、电池续航或应用兼容性。

该公司的封闭式开发模式使外部评估更加复杂。研究人员可以观察公开行为并检查已发布的软件，但无法看到 Apple 的内部分诊工具、人员配置水平或修复队列。

因此，读者应避免两种简单叙事。Apple 并未承认 AI 本身击败了其安全团队；它只是通过政策及相关确认承认，报告量需要更强的控制措施。

相反的叙事也并不完整。该限额并非只是例行管理事务。30 天冷却期表明，常规审查和反垃圾规则至少对某些提交模式而言并不足够。

这项政策应以结果来评判。研究人员需要及时确认，可复现的发现需要快速技术审查，关键缺陷需要协调一致的补丁。队列规模之所以重要，是因为它可能拖慢这些阶段中的每一个。

这正是知识管理成为运营安全的地方。团队需要在报告、受影响组件、既有重复项、补丁和披露截止日期之间建立可搜索的关联。设计良好的可搜索知识库可以支持这项工作，但无法取代安全专业知识。

Apple 面临的挑战并不只是存储更多报告。它必须在发现在线索受理人员、产品工程师、事件响应人员和发布团队之间流转时保留上下文。上下文丢失会让即使有效的报告也变成重复劳动。

AI 可以帮助归类相关发现并检索既往决定，也可以起草复现步骤或识别受影响代码的负责人。这些用途能够减轻行政负担，同时不会将严重程度的最终决定权交给模型。

尚未得到解答的问题是，Apple 是否正在建设这种更深层的能力，还是主要依赖限流。限额争取了时间，但并未揭示 Apple 计划如何利用这段时间。

三项信号将表明 Apple 与 Google 的差距是否持续

下一阶段将由受理质量、修复速度以及对可信研究人员的对待方式来衡量。

第一项信号是 Apple 是否会公布更清晰的配额规则。研究人员需要了解默认限额、例外标准、紧急通道和预期审查时间。透明度将把不透明的限制转变为可预测的运营流程。

若 Apple 能为拥有可复现发现的研究人员快速批准配额，将支持其“政策针对噪音”的论点。未解决的访问请求或关键披露被延误的报告，则会削弱这一论点。

第二项信号是 Apple 是否会在不削弱人工审查的前提下扩展自动化分诊。有效的改变包括重复报告聚类、在隔离环境中执行概念验证，以及采用机器可读的证据要求。

Apple 还可以更广泛地提供目标标记。目标标记是一种受控标识，用于证明研究人员已达成受保护的安全目标。Apple 已在其赏金计划的部分环节中使用这类标记，以加快评估。

基于证据的自动化比统一限额更能直接解决质量问题。它能让 Apple 优先处理包含可靠复现路径的发现，同时为不寻常的漏洞保留提交渠道。

第三项信号是 Google 的安全代理在经过精心管理的演示之外表现如何。Big Sleep 的公开披露、误报控制以及从发现到补丁所需的时间，将提供有意义的比较。

Google 的 Project Zero 已将 Big Sleep 纳入其披露框架，该框架强调补丁可用性和透明度。其披露政策让外界能够考察这些发现如何走向公开发布。

如果 Google 能在不压垮维护者的前提下持续产出经验证的漏洞，其模式将获得更多可信度。若接收方报告称重复提交过多或发现内容流于表面，其与 Apple 的差距将缩小。

整个行业也将关注 GitHub。其基于声誉的机制在无限制访问与统一上限之间提供了一条中间道路。提交质量、新研究者的成功率以及响应时间，将检验这一设计是否有效。

对开发者和企业采购方而言，这一问题影响的是补丁部署时机，而非抽象的 AI 政策。只有当供应商能在攻击者利用漏洞前完成验证和修复时，发现更多缺陷才会提升安全性。

安全负责人应询问供应商，如何区分 AI 辅助研究与未经验证的自动化操作。他们还应了解，报告数量增长是否改变了修复目标、披露协调机制或人员配置。

研究人员同样负有责任。他们应确认受影响的版本，记录确切的前提条件，复现相关行为，并说明被突破的安全边界。AI 生成的文字无法替代这些步骤。

Apple 与 Google 的故事，归根结底关乎整个安全体系的处理吞吐能力。Google 正在展示如何在受控监督下加快漏洞发现。Apple 则在限制来自不受控外部群体的报告接收量。

任何一种方法都无法单独解决问题。没有验证的发现会制造噪音；没有扩大验证能力的限制，则会造成隐性延迟。

未来几个月，需要关注 Apple 是否会用一个更高信号质量的流程取代其紧急刹车措施。明确的例外规则、自动化证据处理以及更快的研究人员沟通，都将强化其立场。

如果冷却期仍是最主要的可见回应，Apple 与 Google 在安全策略上的分歧将进一步加深。AI 将继续增加看似合理的发现供给，而人工审查仍将是稀缺资源。

这种失衡应引起所有依赖广泛部署软件开展工作的人关注。请问问自己：你的供应商只是在限制报告，还是在改进从发现到修复的路径？答案将决定 AI 漏洞研究会成为防御优势，还是又一个不堪重负的收件箱。