"AI 漏洞风暴":构建"Mythos-ready"安全项目
原文:The "AI Vulnerability Storm": Building a "Mythos-ready" Security Program 发布方:CSA CISO 社区、SANS、[un]prompted、OWASP Gen AI Security Project 等联合发布 作者:Gadi Evron(Knostic CEO)、Rich Mogull(CSA 首席分析师)、Robert T. Lee(SANS 首席 AI 官) 特约作者:Jen Easterly(前 CISA 局长)、Bruce Schneier、Chris Inglis(前白宫国家网络总监)、Heather Adkins(Google CISO)、Rob Joyce(前 NSA 网络安全总监)、Phil Venables、Katie Moussouris 等多位业界领袖 发布日期:2026 年 4 月 13 日(Version 0.4) 许可协议:CC BY-NC 4.0
一、执行摘要
发生了什么?
- Anthropic 推出的 Claude Mythos 模型显著提升了攻击者发现新漏洞、编写复杂利用代码、并在大规模自动化攻击中加以组合的能力。
- 虽然 AI 同样加快了补丁开发速度、减少了新软件缺陷,但由于打补丁本身的固有局限,防御方承受的相对负担更重,攻击者获得了非对称优势。
与现状有何不同?
- 短期内,安全团队很可能会被 AI 发现的漏洞、利用代码和自主攻击压得喘不过气,难以及时打补丁和响应。
如何应对当前的风险激增?
- 调整风险计算方式,重新配置安全项目资源,以应对补丁数量激增、修复时间压缩、攻击更复杂持续的新局面。
- 回归基本功、进一步加固环境:网络分段、出站过滤(egress filtering)、多因素认证(MFA)、纵深/广度防御。
未来会发生什么?
- Project Glasswing 披露的漏洞风暴只是第一波,类似大规模 AI 发现的漏洞浪潮将快速连续到来。
- Mythos 所展示的能力将很快被更广泛获取,组织面临的复杂新型攻击将在数量和频率上急剧增加。
为下一波浪潮,现在还应该做什么?
- 优先构建健全的依赖管理体系,降低第三方和开源组件中的漏洞风险。
- 在开发流程中持续执行自动化安全评估,包括使用 LLM 驱动的 Agent 在攻击者之前找到漏洞。
- 在整个网络安全团队中引入 AI Agent,让防御方匹配攻击方的速度,开始缩小差距。
- 重新评估运营停机(漏洞修复导致)的风险容忍度,以适应更短的对抗时间线。
- 更新治理流程,加快供应商准入,并增加人员编制以支撑 AI 防御技术的更快部署。
- 作为整个行业,需要加强联盟、合作与协调。
二、给 CISO 的关键要点
1. 利用基于 LLM 的漏洞发现与修复能力
与防御性 AI 技术不同,基于 LLM 的漏洞发现能力已经成熟,可以立即为你所用。从现在开始,可以让 Agent 对任何代码做安全评审,并逐步建立 VulnOps(漏洞运营) 能力。
2. 更新风险指标
许多现有的指标和风险评估可能已经过时,会影响业务汇报。考虑如何更新这些指标,并与利益相关者沟通这一挑战。
3. 用 Coding Agent 加速团队
尽管防御性 AI 技术落后于进攻性 AI,但 Agent 已经可以加速从事件响应到 GRC 的所有人工工作。鼓励并要求团队使用这些 Agent 来加速能力建设:分诊和测试补丁、红队演练、自动化审计数据收集、整体加速安全运营。
4. 准备应对更多事件
- 针对同一周内发生的多起高严重性事件开展桌面演练,为高级别关键事件准备应对手册。
- 尽可能自动化修复能力。
- 验证并启用诸如网络分段、出站过滤、零信任架构、抗钓鱼 MFA、密钥轮转等缓解控制。
- 供应链将受到影响。
5. 更加关注基本功
基本功依然有效,可以优先处理那些无法通过其他方式缓解的风险:网络分段、已知漏洞打补丁、身份与访问管理(IAM)、纵深/广度防御。趁还有时间,扩大这些工作可降低潜在风险。
6. 为职业倦怠做准备
漏洞披露的节奏和数量将超越以往任何经验。请求额外人员和预算作为储备,避免在自动化落地前耗尽现有员工。
7. 演进到 Mythos-ready 安全项目
Mythos 可能只是网络安全风险诸多变化中的一个。如果还没有开始,现在就要认真考虑把 Mythos 及其影响纳入战略规划。
8. 立即构建集体防御
攻击者早已以团伙形式运作 —— 众包、共享工具、整体联动。现在就与行业协调组织、ISAC、CERT 和标准机构合作,共享威胁情报、协调响应、制定行业专项指导。尤其要关注那些处于 Wendy Nather 所提出的"网络贫困线"之下的组织。
三、引言
关于 AI 在漏洞研究、利用和自主攻击方面能力的许多假设可能已经过时。2025 年全年至 2026 年,能力持续提升的例子在研究和真实世界攻击中不断出现。
Anthropic 的 Claude Mythos(Preview) 代表了这一轨迹上的阶跃式变化:它能自动发现主流操作系统和浏览器中的数千个关键漏洞,在没有人类指导的情况下生成可用的利用代码,并以远超以往任何能力的速度和规模实现自主攻击编排。
这种不对称性是结构性的:AI 降低了发现和利用漏洞的成本和技能门槛,其速度比组织打补丁的速度更快。从漏洞发现到武器化的时间窗口已经压缩到小时级。攻击者获得不成比例的收益,而当前的补丁周期、响应流程和风险指标都不是为这种环境而设计的。
📉 根据 Zero Day Clock(由 Sergej Epp 维护)的数据:从漏洞披露到被武器化的平均时间(Time-to-Exploit, TTE)从 2018 年的 2.3 年骤降到 2026 年的 20 小时。
Mythos 为什么重要?
Mythos 与之前的能力相比,在技术和战略两个层面都与众不同:
- 无需脚手架的漏洞利用。Anthropic 内部测试显示,Mythos 对 Firefox 生成了 181 个可用的利用代码;同样条件下,Claude Opus 4.6 只成功 2 次 —— 说明 Mythos 在自主性和可靠性上都有实质性飞跃。
- 复杂的链式漏洞。Mythos 能识别由多个原语串联而成的漏洞,例如将多个内存破坏 bug 合成一条利用路径。
- "单次提示"(One-shot)能力。Mythos 无需复杂脚手架或 Agent 配置,用单个 Prompt 就能完成远多于以往的任务。
战略上,Mythos 已突破技术圈,登上主流媒体,打进董事会。这迫使安全团队必须做出回应,也为行业带来了新的资源和资金投入。
Glasswing 项目
Mythos 的规模和速度促使 Anthropic 发起了 Project Glasswing,这可能是历史上规模最大的多方漏洞协调努力。Anthropic 为精选的关键基础设施提供商、行业合作伙伴、开源维护者提供了 Mythos 的早期访问权限,以便他们提前修补自己的产品。其他 AI 模型厂商也启动了类似的受限参与项目。
Glasswing 的最大限制在于:它能覆盖的范围有限。全球可被利用的攻击面,远大于任何策划好的合作伙伴生态系统所能覆盖的范围。同时,如果类似的进攻能力在几个月内出现在其他前沿模型中、并在 6 个月到 1 年内出现在开放权重模型中,那么早期访问带来的防御优势将在本质上受时间限制。
四、LLM 进攻能力演进时间线(2025/6)
| 日期 | 事件 |
|---|---|
| 2025-06-24 | XBOW 登顶 HackerOne 美国排行榜,首个在该平台上超越所有人类黑客的自主系统。开源的 raptor 表明任何人都能用现成 Agent 开展自主漏洞研究。 |
| 2025-08-05 | Google Big Sleep 在 FFmpeg、ImageMagick 等开源项目中自主发现并复现了 20 个真实零日漏洞。 |
| 2025-08-08 | DEF CON 33 上的 DARPA AIxCC 决赛,在 5400 万行代码中用 4 小时计算时间发现了 54 个漏洞。 |
| 2025-09 | Heather Adkins(Google CISO)和 Gadi Evron(Knostic CEO)发出警告:攻击者正冲刺"奇点时刻",自主漏洞发现和利用"距离约 6 个月"。 |
| 2025-11-14 | Anthropic 披露:一个中国国家支持的组织使用 Claude Code 自主运行完整攻击链(从侦察到数据外泄),针对约 30 个全球目标(2025 年 9 月中旬被发现)。 |
| 2026-02-05 | Anthropic 使用 Claude Opus 4.6 在开源软件中报告了 500+ 高危漏洞。AISLE 发现 12 个 OpenSSL 零日,其中包括一个可追溯到 1998 年的 CVSS 9.8 漏洞。Sysdig 记录了一次 AI 驱动的攻击 8 分钟内获得管理员权限。Gambit 披露了对墨西哥政府基础设施的 AI 主导攻击。 |
| 2026-03 | Linux 内核 bug 报告从每周 2 个升至每周 10 个,最初多为幻觉,现全部为真实 bug。curl 项目因 AI 生成的"垃圾"报告而停止 bug 赏金计划,但同样反映出 AI 辅助的高质量发现在快速增长。 |
| 2026-03 | [un]prompted 大会举行;Zero Day Clock 发布,将武器化时间可视化为已跌破 1 天。 |
| 2026-04-07 | Claude Mythos Preview 发布。Anthropic 宣布 Project Glasswing。在所有主流 OS 和浏览器中发现数千个零日,利用成功率 72%,包括一个 27 年前的 OpenBSD bug。 |
五、Mythos-ready 安全项目
应对方式必须是运营级、事件响应级和战略级三位一体的,重在项目长期建设。这要跨越三个时间范围推进。
Mythos-ready 项目应先达成最低可行弹性(minimum viable resilience),然后在关键指标上升级到更高成熟度 —— 例如:利用成本、早期入侵检测、爆炸半径控制。
超越应用安全与漏洞管理
- 运营层面:预计 Glasswing 早期访问计划中约 40 家厂商会密集发布补丁,类似最近两周内多起供应链事件的场景。
- 风险管理层面:业务风险正在变化,与利益相关者就风险规划和容忍度进行沟通是关键。CISO 控制风险的能力被削弱,这可能对业务汇报和预测产生影响。
- 战略层面:长期差距分析、对各项职能的选择性整顿将带来收益,包括支持更快技术准入的治理流程、以及创新 AI 驱动安全控制的落地。
这是许多浪潮中的第一波
Mythos 只是未来 AI 技术颠覆的第一波。在构建 Mythos-ready 项目时,目标不仅是回归平衡,更是为未来的浪潮做准备。
人力成本
领导者必须清醒地认识这一转型的人力成本。安全团队被夹在两面夹击中:一方面 AI 加速了他们必须应对的漏洞量,另一方面组织发布的代码量在增加、攻击面在扩大。再加上将 AI 整合到自身工作流程的认知强度 —— 员工已经满负荷,却要吸收指数级增长的工作量,人手、工具、健康方面却没有相应投入。
倦怠和流失是直接的运营风险 —— 这种转型所需的专业知识稀缺、需要多年培养、在短期内无法替代。团队韧性(可持续工作量、心理健康支持、人员保留)应与 AI 带来的技术挑战一样被视为战略优先级。
时间窗口在收缩
行动时间在减少,需要找到更快的方式前进。长期目标最多应被视为一个季度之外的事情。
六、10 个问题:理解你的安全项目现状和影响力
| 问题 | 背景 |
|---|---|
| 我们当前对 AI 的实际立场是什么? | 允许、容忍、限制,还是未知? |
| 员工今天能否在企业中使用 Agent 化的编码工具? | 不只是 Chatbot 访问 —— 是否针对 Coding Agent 部署了安全护栏? |
| 员工能否在没有法律模糊性的情况下为开源做贡献? | 这是法律和知识产权问题,不是技术哲学问题。 |
| 我们对代码仓库、制品、软件(包括 MCP 服务器、插件、技能等 Agent 化供应链)有纪律性的管控吗? | 源代码控制、包路径、制品来源。 |
| 代码变更和生产之间是否有真正的冷却点/安全卡口? | 展示发布周期中安全的执行力度。 |
| 安全是运营型还是主要咨询型? | 安全职能能直接影响结果的程度,还是仅作为评审和上报? |
| 过去一年公司最快的一次安全驱动生产变更用了多久? | 用真实案例,不是政策陈述。 |
| 我们的"皇冠珠宝"是否被明确跟踪并保持最新? | 不是理论上重要的系统,是实际最重要的那几个以及它们的主要依赖。 |
| 我们是否知道如何让关键第三方优先处理紧急工作? | 功能请求、Bug 报告、安全升级、关系所有权和杠杆。 |
| 高管层是否对"紧急"有可用的定义? | 如果什么都是危机,那就什么都不紧急。 |
七、Mythos-ready 安全项目风险登记册(草稿)
CRITICAL(关键风险)
| # | 风险 | 类型 | 描述要点 | 对应优先行动 |
|---|---|---|---|---|
| 1 | 加速的威胁利用:AI 自主生成利用代码,速度达到机器级 | 威胁 | 复杂攻击的速度、规模与所需技能门槛均急剧下降。每个补丁都变成利用蓝图 —— AI 能快速做补丁差分和逆向工程 | PA 4, 5 |
| 2 | AI 自动化能力不足:防御方以人类速度工作,而攻击方已加装 AI 增强 | 能力差距 | 很多防御团队还不了解可用的等效能力,或缺乏部署的安全控制 | PA 1, 2 |
| 3 | 无管理的 AI Agent 攻击面:现有控制框架未覆盖权限 Agent | 漏洞 | Agent 是抵御 AI 速度威胁所必需,但默认是特权且不安全的。包括内部 Agent 和来自第三方的供应链风险 | PA 3 |
| 4 | 事件检测与响应速度不足:人类速度对抗机器速度攻击 | 能力差距 | 告警分诊量、SIEM 关联速度、遏制授权延迟都是为人类节奏设计的 | PA 9, 10 |
| 5 | 过时的网络安全风险模型:利益相关者基于前 AI 时代的假设做决策 | 治理 | 过时的风险模型可能导致对防护措施的资金不足 | PA 6 |
HIGH(高风险)
| # | 风险 | 描述要点 | 对应行动 |
|---|---|---|---|
| 6 | 资产和暴露面清单不全:未知攻击面、代码、依赖、影子 Agent | 攻击者可以用低成本扫描整个 OS 代码库。Coding Agent 扩散到非开发人员,进一步碎片化中心 IT 可见性 | PA 7 |
| 7 | 不安全的软件交付流水线:代码未经一致的安全评审就发布 | AI 生成的代码引入漏洞的数量高于人工开发。风险是复合的 | PA 1 |
| 8 | 网络架构不足以遏制横向移动:扁平或分段不足 | AI 驱动的攻击会自动化多跳横向移动 | PA 8 |
| 9 | 持续漏洞管理成熟度差距:对 AI 发现的零日做响应式姿态,无 VulnOps 职能 | 季度渗透测试和被动打补丁周期跟不上 AI 驱动的发现速度 | PA 11 |
| 10 | 威胁检测依赖滞后情报:CVE 和 KEV 情报结构上落后于 AI 发现速度 | CVE 体系可能跟不上 AI 生成的发现速率,新型漏洞在 KEV 中没有按定义的条目 | PA 9, 10 |
| 11 | 创新治理和监督缺口:治理真空造成审批摩擦,阻碍防御性 AI 的采用 | AI 加速的时间线让这种摩擦有了更紧迫的截止日期 | PA 2, 4 |
| 12 | 因 AI 发现漏洞产生的监管和责任敞口:随着 AI 扫描广泛可用,合理注意义务的标准在改变 | EU AI Act(2026 年 8 月)引入了自动审计、事件报告和围绕 AI 的网络安全要求。董事会将面临质询:是否使用了可用的 AI 工具做防御扫描;不使用是否构成疏忽 | PA 1, 4 |
MEDIUM(中等风险)
| # | 风险 | 描述要点 | 对应行动 |
|---|---|---|---|
| 13 | AI 炒作和混乱造成系统性不作为 | 威胁和技术指导的信号/噪声比崩塌,安全领导者在噪声中难以导航 | PA 1 |
八、优先行动清单(草稿 · 激进时间表)
💡 "对于周一早上需要带着计划走进会议室的 CISO" 的快速参考。假设了激进的时间表,对某些组织可能不现实。
| # | 行动 | 类别 | 风险 | 开始 | 周期 | 含义 |
|---|---|---|---|---|---|---|
| 1 | 将 Agent 指向你自己的代码和流水线 | 风险控制 | CRITICAL | 本周 | 持续 | 把 Agent 和 LLM 能力向内转,指向自己的代码和依赖。立即开始:让 Agent 对任何代码做安全评审;逐步建立 CI/CD 内的完整审计;通过将能力直接加入开发者的 Coding Agent 实现左移。所有代码(人工或 AI 生成)在合并前都应通过 LLM 驱动的安全评审。可用工具包括:Anthropic 的 Claude Code Security、OpenAI 的 Codex Security;开源:Knostic 的 OpenAnt、raptor(Claude Code 框架)、exploitation-validator Agent 技能、Trail of Bits 的 Agent 技能 |
| 2 | 强制要求采用 AI Agent | 运营支持 | CRITICAL | 本周 | 持续 | 将 AI Agent 的使用(主要以 Coding Agent 的形式)正式化为所有安全职能的一部分,并配有强制的安全控制和监督。可选采用计划未能克服文化障碍,而采用率是达成后续行动的限制因素 |
| 3 | 保卫你的 Agent | 风险控制 | CRITICAL | 本月 | 45 天 | Agent 未被现有控制覆盖,同时引入网络防御和 Agent 化供应链风险。Agent 的"外壳"(Prompt、工具定义、检索管道、升级逻辑)是最关键的失败点 —— 审计它时要像审计 Agent 权限一样严格。部署到生产环境前,定义范围边界、爆炸半径限制、升级逻辑和人工覆盖机制。不要等业界治理框架,现在就定义你自己的 |
| 4 | 建立创新与加速治理 | 治理 | CRITICAL | 本周 | 6 个月 | 建立跨职能机制(安全、法务、工程),评估新的进攻性威胁,加快防御性技术的引入。没有这一点,其他所有行动都会遇到审批摩擦,对攻击者有利 |
| 5 | 为持续打补丁做准备 | 风险控制 | CRITICAL | 本周 | 45 天 | 随着漏洞发现和报告的增加,尤其是 Glasswing 让 Mythos 对主要软件厂商可用,准备分诊和部署能力以应对即将到来的补丁洪流 |
| 6 | 更新风险模型和汇报 | 治理 | CRITICAL | 本周 | 45 天 | 审查并更新安全风险指标、汇报、业务风险计算,反映 AI 加速的利用时间线和攻击复杂性。前 AI 时代关于补丁窗口、利用稀缺性、事件频率的假设可能不再成立 |
| 7 | 盘点并减少攻击面 | 风险控制 | HIGH | 本月 | 90 天 | 使用 Agent 可以大幅加速清单维护,支持持续更新。从关键的面向互联网的系统开始,在 45 天内建成全覆盖清单。生成真正的 SBOM。积极关闭不需要或无人维护的功能,淘汰不符合更新漏洞管理要求的供应商,隔离或气隙(airgap)处于风险中的系统。你不能保护你不知道存在的东西 |
| 8 | 加固你的环境 | 风险控制 | HIGH | 本月 | 6 个月 | 基本功仍然有效。实施出站过滤(它曾阻止每一次公开的 log4j 利用)。尽可能执行深度网络分段和零信任。锁定依赖链。对所有特权账户强制使用抗钓鱼 MFA。每一道边界都会增加攻击者成本 |
| 9 | 建立欺骗防御能力 | 风险控制 | HIGH | 接下来 90 天 | 6 个月 | 部署 Canaries 和 Honey Tokens,叠加行为监控,预授权遏制行动,构建在机器速度执行的响应手册 |
| 10 | 建立自动化响应能力 | 风险控制 | HIGH | 接下来 90 天 | 12 个月 | 提升检测工程和事件响应能力,让它们系统化并尽可能自主。示例:资产和用户行为分析、预授权遏制行动、以机器速度执行的响应手册 |
| 11 | 建立 VulnOps | 风险控制 | CRITICAL | 接下来 6 个月 | 12 个月 | 长期看没有替代方案 —— 必须建立永久性的漏洞运营(VulnOps)职能,像 DevOps 一样由人员配备和自动化驱动,但针对的是自主漏洞研究和修复。拥有对整个软件资产(从自有代码到第三方软件)中零日漏洞的持续发现能力,并建立自动化的修复流水线。从一开始就围绕分诊纪律设计 VulnOps |
九、面向高管和董事会的简报:AI 风险总结
Mythos 现在已是董事会议题,这也是一个机会。为领导层准备的谈话要点围绕两件事:说明现有项目的价值,以及为下一步做商业论证。
谈话要点:AI 让双方都变快
AI 让我们变得更快、更有竞争力。但同样的能力也让攻击者变得更快、更危险。它把从"漏洞存在"到"造成严重事件"的时间从数周压缩到了数小时,而这个差距还会继续缩小。
但反过来用,这些工具能让我们在对手之前先找到并修复自己的弱点。如果不关注这场"买断风险"(buying down risk),我们作为业务前进得更快的同时,也会同样快速地累积风险。
谈话要点:需要一个激进的计划
这不是一个开放式的 AI 倡议,而是在寻求对齐,以执行一个明确所有者和结果的 90 天激进计划:
- 增加人力和容量。规划现有员工的重新调配(尤其是在工程团队内)或新员工和承包商的引进,以应对预计增加的分诊、修复和事件工作,同时保护经验丰富的员工免受倦怠(特别是当第一波 Glasswing 补丁来袭时)。
- 部署 AI 工具。将 AI Agent 的使用正式化为所有安全职能的标准实践:扫描自己的代码、确保代码发布前有 AI 驱动的评审、为团队配备定制化 Agent。这让团队能以与对手相同的速度运作。
- 加固基础设施。优先更新资产清单,减少不必要的暴露,强制执行分段、零信任、出站过滤和抗钓鱼认证。在内部系统和关键第三方供应商(MSP、SOC)之间验证这些要素。
- 加快采购和治理。跨职能团队(安全、法务、工程)对齐,评估威胁并加速优先防御技术的引入。当前的审批周期对即将到来的威胁环境来说太慢了。
- 更新手册。更新技术和通信响应计划,以所需速度和规模执行,包括对并发事件的预授权遏制和协调。
- 跟踪进展。在 90 天周期内定期检查以获取结果并识别路障。
十、结论和建议
基于 AI 的攻击代表了进攻与防御之间工作方式的结构性转变,它不会改变。漏洞发现的成本和能力门槛在下降;从披露到武器化的时间正朝着零压缩;以往需要国家级资源的能力正变得广泛可用。
虽然对 Mythos 的漏洞发现能力已经在早期 AI 模型中存在,但 Mythos 的发布抓住了董事会的注意力。防御方可以抓住这个机会,为成为"Mythos-ready"做出有力的商业论证,为即将到来的补丁浪潮做好准备。
"Mythos-ready" 意味着
- 设计一个有弹性的架构,限制攻击者利用已发现漏洞的能力,并在漏洞被利用时遏制影响;
- 在任何对手(或厂商公告)之前自己发现更多漏洞;
- 以规模化的方式快速响应事件并遏制影响,最大限度地减少业务中断;
- 用 AI Agent 加速你的安全项目和员工能力。
让你的团队从今天起就使用 AI 进行防御。这份简报中的每一个行动,都可以在本周开始。
历史先例
这不是行业第一次面对系统性挑战。Y2K 是一个有硬截止日期的系统性威胁,行业通过协调、有纪律的努力成功应对。现在面临的是同一种问题,需要同样的响应方式,而防御方手里有更强大的工具。
构建"Mythos-ready"安全项目,不是对某一个模型或公告的反应,而是永久性地缩小"漏洞被发现的速度"与"你的组织能响应的速度"之间的差距。
本文为 CSA 文档的中文全面摘要翻译,具体技术细节和完整引用请参阅原文。 联系方式(询问):cisos@cloudsecurityalliance.org
