Amazon 和 Apple 面临人力难以及时消化的 AI 安全积压

Amazon 和 Apple 的安全团队如今面临一个直白的逆转：AI 发现软件漏洞的速度，已超过人类工程师验证、排序和修复它们的速度。

Apple 最近的安全更新以具体方式展现了这一变化。其 7 月操作系统更新将 Claude、OpenAI Codex Security 及其他 AI 工具列为协助研究人员发现漏洞的贡献者。这些致谢出现在仅数周前另一批异常庞大的修复之后。

这一故事远不止一次 Apple 更新。Amazon Web Services、Apple、Google、Microsoft 及其他基础设施提供商加入了 Anthropic 的 Project Glasswing，以便在攻击者发现关键缺陷之前抢先找到它们。如今，漏洞发现的速度正超过传统安全工作流程的处理能力。

这带来了一个令人不安的结果。更好的漏洞检测并不会立即带来更安全的软件。它首先会带来更多已知问题、拥挤的接收队列，以及关于哪些弱点值得投入稀缺工程资源的艰难选择。

Anthropic 表示，其合作伙伴在 Glasswing 的早期部署期间发现了超过 10,000 个高严重性或关键严重性漏洞。该数字仍是公司自行汇总报告的结果，并非经外部独立审计的完整公开目录。

不过，单项成果提供的证据比这一头条数字本身更有力。获得 AI 协助的研究人员已在 Apple 公告中获得署名，而 Mozilla 和开源维护者也已处理大量相关发现。安全竞赛正在从“谁能发现漏洞”转向“谁能率先将发现转化为可靠补丁”。

AI 辅助发现已进入 Apple 的发行说明

决定性的变化在于，AI 辅助漏洞研究已从实验室基准测试进入生产环境的安全更新。

Apple 7 月 27 日的安全文档，在 iPhone、iPad、Mac 和 Safari 软件的多个版本中列出了若干 AI 系统和研究人员的贡献。这些文档紧随更早的更新而来，后者修复了借助 Claude 和 OpenAI Codex Security 发现的 WebKit 缺陷。

WebKit 是 Apple 的浏览器引擎，负责处理 Safari 及许多应用中的网页内容。由于多个产品采用同一底层组件，其中的弱点可能影响多个 Apple 平台。

7 月的一项披露将一处 WebKit 释放后使用漏洞归功于与 Claude 合作的研究人员。这类漏洞发生在软件释放内存后仍继续使用该内存时，可能导致崩溃或恶意代码执行。其他条目则将发现独立缺陷归功于 Codex Security。

这些致谢并不意味着某个 AI 系统独立完成了研究的每一个阶段。漏洞研究还包括选择目标、构建测试环境、验证影响、复现故障，以及负责任地与厂商沟通。

人类研究人员依然掌控着这条链路中的关键环节。尽管如此，Apple 的公告表明，AI 已足够有用，能够与具名专家一同获得公开认可。

节奏同样值得关注。Apple 在其 26.5.2 版本发布后不久公布了篇幅很长的 7 月文档；这些版本已交付了最初与后续开发周期相关的修复。一篇安全发布评测指出了修复数量以及 AI 工具作用的持续扩大。

这并不能证明 Apple 已失去对其安全流程的控制。厂商经常协调大量修复，而更长的公告也可能反映出可见性提升，而非代码质量恶化。

不过，发行说明提供了一个可验证的信号：漏洞发现能力已经发生变化。研究人员现在可以引导语言模型分析陌生代码，要求它们跨组件推理，并利用其输出指导更深入的测试。

较早的自动化扫描器通常会寻找已知模式，或生成触发意外行为的输入。较新的模型则能够就不同代码路径如何交互形成假设，并在测试失败后修正这些假设。

这一差异使 AI 对成熟软件格外重要。Apple 的操作系统历经多年的内部测试、外部研究、模糊测试和真实世界使用。随着代码库接受更多审查，容易发现的缺陷理应变得更少。

AI 可以重新审视这些成熟代码，而不必继承早期审查所遵循的每一种假设。它能够以任何个人研究人员都无法长期维持的规模，反复检查隐蔽路径。

结果并非一次戏剧性的入侵，而是一股持续增长、可信的发现流，正进入 Apple 现有的披露和发布机制。这股发现流构成了 Amazon 和 Apple 安全故事背后的核心压力：检测正变得更便宜，而负责任的修复仍然昂贵。

为什么 Amazon 和 Apple 的安全团队承受压力

Amazon 和 Apple 并不缺乏安全专业能力；真正限制它们的，是每一项经验证发现所带来的重大决策数量。

Anthropic 于 2026 年 4 月 7 日推出了 Project Glasswing。其首批成员包括 Amazon Web Services、Apple、Broadcom、Cisco、CrowdStrike、Google、JPMorganChase、Linux Foundation、Microsoft、Nvidia 和 Palo Alto Networks。

该联盟获得了对 Claude Mythos Preview 的受控访问权限，这是一款专为高级网络安全工作设计、尚未发布的模型。Anthropic 限制访问，是因为帮助防御者发现并组合弱点的同类能力，也可能帮助攻击者。

Glasswing 的目标听起来很直接：在相当的工具扩散到恶意操作者手中之前，定位关键软件缺陷。真正的运营挑战始于模型返回一个看似有价值的结果之后。

厂商必须首先判断报告描述的是否为真实弱点。随后，工程师会评估哪些受支持版本受到影响、易受攻击的路径是否可达，以及攻击者需要哪些权限。

仅凭严重性标签无法回答这些问题。一处技术上严重的内存漏洞，可能在标准配置中无法触及；而一处看似轻微的授权错误，如果与另一个缺陷结合，可能暴露敏感账户。

团队还需要识别重复报告。多名使用相似模型的研究人员可能独立发现同一弱点，并提交不同解释。Linux 开发者曾遇到这个问题，重复的 AI 辅助报告给一个私有安全邮件列表带来了压力。

完成验证后，工程师必须设计不会破坏合法行为的修复方案。他们需要通过测试证明，修复既能封堵原有弱点，又不会引入新问题。成熟平台还需满足跨硬件世代、应用、区域配置和企业部署的兼容性要求。

随后，Apple 还要跨相关操作系统协调补丁。AWS 面临的是不同但同样严苛的环境，包括云服务、开源依赖、托管基础设施以及由客户控制的配置。

这正是 Amazon 和 Apple 被并列讨论的原因，尽管两家公司运营不同的平台。两者都支撑着被大量个人和组织使用的系统。仓促发布的补丁可能以小型开发者极少面对的规模干扰用户。

延迟补丁则有其自身风险。一旦有关弱点的足够信息变得可得，攻击者就可能逆向分析修复方案，或自行复现发现过程。

Google 已描述过一起事件：犯罪分子在攻击一个此前未知的漏洞时使用了 AI 模型，随后被其阻止。该公司未披露该模型或受影响厂商的身份。根据这起AI 利用案例，调查人员发现证据表明攻击者曾使用 AI 发现该弱点。

这一事件打破了一个令人安慰的假设：防御者不能依赖高级 AI 漏洞发现能力始终被限制在可信联盟内。

因此，Amazon、Apple 及其同行正面临双向压力。防御模型正在增加报告数量，而进攻性使用者则可以缩短从发现到尝试利用之间的时间。

增聘审查人员只能部分缓解问题。经验丰富的安全工程师稀缺，新员工仍需要产品知识。更深层的需求是重新设计一条流程管线，利用自动化完成验证、去重、可利用性评估、补丁生成和回归测试。

在这些阶段加速之前，更好的发现能力增加队列的速度将快于它降低风险暴露的速度。

真正的瓶颈已从发现漏洞转向修复漏洞

AI 已将漏洞发现转变为一个吞吐量问题，但软件修复仍依赖人类问责和产品语境。

Anthropic 表示，Glasswing 合作伙伴在该计划的第一个月内识别出超过 10,000 个高严重性或关键严重性漏洞。其项目初始更新还描述了涉及数百个开源项目的直接披露。

这些说法需要谨慎解读。一项发现可能代表疑似缺陷、经验证的漏洞，或已通过另一渠道获知的弱点。汇总众多合作伙伴的结果，也可能掩盖方法论和严重性评估上的差异。

Anthropic 表示，会在披露前进行人工审查，并努力让提交量与维护者的处理能力相匹配。其政策以常规的 90 天披露期限为目标，同时允许在特殊情况下采用其他协调时间表。

这一政策承认了一个重要冲突。快速公开有助于用户了解自身风险，但在补丁覆盖所有受影响系统之前，披露也可能向攻击者提供路线图。

将报告私下保留可避免即时曝光，但也会形成不断增长的已知弱点库存。使用独立模型的攻击者无须等待公开公告。

因此，瓶颈远不止编写代码补丁。安全团队必须判断哪些报告需要立即处理，哪些可以纳入常规发布，哪些需要临时缓解措施。

他们还必须决定模型提出的利用方式是否代表现实攻击。自主系统可以在简化的测试环境中生成令人印象深刻的演示，却忽略生产环境中已有的防御措施。

反过来，模型也可能低估一个微妙的缺陷，因为它不了解客户如何组合使用各种功能。当技术严重性与实际业务风险出现分歧时，人类的产品知识仍不可或缺。

这正是 AI 漏洞研究背后的主要权衡。模型提供速度和广度，但其输出可能带来高昂的验证成本。高误报率会占用处理真实紧急事件所需的同一批审查人员。

Apple 更新后的漏洞赏金指南明确警告不要提交冗长的 AI 生成描述。其条款还将反复高频提交不正确或未经验证的 AI 辅助报告列为有问题的行为。

这种立场并不否定 AI 辅助研究。Apple 自己的安全公告也对成功使用 AI 的研究人员表示了致谢。它所划定的界限，是基于证据的发现与自动化推测之间的界限。

一份高质量报告必须包含清晰的技术描述、可复现的步骤，以及证明该问题会影响受支持配置的证据。这些要求能将原始模型输出转化为产品安全团队可评估的内容。

同样的区分也适用于企业内部。在整个代码库上运行 AI 扫描器，比建立一条从警报到已部署修复方案的可信路径要容易得多。

有效的内部流程需要可复现的测试用例、责任归属信息、依赖关系映射和发布控制。缺少这些要素，模型只会再生成一个充满警告的仪表盘。

知识管理成为安全系统的一部分，因为团队必须将新发现与早先的事件、架构决策和既往修复关联起来。当这些记录仍然分散时，可搜索的工程知识库可以减少重复调查。

AI 也能支持修复工作。模型可以起草补丁、生成回归测试、比较类似修复方案，并总结受影响组件。然而，最终变更仍需由明确负责的所有者承担责任。

发现工作可以持续并行运行。生产环境发布则仍受制于审查、测试、部署窗口和用户采用情况。这种不对称解释了为何即使每项工具都按预期运作，积压仍可能不断增长。

更多发现并不自动意味着 Apple 软件更不安全

已披露漏洞数量激增，可能意味着检测能力更强、风险更大，或两者兼有；因此，原始数量无法衡量 Apple 的安全态势。

最容易得出的解释是，AI 暴露了 Apple 代码库异常薄弱的问题。现有证据并不支持这一结论。

Apple 开发了多个操作系统、浏览器组件、云服务和硬件安全机制。庞大的攻击面天然会比范围狭窄的应用程序带来更多缺陷机会。

其产品也吸引了独立研究人员、商业间谍软件供应商、政府和犯罪团伙的密切审查。更多关注会带来更多发现，即使底层工程质量保持稳定。

AI 进一步扩大了这种审查范围。模型可以反复检查被忽视的组件，并探索人工审查者跳过的交互。今天发现一个旧缺陷，并不意味着该缺陷是最近才出现的。

Glasswing 的一个案例涉及 OpenBSD 代码中的弱点，该问题经历数十年审查仍未被发现。另一个案例涉及经过广泛测试的媒体库 FFmpeg。这些案例支持一个更广泛的结论：即使经过大量人工分析，成熟且受尊重的代码仍可能保留缺陷。

Apple 的公开安全记录提供的是已修复问题的证据，而不是尚未解决弱点的完整清单。供应商通常会在交付修复后才披露细节，因为过早公开可能增加被利用的风险。

这使得标题中的说法难以精确衡量。外部人士无法计算有多少由 AI 生成的 Apple 报告尚未验证、有多少属于重复报告，或各个严重性等级的修复速度如何。

Anthropic 的汇总数据无法填补这一空白。Glasswing 覆盖许多组织和软件项目。其总数不应被视为 Apple 专属计数。

持怀疑态度的观点也质疑自主发现的质量。安全模型可能将崩溃误判为可利用的漏洞。它们可能生成措辞精致的叙述，夸大影响，或遗漏环境约束。

基准测试对这一问题的防护作用有限。模型可能在预设的漏洞任务中表现出色，却难以应对文档不完整、构建要求特殊的陌生生产系统。

人工协作使归因更加复杂。当一份公告感谢“使用 Claude 的”研究人员时，模型可能生成了决定性的假设；也可能只是加快了代码审查、测试创建或漏洞利用完善的速度。

这些限制都不意味着这项技术不重要。它们说明，AI 发现必须经过严格验证，才能改变发布计划。

Apple 的漏洞赏金计划现在为复杂漏洞利用链提供最高 200 万美元的奖励，加上奖金后最高金额可超过 500 万美元。漏洞赏金计划还使用目标标记，使研究人员能够证明漏洞利用已达成受保护目标。

这些激励措施能够提高报告质量，因为研究人员必须展示实际影响，而非仅仅产出令人信服的文字。它们也揭示了可信漏洞信息已变得多么有价值。

Apple 表示，其安全技术保护着超过 23.5 亿台活跃设备。这一规模提高了两类错误的代价：忽略有效报告可能使大量用户暴露于风险中，而部署有缺陷的补丁则可能干扰这些用户。

因此，正确判断应比最耸动的标题更为克制。AI 正在提高有用安全发现的数量和速度。公开证据并未证明 Apple 的工程师已经无法保护其平台。

它所表明的是，机器速度的调查与围绕人类规模发现而设计的发布流程之间，存在日益扩大的错配。即使长期安全性有所改善，这种错配也会造成危险的过渡期。

受限的 AI 访问无法永远维持优势

Project Glasswing 为防御者争取了时间，但竞争对手和攻击者已经在削弱受控访问的价值。

Anthropic 最初因 Claude Mythos Preview 的进攻性潜力，仅向选定组织限制开放。该公司后来将 Glasswing 从约 50 家合作伙伴扩展至超过 15 个国家的约 150 家新增组织。

扩展让更多防御者获得同等类别的能力，同时也增加了必须保持安全的端点、凭证、工作流和人员。

Anthropic 面临的挑战并不只是防止公开下载模型。它还必须控制合作伙伴如何使用系统、提交哪些代码、发现结果存储在哪里，以及谁能够检索敏感结果。

模型本身并非唯一的风险来源。包含新发现漏洞的数据库可能成为颇具吸引力的目标。日志、第三方集成、研究人员账户和自动化测试基础设施同样如此。

与此同时，竞争实验室正在构建可比系统。OpenAI 已开发以网络安全为重点的工具，而 Google 持续推进 AI 辅助漏洞研究。也有报道称，其他开发者的模型正在特定安全任务上接近 Mythos。

基准测试上的持平并不自动等同于实际运营能力的持平。真实的漏洞研究依赖工具使用、长时间运行的任务、环境配置、漏洞利用验证，以及从失败方法中恢复的能力。

不过，方向已经很明确。Amazon 与 Apple 的联盟不能假定受限的 Mythos 访问能形成持久的防御性垄断。

传统漏洞发现也仍在这些计划之外持续进行。国家支持的团队、间谍软件供应商、犯罪团伙和独立研究人员早已具备专业能力。AI 可以在把新手变为专家操作者之前，先放大这些既有能力。

当模型缩短串联多个轻微缺陷所需的时间时，风险最大。现代平台依赖多重安全边界，因此攻击者往往需要的是漏洞利用链，而不是单个孤立漏洞。

浏览器漏洞可能提供初始立足点。沙箱逃逸可让代码越过浏览器进程边界。随后，内核弱点可能提供更高权限的控制。

能够跨越这些边界进行推理的模型，会提高此前看似难以组合的小型发现的价值。这使优先级排序变得更难，因为工程师无法孤立地评估每份报告。

防御者需要知道，一个低严重性问题是否补全了更大的攻击路径。AI 可以帮助识别这些关系，但攻击者也可以使用同样的推理。

因此，Amazon 与 Apple 的应对措施必须超越产出更多补丁。两家公司都需要分层控制措施，以便在未知或未修复漏洞遭利用时减少损失。

对 Apple 而言，这些层级包括沙箱、内存保护、代码签名、快速更新，以及面向遭受高度定向攻击用户的 Lockdown Mode。AWS 则依赖隔离、身份控制、监控、针对服务的缓解措施和协调一致的客户指引。

这些保护措施并不能消除修复积压，但能降低一个遗漏的缺陷演变为全面攻陷的概率。

短期内的竞争，并不是完美安全的供应商与无所不能的模型之间的竞争，而是两条都不完美的流程之间的竞争。防御者必须发现、验证、修复、测试、分发并监控；攻击者只需找到一条穿过这些防线的可行路径。

这种不平衡解释了为何更快的发现速度可能在带来长期安全之前，先增加短期危险。

三个信号将显示防御者是否正在追赶

下一阶段将通过经验证的补丁产出、更强的报告筛选，以及 AI 能否像加速发现一样有效加速修复的证据来衡量。

第一个信号是 Apple 获得 AI 贡献署名的安全修复节奏。未来的 iOS、macOS 和 Safari 公告应能显示，7 月的发布是暂时性集中，还是持续性的变化。

持续出现经验证的发现，将强化 AI 已成为 Apple 安全研究可靠组成部分的结论。致谢与修复之间的间隔缩短，也将表明 Apple 正在调整其发布流程。

更重要的衡量指标并不是致谢数量，而是 Apple 能否处理新报告，同时不延误高风险修复，也不发布不稳定更新。

Apple 不会公布所有内部时间指标。研究人员仍可以比较披露日期、CVE 记录、更新说明和后续致谢。持续一致的协调将削弱该公司只是被提交报告淹没的说法。

第二个信号是 Glasswing 的发现数量与完成补丁数量之比。Anthropic 的发现总数标题吸引了关注，但真正改变用户风险的结果是修复。

补丁率的上升将表明，参与公司和开源维护者正在将模型输出转化为生产环境改进。差距扩大则会证实漏洞接收量已超过工程能力。

分母的质量很重要。项目更新应区分疑似发现、经人工验证的漏洞、重复报告、已接受的披露和已部署的修复。

没有这些类别，一个庞大的总数就可能混合处于截然不同工作阶段的内容。透明的报告能帮助企业判断，类似计划带来的是有用的安全改进，还是昂贵的警报量。

第三个信号是 AI 辅助修复是否实现运营化。仅生成补丁是不够的，因为软件变更还需要回归测试、兼容性审查，以及针对原始漏洞利用的验证。

最有力的证据是将经验证的发现与经过测试的修复，以及清晰的人工审批链结合起来。能够可靠产出这套材料的工具，可以缓解瓶颈，而非只是不断向其中输送更多内容。

关注厂商是否会将可利用性评分、重复项检测、补丁建议和自动化测试生成整合到一个可控工作流中。碎片化工具可能只是在不同队列之间转移工作，并不会提升整体吞吐量。

企业买家还应询问供应商如何保护其漏洞处理流程。重要问题包括：谁可以访问未公开的发现、报告如何验证，以及紧急缓解措施能多快送达客户。

开发者也面临相关转变。安全工作将越来越多地涉及审查由模型生成的假设，而不是等待传统扫描器标记出已知模式。这要求更强的推理能力，而非更少的专业知识。

知识工作者和产品团队同样应当关注，因为修补决策会影响发布计划、客户沟通和合规义务。一旦多个有效漏洞需要争夺同一批工程师，安全队列就可能变成产品管理队列。

对用户而言，眼下的应对方式依然寻常却很重要：及时安装安全更新，淘汰不再受支持的设备，并在个人风险需要时启用更强的防护措施。

Amazon 与 Apple 的安全故事，归根结底关乎一个不断变化的约束条件。AI 让发现变得充裕；验证、优先级排序和安全部署如今决定了这种充裕究竟是在保护用户，还是只会暴露尚未完成工作的深度。

接下来的几个更新周期将揭示哪种结果正在占上风。请关注已验证发现与已部署修复之间的比例，而不是标题中最大的漏洞数字。