当一台机器能在 20 小时内仅凭漏洞描述写出可用的利用代码时，你没法靠打补丁跑赢它。别再试图优化一场你赢不了的游戏。

2026 年 7 月 14 日，白宫推出 Gold Eagle——一个联邦级协调机构，使用前沿 AI 在攻击者得手之前识别、排序并协调软件漏洞的修复，覆盖范围包括政府和关键基础设施。该项目整合了财政部、国土安全部、国防部、开源软件合作伙伴以及美国关键基础设施的运营方。其核心引擎正是 Anthropic 的 Mythos——正是这一类系统在测试中揭示了美国机密政府软件内部的关键缺陷。

政府动用先进 AI 来主动猎捕漏洞，这本身就是在承认一个根本事实：二十年来"人工逐个发现并逐个修补"的模式已经跟不上节奏了。

Gold Eagle 是国家层面的回应。但更棘手的问题是：在你自己的企业边界内，需要做出哪些改变？

Mythos 是一个前沿 AI 模型，能够挖掘出以往任何工具都发现不了的漏洞——从 OpenBSD 中一个潜伏了 27 年的远程崩溃缺陷，到不需要人工引导、可直接升级至完全系统控制的 Linux 内核链式漏洞。Anthropic 的 Project Glasswing 合作伙伴（约 50 家）已在基础软件中挖出了超过 1 万个高危或严重级别漏洞。

如果这种能力只留给防御者一方，倒还好。事实并非如此。2026 年 6 月，Anthropic 向公众发布了 Fable；其访问权限当月曾短暂因美国出口管制被暂停，随后又恢复——这本身就是一个信号：前沿漏洞发现能力已被视为受控技术，更接近军火而非 SaaS 产品。

看看我们面对的运营时间线：

• 攻击者速度： 2026 年 3 月，Sysdig 研究人员观察到威胁行为者在 CVE 公开后 20 小时内即开始利用，且当时没有任何公开的概念验证（PoC），仅凭漏洞描述就完成了武器化。Mandiant 的 M-Trends 2026 报告给出的平均利用时间（MTTE）为负 7 天——意味着利用代码如今常常跑在公开披露之前。

• 防御者滞后： Verizon 2026 数据泄露调查报告给出的已知被利用漏洞的中位修复时间为 43 天（前一年为 32 天），而仅有 26% 的漏洞被完全修补。

• 极端增量： 事件响应与安全团队论坛（FIRST）预测 2026 年全年新增约 5.9 万个 CVE——日均超 160 个——其中远程代码执行（RCE）漏洞较去年增长 130%。

传统的 CVE 体系根本无法应对这种数量与速度。

重思补丁流程。 思科重构了其 CVE 流程，因为他们意识到逐个评估风险不可持续，转而采用基于风险的披露模型，将通用弱点归入大类，并改为每月两次的发布节奏。政府也得出了同样结论：2026 年 6 月，CISA 的约束性操作指令 26-04（BOD 26-04）废止了 BOD 22-01（后者曾要求对 KEV 目录所有项目严格执行打补丁期限）。在 BOD 26-04 下，KEV 状态只是四个评估变量之一，其余三个维度分别是：公网资产暴露面、自动化可利用性，以及技术影响（部分控制 vs 完全控制）。我们正从"按期限把一切打上补丁"转向"按真实已实现的风险排优先级"。Palo Alto Networks 首席安全情报官 Wendi Whitmore 给董事会的提问是："如果明天一个漏洞被公开，附带 AI 生成的可利用代码，你承诺的修复时间线是什么？谁有权在不升级审批的情况下拍板执行？"

压缩暴露面。 你无法修补——也无法防御——你看不见的东西。发现资产、刻画互联网暴露服务、遗留主机和影子部署的攻击面，仍是基础一步。但在 AI 时代，暴露面管理已不只是开放端口的问题；它要求约束自主智能体和非人类身份被允许执行的操作。2026 年 7 月 Hugging Face 漏洞事件就是一个警示：一个自主 AI 智能体从数据处理管道进入，升级到节点级权限，并在单个周末内向内横向移动到多个内部集群。这个智能体所做的事，如果有一套合理的权限模型本不该发生——它只是拥有自由行动的空间。最小权限、严格受限的工具访问，以及为非人类身份（服务账号、API 密钥和 AI 智能体）设置爆炸半径限制，如今与打补丁本身同等关键。

弄清什么真的可被利用。 一个 CVSS 9.8 评分说明不了什么：组件在你的环境中是否面向互联网？利用链能否触达敏感数据？现有控制是否已经缓解？暴露面管理平台能够绘制真实环境中的真实利用路径，把上千条发现压缩成团队可以跟进的队列。这正是 BOD 26-04 所蕴含的逻辑：不在于漏洞是否存在，而在于它在你的架构下是否可被利用。

验证你的暴露面和控制的有效性。 SafeBreach 对 180 万次攻击模拟的分析发现，终端控制能拦截约 53% 的攻击，而以身份为切入点的隐蔽型攻击却能绕过那些能稳定阻止勒索软件的防御。SafeBreach、Picus、Cymulate 等厂商现已被归入 Gartner 所称的"对抗性暴露验证"（Adversarial Exposure Validation）品类——它们回答了静态扫描无法回答的问题："攻击者真的能利用这个吗？他能触及到什么？"

在漏洞出厂之前就阻止它。 AI 编程助手加快了开发速度，也带来了与之同步的漏洞激增——RCE 增长 130% 的趋势早于 Mythos 和 Fable，仅 AI 生成代码本身就推动了这种增长。应用安全平台把发现直接推入 IDE 和 CI/CD 流水线，并用 AI 追踪每个缺陷的根因以及代码库中的所有变体。某些厂商（如 Pi Security）将每一次修复视为机构级安全记忆，确保同一漏洞不会在新代码中重现。

• 审视真实的补丁节奏： 衡量过去 90 天内严重 CVE 的实际部署时间，而非政策目标。政策与现实之间的差距，就是你真正的暴露面缺口。

• 采用 BOD 26-04 分流模型：

• Bucket 1（事件响应）： 互联网暴露系统上正在被利用的漏洞，立即以事件级别响应，在打补丁前先做失陷排查。

• Bucket 2（加速修复）： 没有活跃利用迹象的严重级别发现，走快速部署通道。

• Bucket 3（标准维护）： 其余所有缺陷走标准化、自动化的补丁周期。

• 测试决策权限： 通过桌面推演测算紧急补丁所需的执行、运营、法务审批时间。周二下午两小时能走完的流程，周日凌晨两点可能需要十二小时。

• 用 AI 代码审计 AppSec： 用真实的 AI 生成代码样本测试你现有的扫描器。扫描器漏掉的部分，就是你的基线技术债。

• 重新思考漏洞悬赏与披露： 许多企业正在暂停漏洞悬赏项目，因为 AI 现在挖出的漏洞数量已超出内部团队物理上能验证的极限。在海量提交压垮你的团队之前，建立一条自动化分流流水线。

当一台机器能在 20 小时内仅凭漏洞描述写出可用的利用代码时，这场竞赛就已经结束了——别再试图优化一场你赢不了的游戏。未来十年能脱颖而出的组织，不会是那些单纯打补丁更快的组织。它们将是那些能够压缩暴露面、按真实可利用性排优先级、证明控制有效、在代码出厂前就堵住缺陷的组织。

这要求的不是流程优化，而是安全体系的重新设计。