随着漏洞报告触及新上限，Apple 与 Google 的安全分歧扩大

在 AI 辅助研究人员于三周内生成超过 50 项潜在 macOS 漏洞发现后，Apple 对安全提交设置了上限。这一变化暴露了现代漏洞计划中的严重矛盾：AI 发现看似可信漏洞的速度，已经超过人工团队验证、排序和修复它们的能力。

据报道，这项限制包括：达到配额的研究人员须经历 30 天冷静期。研究人员可以申请额外容量，但这一流程意味着，在 Apple 收到可能紧急的报告前，还会多出一个决策环节。Apple 尚未公开默认配额或审批标准。

这种张力使 apple google 的比较尤其具有参考价值。多年来，Google 一直将 AI 纳入结构化漏洞研究体系，并在模型周围配套测试、复现和人工审查。Apple 则一边在同一转变的输出端进行筛选，一边又在安全更新中认可 AI 辅助发现。

关键问题并非 AI 是否应属于安全研究的一部分。它已经是了。更困难的问题是：谁必须证明一项由机器生成的发现，值得占用稀缺的人工注意力。

Apple 的新限制将分诊能力变成一道安全边界

Apple 的提交上限将漏洞接收从开放通道变为按量计费的通道。

据最初报道，Apple 确认已对通过其安全门户提交的报告设置上限，并设立 30 天冷静期。需要更多容量的研究人员必须申请更高配额。

据报道，这项变化发生在意大利网络安全公司 Bynario 开展一轮异常密集的研究之后。该公司在审查 macOS 时据称使用了 ChatGPT，并在三周内产出了超过 50 项潜在发现。

其中一项被报道的发现涉及一条权限提升链，Bynario 认为它可能让攻击者获得对 Mac 的广泛控制权。然而，该公司在能够通过常规门户提交该发现之前，就已达到提交上限。

这一说法需要谨慎对待。Apple 尚未公开验证这条被报道的链条、为其分配 CVE，或确认其技术影响。因此，Bynario 的评估仍属于研究人员的主张，而非已确立的漏洞评级。

不过，这起事件仍说明了一个真实的接收难题。一个围绕偶发、劳动密集型发现设计的系统，如今正面对能在一次短期研究活动中生成数十条线索的研究人员。

Apple 现行的赏金指南明确了其质量门槛。报告必须提供清晰说明、可靠的概念验证、复现步骤，以及真实世界安全影响的证据。

指南还要求研究人员避免冗长的 AI 生成描述。Apple 将未经适当验证的理论性 AI 发现归类为不符合资格，即使其呈现方式看上去技术上颇为成熟。

反复提交此类报告会带来后果。Apple 表示，如果研究人员反复发送不可行或未经验证的发现，其处理流程可被暂停 180 天。暂停期超过两次，可能导致永久移除。

这些规则处理的是报告进入系统后的质量问题。配额则在 Apple 审查内容之前控制访问权。当一名研究人员拥有多项有效发现，或在达到上限后发现严重问题时，这一区别至关重要。

安全门户不仅仅是行政收件箱。它是从发现到修复这一防御路径的一部分。该路径中的延迟，可能延长有效漏洞仍可被攻击者利用的时间。

Apple 确实提供了通过配额申请绕过限制的途径。然而，公开信息并未说明这些申请多久能获得决定，或何种证据能够争取到配额提升。

这些细节的缺失给独立研究人员带来了不确定性。他们难以预测，富有成效的一周研究是否会在最具影响力的发现到来前耗尽其访问权限。

这一上限也改变了研究人员的激励机制。研究人员可能会整合发现、暂缓较弱的报告，或在 Apple 看到前先对发现进行排序。这可以提高信号质量，但也将一项重要的分诊决策转移到了 Apple 之外。

有些研究人员会谨慎作出这一决定。另一些人则可能误判严重程度、合并无关漏洞，或因对门户感到挫败而选择公开发布。每一种结果都会带来不同的安全风险。

Apple 表示，大多数被接受的报告会在 90 天内解决。这一目标涵盖的是已经收到的报告，而不包括因配额或访问审查而等待的发现。

因此，据报道的这项政策构成了本文的核心权衡。Apple 需要防范自动化噪声，但其过滤机制不能成为经过验证的研究成果的障碍。

为什么 AI 生成的漏洞报告正在压垮人工审查

AI 降低了产出一项看似可信发现的成本，却没有降低证明其成立的成本。

现代语言模型可以检查源代码、推理陌生接口、起草漏洞利用假设，并生成润色完善的技术文字。这些能力让熟练研究人员能在相同时间内探索更多路径。

它们也让缺乏经验的用户能够将不确定的模型输出转化为看似令人信服的报告。即使底层行为从未被复现，排版也可能制造出严谨的印象。

安全分诊团队不能表面接受这种印象。他们必须确定受影响组件是否存在、该行为是否属于预期，以及攻击者能否触及它。

他们还必须检查产品版本、安全边界、重复报告以及此前的内部工作。一份只需几分钟生成的报告，可能需要数小时工程审查。

误报并非无害。每一项缺乏依据的主张，都会与描述影响真实用户的可利用条件的报告争夺资源。队列因此成为一个安全资源分配问题。

Apple 自身的规则将缺失要素界定为人工验证。其计划条款禁止在未经人工审查的情况下，反复发送由 AI 辅助生成的垃圾信息和虚假主张。

这类措辞并不禁止 AI 工具。它将责任放在提交结果的人身上。研究人员必须证明问题确实存在，并说明攻击者能从中获得什么。

概念验证（PoC）是展示所声称行为的代码或可重复执行的流程。它将模型的假设转化为另一名工程师可以测试的证据。

仅仅复现并不总能证明安全影响。软件可能崩溃，却并未泄露数据、跨越权限边界，或赋予攻击者有意义的控制权。

这种区别对语言模型而言很困难。模型可以识别与漏洞有关的模式，却可能误解代码周围的防护机制。

例如，表面上的权限绕过可能只会在用户有意授予访问权限后发生。一条可疑的数据流也可能仍被限制在现有沙箱内。

安全计划必须调查上下文，而非关键词。他们需要了解攻击者的起始位置、所需的用户操作、可触及的资产，以及最终可获得的能力。

AI 还会增加重复发现。多个模型可能检查同一版本、优先关注相似的代码模式，并报告同一底层缺陷的不同变体。

Apple 7 月的操作系统更新展示了这种重叠。其致谢在相关组件中列出了多种 AI 工具和研究团队，而一些内核问题则吸引了多名报告者。

重复报告仍会消耗时间。工程师必须比对触发条件，并确定两份提交是同一根本原因，还是不同的利用路径。

这种经济失衡十分鲜明。报告生成正在自动化，但验证仍高度依赖经验丰富的工程师。接收组织承担了绝大部分验证成本。

这正是行业各处开始出现配额的原因。它们是对机器规模产出与人工规模裁决之间不对称性的直接回应。

然而，原始数量并不是完美的质量信号。谨慎使用自动化的团队可能产出许多有效发现，而一份精心润色的提交也可能完全属于推测。

更好的信号是验证密度。计划需要衡量研究人员的报告有多常能够复现、跨越既定边界，并最终促成安全修复。

Apple 已具备支持这种方法的一些基础设施。Target Flags 是嵌入 Apple 平台、针对特定漏洞类别的机器可验证工件。

捕获相关标记的研究人员，可证明一项明确定义的能力，例如对执行或受保护内存的控制。Apple 验证这种证据的速度可以快于验证叙述性主张。

Target Flags 并不覆盖所有类别。它们也无法消除理解根本原因、受影响版本或潜在利用链所需的工作。

尽管如此，它们指向了更好的接收模式。当提交流程要求提供机器和人类都能高效验证的证据时，AI 可以扩大漏洞发现的规模。

Apple 与 Google 的安全模式奖励不同类型的规模

apple google 的对比并非开放与限制之争，而是非结构化数量与工具化发现之争。

Google 已在漏洞研究中使用大语言模型，同时围绕它们配备执行工具、模糊测试器和可重复验证机制。其项目展示了当证据成为工作流程一部分时，AI 辅助发现会呈现何种面貌。

Google Project Zero 和 Google DeepMind 开发了 Big Sleep，这是一款用于漏洞研究的 AI 代理系统。该系统在漏洞进入官方发布版本前，就在 SQLite 中发现了一个可被利用的栈缓冲区下溢问题。

开发人员在 Google 报告该问题的当天修复了它。不过，Google 仍将这一结果描述为实验性成果，并表示针对目标的专用模糊测试器可能同样有效。

这种克制很重要。Big Sleep 并非只是生成了具有说服力的解释。它在真实软件中发现了具体行为、提供了证据，并将该发现纳入协调修复流程。

Google 的Big Sleep 研究也将模型访问描述为系统的一部分，而非全部。该代理获得了能够收集证据并检验自身推理的工具。

Google 的 OSS-Fuzz 工作遵循类似模式。模糊测试会自动向软件提供异常输入，并监控程序是否出现崩溃或不安全行为。

语言模型帮助生成和改进了这些模糊测试目标。Google 报告称，在生成的测试针对实际软件运行后，该工作发现了 26 个漏洞，其中包括一个 OpenSSL 漏洞。

AI 模糊测试计划并未将每一项可疑的模型响应都视为漏洞。编译、执行、崩溃分诊和根本原因分析仍是这一流程的一部分。

这种结构改变了维护者接收到的信号。接收者得到的并非一段声称代码看似危险的叙述，而是与特定输入关联的可观察故障。

这并不意味着 Google 能免受误报影响。自动化测试仍可能识别出不具备安全影响的崩溃，而复杂环境也可能产生误导性结果。

这种方法确实让验证更贴近发现阶段。这降低了未经支持的假设流入其他组织人工分诊团队的可能性。

Apple 正通过不同的控制措施追求相关目标。其漏洞赏金计划要求外部研究人员提供可运行的漏洞利用、可靠的复现步骤，以及可用时的 Target Flags。

区别在于各系统如何吸收规模压力。Google 的公开研究案例将模型置于受管控的实验流程中。Apple 的门户则接收来自不受控制的全球研究人群的提交。

因此，直接进行 Apple 与 Google 的排名比较会产生误导。Google 可以在报告离开其环境前调整内部代理、目标和证据要求。Apple 无法控制外部研究人员使用哪些工具。

不过，Apple 可以控制其提交协议。统一配额只是一个选项，而且或许是信息量最少的选项。

更完善的门户可以要求提交者结构化说明攻击者的初始位置、受影响版本、被突破的边界、复现率以及最终能力。

它可以在隔离环境中执行安全的概念验证。也可以在将报告分配给安全工程师之前对重复项进行聚类。

复现结果持续可靠的研究人员可以自动获得更高配额。新账户则可通过经验证的提交获得更多容量，而不是依赖人工申请。

Apple 的 Target Flags 已在特定类别中为这一模式提供了基础。扩大其覆盖范围将把提交容量与可验证结果关联起来。

Google 的经验还表明，模型应协助分诊，而不仅仅是发现。AI 系统可以将新报告与已知问题进行比对、提取复现步骤，并识别缺失的证据。

Apple 表示每份报告都会得到审查，而自动化系统可以帮助确定案件优先级。当报告可能影响复杂的安全边界时，仍然需要人工判断。

因此，Apple 与 Google 比较带来的有益启示在于运营层面：当工作流程同时降低验证成本时，AI 驱动的发现才能发挥最佳效果。

配额会压低输入量。证据流程则能提高输入的平均价值。Apple 很可能两者都需要，但二者的平衡将决定研究人员的信任。

GitHub 和 curl 表明这是全行业的提交危机

Apple 的上限是商业软件和开源软件领域更广泛地收紧无限制漏洞提交的一部分。

GitHub 在 2026 年 7 月重组了其漏洞赏金计划，此前它面临着不断增长的低投入和 AI 生成报告积压队列。该公司建立了独立的公开通道和邀请制通道。

缺乏既有 HackerOne 信誉信号的新研究人员可提交四份报告，以证明自身过往记录。GitHub 将这一限制描述为足以让真正的新手证明能力的空间。

其赏金计划重组适用于 2026 年 7 月 27 日或之后提交的报告。GitHub 保留了此前报告的原有结构，而非追溯性地修改规则。

该公司阐述的原则与 Apple 高度一致。问题不在于使用 AI 本身，而在于消耗专家审查时间、却未经验证的输出。

GitHub 将有效报告描述为简洁、可复现，并与真实安全影响相关。它还要求研究人员删去掩盖相关证据的理论性叙述。

影响 GitHub 的规模已超出其赏金计划。该平台上的私密漏洞报告从 1 月每周约 550 份，增至 5 月大部分时间每周超过 3,000 份。

5 月，GitHub Advisory Database 发布了 1,560 条经审查的公告。GitHub 表示，该总量超过其常规月度产出的五倍，但仍无法匹配不断涌入的需求。

这些数字反映出生态系统层面的瓶颈。更多发现并不会自动转化为更快的保护，因为审查与修复能力仍然受限。

开源项目面临着更严峻版本的同一失衡。它们通常缺乏专门的分诊人员、可复现的测试环境，以及用于持续审查的预算。

在维护者描述 AI 生成报告形成难以持续的洪流后，curl 于 2026 年初结束了漏洞赏金计划。该项目还在 7 月暂停了漏洞披露通道。

其现行披露政策要求贡献者不要粘贴大篇幅的 AI 生成说明。报告必须保持易于理解，并遵守项目的协调披露流程。

curl 于 8 月 3 日恢复接收漏洞报告。这次暂停表明，提交压力可能会暂时关闭一个被广泛部署的软件组件的报告通道。

这种结果比选择性配额更糟。当披露通道完全关闭时，研究人员只能等待、寻找其他联系人，或保留尚未披露的漏洞。

维护者还要承担心理成本。反复出现的错误主张会让审查者预期看到噪音，从而增加他们忽视一份有效但不够完美报告的风险。

安全社区此前也遇到过这种模式。静态分析器和自动化扫描器同样产生了大量低置信度警报。

组织的应对方式是要求提供复现、严重性背景和责任归属。AI 扩大了同一问题，因为它可以加入具有说服力的语言和拟议的漏洞利用叙事。

因此，新一代控制措施类似于垃圾信息过滤。信誉、速率限制、结构化证据和自动化聚类，都有助于维持开放通道的可用性。

安全报告不同于普通垃圾信息，因为少见的有效消息可能极其重要。严格的误报过滤器可能恰恰抑制供应商最需要的那份报告。

这使透明度至关重要。研究人员应了解自己剩余的提交容量、被拒绝的原因，以及获得更高配额所需的证据。

他们还需要一条面向高置信度发现的紧急通道。这条通道应要求更强的证据，但不应取决于等待通用冷却期结束。

计划可以在不把每位新研究人员都视为可疑对象的情况下抑制投机性提交。沙盒复现和机器可验证的工件提供了比单纯信誉更客观的门槛。

GitHub 的公开通道为新手提供了明确数量的机会。Apple 据称的流程则仍不够清晰，因为其默认配额和升级标准并未公开。

这一信息缺口如今也是风险的一部分。隐藏规则使合法研究人员更难规划，也让更广泛的社区更难评估。

Apple 的上限可以拦截噪音，也可能延误真实漏洞

核心风险不在于 Apple 拒绝 AI 输出；而在于数量限制可能将生产力误判为滥用。

Bynario 据称的经历正体现了这一担忧。该公司生成了数十项潜在发现，达到 Apple 的限制后，又识别出一条其认为严重的权限提升链。

这项技术主张尚未得到独立验证。未经 Apple 验证或公开公告，其据称的价值和严重性不应被视为既定事实。

不过，这一过程暴露了统一配额的弱点。基于未结报告数量的限制并不知道下一份提交是琐碎、重复，还是紧急。

如果 Bynario 较早的发现并不完整，该政策或许会完全按预期发挥作用。要求该公司验证并确定其优先级，将节省 Apple 的工程时间。

但如果数份报告有效、而后续漏洞链影响更高，它也可能造成本可避免的延误。现有公开证据尚无法判断哪种解释正确。

Apple 有充分理由要求克制。根据其 2025 年 10 月的赏金公告，该公司支持超过 23.5 亿台活跃设备。

影响常见 Apple 组件的漏洞，可能在 iOS、iPadOS、macOS、watchOS、tvOS 和 visionOS 中引发工作。一项根本原因可能需要多个协调发布版本来解决。

该公司在 2025 年末扩展了漏洞赏金计划，并强调完整的漏洞利用链，而非孤立的理论性漏洞。它还引入了 Target Flags 以加快验证。

Apple 的赏金计划扩展称，自 2020 年公开计划启动以来，公司已向研究人员发放超过 3,500 万美元奖励。已有超过 800 名研究人员获得奖励。

这些事实使“Apple 正在关闭大门”的简单说法变得复杂。该公司在收紧缺乏已证明影响的报告访问方式的同时，也提高了对高级研究的激励。

这一政策最好被理解为分层管理。Apple 希望获得经过深入验证的漏洞利用研究，而不是不受限制的机器生成疑虑流。

值得怀疑的问题是，其实施方式能否足够早地识别这种区别。除非 Apple 快速审查，配额申请就会变成另一条队列。

信誉系统也可能加剧既有的访问鸿沟。资深研究人员了解计划预期，并且通常拥有直接联系人；而新手依赖门户。

一名新研究人员可能拥有有效发现，但缺乏打包漏洞利用的经验。模型可以帮助解释问题，但这种协助可能会使报告看起来不那么可信。

Apple 必须避免将类似 AI 的写作风格作为无效性的替代指标。风格无法证明漏洞是否可复现，或是否跨越了有意义的边界。

最安全的过滤器应评估证据。只要拥有可靠的概念验证，一份简洁报告就应得到关注，无论 AI 是否协助发现或描述该问题。

研究人员同样承担责任。他们应复现每项发现、删除推测性主张，并将可观察行为与模型解释区分开来。

他们应明确具体的安全边界，并说明攻击者最终可获得的能力。提交每一个候选项，是将未完成研究的成本转嫁给供应商。

以机器速度生成发现的团队也需要进行内部自行分诊。他们应聚类重复项、测试当前版本，并按已证明的影响对问题排序。

可搜索的工程知识库可以保存测试证据、受影响版本和先前报告。这些记录有助于研究人员避免重复或相互矛盾的提交。

供应商应以更清晰的状态信息作为回应。研究人员需要知道 Apple 是否复现了某个案例、是否将其关联至现有工作，或是否需要补充证据。

更好的沟通会减少重复报告和反复尝试重新开启已解决案例的行为。它也会让配额决定看起来不那么随意。

如果验证成为共享协议而非私下判断，Apple 与 Google 之间的差异将会缩小。发现者和接收者都需要随主张一同流转的证据。

三个信号将表明 Apple 是否找到了恰当平衡

下一项考验在于，Apple 是否会将紧急提交控制措施转化为透明、基于证据的系统。

第一个信号是公布明确的配额规则。Apple 应说明未结报告如何计入上限、限制多久重置一次，以及研究人员如何获得更多提交容量。

这些信息将强化“上限是一项经过校准的防御措施”的论据。持续的模糊性则表明，合法研究人员仍面临不可预测的访问条件。

第二个信号是机器可验证证据的应用范围是否扩大。Apple 可以将 Target Flags、安全复现环境或其他结构化检查扩展到更多漏洞类别。

成功扩展将表明，Apple 正在降低分诊成本，而非仅仅减少参与者数量。若一个门户主要依赖人工例外处理，这一结论就会被削弱。

第三个信号是，在未来几个发布周期内如何对待高产研究人员。安全公告将揭示，使用 AI 辅助的团队是否仍会因经验证的发现而获得署名。

Apple 在 2026 年 7 月发布的更新中，已向 Anthropic 研究人员、Claude、OpenAI Codex Security、Z.AI 的 GLM 以及 NVIDIA 的 AI Red Team 致谢。这一记录表明，只要 AI 辅助工作促成了确认后的修复，Apple 就会予以认可。

未来的致谢名单将显示，该配额是否保留了这一高效渠道。独立研究人员署名的大幅减少可能意味着过滤过度，尽管仅凭署名无法证明因果关系。

Google、GitHub 以及大型开源项目提供了有价值的比较参照。它们的计划也正转向结构化证据、研究人员信誉和有边界的接收机制。

其影响将超越漏洞赏金计划。AI 系统正从代码建议转向自主测试、漏洞利用、分诊和修复。

漏洞发现速度将持续提升。人类安全团队无法再按报告到达的顺序逐一处理由此产生的队列。

他们需要让可利用性清晰可见、合并重复发现，并快速分流高影响案例的流程。他们还需要一条紧急通道，在常规配额耗尽后仍保持开放。

研究人员应在未来一到三个月内留意 Apple 指南的修订。他们也应在使用有限的提交额度之前，记录每一个复现步骤。

企业安全团队在内部也面临同样的挑战。AI 扫描器产生的警报可能多于开发人员能够调查的数量，因此部署指标必须奖励已确认的风险降低成果。

统计发现数量会鼓励追求规模。统计可复现漏洞、已完成修复和暴露面减少，才能鼓励有价值的安全工作。

这正是 Apple 与 Google 对比带来的长期启示。胜出的安全计划不会是那个让 AI 点出最多潜在漏洞的计划。

而会是那个以最少无效投入，将已验证发现从发现阶段推进到修复阶段的计划。Apple 的上限争取到了时间，但后续走向必须由基于证据的接收机制决定。

对于研究人员而言，眼下的行动很简单：提交前先验证，保留测试证据，并清楚说明被突破的安全边界。对于供应商而言，责任同样直接：为经得起这些检查的证据保留一条可靠的上报通道。

Apple 会不会公布更清晰的配额制度，并扩展机器可验证的提交方式？还是研究人员仍将在达到上限后才发现规则？答案将表明，这一上限究竟是在保护 Apple 的分诊团队，还是仅仅把瓶颈转移到了别处。