Project Glasswing: Mythos 展示给我们的启示

标题：Project Glasswing：Mythos向我们展示了什么

文章来源：https://blog.cloudflare.com/cyber-frontier-models/

发布时间：2026-05-18T14:00+08:00

2026-05-18

9 分钟阅读

过去几个月，我们一直在自己的基础设施上测试一系列以安全为重点的大语言模型（LLM）。这些LLM帮助识别我们系统中的潜在漏洞，以便我们能够修复它们——同时它们也向我们展示了攻击者将能够利用最新模型做些什么。

在这些LLM中，最引人注目的莫过于Anthropic的Mythos Preview。几周前，我们受邀使用Mythos Preview作为Project Glasswing的一部分。我们很快将其指向了我们自己的五十多个代码库——看看它能发现什么，以及它是如何工作的。

这篇文章分享了我们观察到的内容、模型的优点和不足，以及围绕它们的架构和流程需要如何改变，以便能够大规模使用。

Mythos Preview带来的变化

Mythos Preview是一个真正的进步，在深入讨论之前，这一点值得明确说明。我们运行模型分析代码已有一段时间，从之前通用前沿模型的能力到Mythos Preview如今的表现，不仅仅是之前的改进。

它是一种不同类型的工具，做着不同类型的工作，这使得与早期模型进行清晰的同类比较变得困难。因此，与其试图将Mythos Preview与通用前沿模型进行基准测试，更有用的是描述它实际能做什么，以及我们在使用Mythos Preview过程中突出的两个特性：

• 漏洞利用链构建 - 真正的攻击很少只利用一个漏洞。它将几个小的攻击原语串联成一个有效的漏洞利用。例如，它可能将一个释放后使用（use-after-free）漏洞转化为任意读写原语，劫持控制流，并使用面向返回的编程（ROP）链来完全控制系统。Mythos Preview可以获取多个这样的原语，并推理如何将它们组合成一个有效的证明。它在此过程中展示的推理看起来像是一位资深研究员的工作，而不是自动化扫描器的输出。

• 证明生成 - 发现一个漏洞和证明它是可利用的是两件不同的事，而Mythos Preview可以两者兼顾。它会编写触发可疑漏洞的代码，在一个临时环境中编译该代码并运行它。如果程序的行为符合模型的预期，那就是证明。如果没有，模型会读取失败信息，调整其假设，然后再次尝试。这个循环与它发现的漏洞同样重要，因为一个没有有效证明的可疑缺陷只是推测，而Mythos Preview自行弥补了这一差距。

我们上面描述的一些内容并非Mythos Preview所独有。当我们通过相同的测试框架运行其他前沿模型时，它们也发现了相当数量的相同底层漏洞，并且在某些情况下，它们在推理方面也比我们预期的走得更远。它们的不足之处在于将各个部分整合在一起。一个模型可能会识别出一个有趣的漏洞，写下一段深思熟虑的描述说明其重要性，然后就停止了，留下未完成的实际利用链和悬而未决的可利用性问题。Mythos Preview带来的改变是，一个模型现在可以获取那些低严重性漏洞（传统上会隐藏在待办列表中）并将它们串联成一个单一的、更严重的漏洞利用。

模型在合法漏洞研究中的拒绝行为

Anthropic作为Project Glasswing一部分提供的Mythos Preview模型，没有普遍可用模型（如Opus 4.7或GPT-5.5）中存在的额外安全防护措施。

尽管如此，该模型会有机地（organically）抵制某些请求——就像使其对漏洞搜寻有用的网络能力一样，该模型有其自身 emergent 的防护栏（guardrails），有时会导致其抵制合法的安全研究请求。但正如我们所发现的，这些有机的拒绝行为并不一致——相同的任务，以不同的方式构建或呈现在不同的上下文中，可能会产生完全不同的结果，如下面的例子所示。

_Mythos Preview拒绝构建有效概念验证（PoC）的示例_

例如，该模型最初拒绝在一个项目上进行漏洞研究，然后在项目环境发生不相关的更改后，同意对相同的代码执行相同的研究。被分析的代码本身没有任何变化。在另一种情况下，模型在代码库中发现并确认了几个严重的内存漏洞，但拒绝编写演示性的漏洞利用程序。相同的请求，以不同的方式构建，得到了不同的答案，甚至由于模型的概率性质，相同的请求在不同次运行中也可能产生不同的结果。语义上等效的任务，根据它们呈现给模型的方式和时间，可能会产生相反的结果。

这一点很重要，因为虽然模型的有机拒绝/防护栏是真实存在的，但它们不够一致，无法单独作为完整的安全边界。这正是为什么任何未来普遍可用的、有能力的网络前沿模型都必须在此基线行为之上包含额外的安全防护措施——使其适合在像Project Glasswing这样的受控研究环境之外更广泛地使用。

信噪比问题

在评估安全漏洞时，最困难的部分之一是判断哪些漏洞真实存在、哪些具有可利用性、哪些需要立即修复。即便在人工智能尚未普及的时代，这已是棘手难题。AI漏洞扫描器和AI生成代码的出现加剧了这一挑战，因此Cloudflare构建了多重后验证阶段来应对。

误报率主要受两大因素影响：

• 编程语言 - C和C++语言提供直接内存控制能力，随之带来的缓冲区溢出、越界读写等漏洞类别，在Rust等内存安全语言中可通过编译阶段消除。我们观察到，采用非内存安全语言的项目 consistently 产生更多误报。

• 模型偏差 - 优秀的人类研究员会明确告知发现内容及其置信度，而模型不具备这种能力。要求模型寻找漏洞时，无论代码是否存在问题，它总会给出结果。这些发现往往伴随着"可能"、"潜在"、"理论上可以"等模糊表述，且存疑结论的数量远超确凿结论。对于探索性工具而言，这种偏差尚可接受，但对于评估队列却是灾难性的——每个推测性发现都会消耗人力进行验证驳回，这种成本在数千个发现中会持续累积。

Mythos预览版在这方面实现显著提升，尤其是其链式原语能力——将多个漏洞组合成可运行的概念验证方案，而非孤立上报。附带PoC的发现可直接付诸行动，极大减少了验证"该漏洞是否真实存在"的时间消耗。

我们故意将检测框架调整为过度报告模式，从而扩大检测范围（减少漏报），但代价是噪声激增。不过在评估阶段，Mythos预览版的输出质量明显更高：模糊结论更少、复现步骤更清晰、决策修复或驳回的工作量大幅降低。

为何通用编码代理无法直接应用于代码库

去年启动AI辅助漏洞研究时，我们最初本能地采用直观方案：将通用编码代理指向任意代码库并要求其发现漏洞。这种方法确实能产生发现，但无法实现对真实代码库的有效覆盖和有价值漏洞的识别。主要原因有二：

• 上下文限制 - 编码代理专精于单一工作流：功能构建、缺陷修复或代码重构。它们会摄入大量源代码，每次仅持有一个假设并进行迭代。这与漏洞研究的需求背道而驰——漏洞研究本质是狭窄且并行的。人类研究员会选择特定目标深入调查，可能是某个复杂功能、安全边界转换或特定漏洞类别（如命令注入，即攻击者输入最终被作为shell命令执行）。他们会针对不同功能、安全边界或漏洞类别重复此过程，在代码库中执行数千次。而单次代理会话（即使使用子代理）面对十万行规模的代码库时，最多仅能覆盖约千分之一的有效表面，随后模型上下文窗口就会饱和并触发压缩机制——这可能丢弃之前的重要发现。

• 吞吐量限制 - 单流水线代理每次只能处理一个任务，但真实代码库需要同时对多个组件进行多重假设验证，并在出现可疑迹象时快速展开深度检测。虽然可以强行提升单个代理的负载，但最终瓶颈不再是模型能力，而是交互模式本身。当研究员已有线索并需要辅助审查时，直接在编码代理中使用模型确实适合人工调查。但若要实现高覆盖率，这就是错误的工具。认清这一点后，我们不再强迫Mythos预览版执行不合适的任务，转而围绕其构建专用检测框架。

检测框架的实际改进效果

大规模实践得出四项核心经验，每项都指向需要整体执行管理框架：

• 狭窄范围产生更优质发现 - 指令"在该代码库中寻找漏洞"会导致模型盲目游荡。而指令"在该特定函数中寻找命令注入漏洞，上方存在此信任边界，这是架构文档和该区域既往覆盖记录"能使其执行更接近研究员实际工作的操作。

• 对抗性审查降低噪声 - 在初始发现与评估队列之间插入第二代理（使用不同提示词、不同模型且无自主发现能力），可捕获首轮代理自查时遗漏的大量噪声。事实证明，让两个代理形成刻意对立的审查机制，远比单纯要求单个代理谨慎工作更有效。

• 跨代理拆分链式推理提升分析质量 - "这段代码是否存在缺陷？"与"攻击者能否从系统外部实际触达该缺陷？"本质是两个独立问题。分开提问时模型对每个问题的处理效果更佳，因为单个问题的聚焦度高于复合版本。

• 并行窄域任务优于单一 exhaustive 代理 - 当多个代理处理精确定义的问题后再进行结果去重，比要求单一代理实现 exhaustive 覆盖能获得更好的检测覆盖率。

这些观察都是关于模型行为的，它们共同描述了一种不再仅仅是聊天界面的工具。它是一个帮助你实现最终成果的框架。构建这样一个框架的最初步骤很简单，你可以直接让模型来协助——这正是我们所做的。我们利用 Mythos Preview 来构建、调整并改进我们原有的框架，以充分发挥其优势。下面是一个实际应用中的框架示例。

我们的漏洞发现框架

以下是我们的漏洞发现框架逐步的工作流程。该框架被用于扫描我们运行时、边缘数据路径、协议栈、控制平面以及我们所依赖的开源项目中的实时代码。

阶段功能重要性 **

侦察一个代理从上到下读取代码库，将任务分配给负责每个子系统的子代理，并生成一份架构文档，涵盖构建命令、信任边界、入口点以及可能的攻击面。同时，它还会为下一阶段生成初始任务队列。为所有下游代理提供共享上下文。减少漫无目的的问题。

搜寻每个任务包含一种攻击类型和一个范围提示。搜寻器（实际查找漏洞的代理）并发运行，通常一次约五十个，每个搜寻器会分配少量探索子代理。每个搜寻器可以使用工具，在每项任务的临时目录中编译和运行概念验证代码。这是大部分工作发生的地方。许多狭窄的任务并行进行，而不是一个 exhaustive 代理。

验证一个独立的代理重新阅读代码，尝试反驳最初的发现。它使用不同的提示，并且没有能力自行发出新的发现。捕获了相当一部分搜寻器在审查自己工作时无法发现的噪音。

填补空白搜寻器标记它们接触过但未彻底覆盖的区域。这些区域会被重新加入队列进行另一轮处理。抵消模型倾向于偏向已经成功的攻击类型的趋势。

去重具有相同根本原因的发现会被合并为一条记录。变体分析是一个功能，而不是用重复项填充队列的方式。

追踪对于共享库中每个已确认的发现，一个追踪代理会进行分发（每个消费者代码库一个实例），使用跨仓库符号索引，并判断攻击者控制的输入是否真的能从系统外部到达该漏洞。将“存在缺陷”转化为“存在可触达的漏洞”。这是最重要的阶段。

反馈可触达的追踪结果会在实际暴露漏洞的消费者代码库中成为新的搜寻任务。形成闭环。流水线在运行过程中会不断改进。

报告**一个代理根据预定义的架构编写结构化报告，自行修复针对该架构的任何验证错误，并将报告提交至接收 API。输出是可查询的数据，而非自由格式的文本。

这对安全团队意味着什么

其他安全领导者对 Mythos Preview 最强烈的反应是关于速度——更快地扫描、更快地打补丁、压缩响应周期。我们交谈过的多个团队现在正遵循从 CVE 发布到生产环境打补丁的两小时服务级别协议（SLA）。这种本能是可以理解的：当攻击者的时间线缩短时，防御者的时间线也必须随之缩短。但仅仅更快是不够的，我们认为很多团队即将花费大量时间、精力和金钱来艰难地学习这一点。

更快地打补丁并不会改变产生补丁的流水线形态。如果回归测试需要一天时间，那么不跳过它就无法实现两小时的 SLA，而跳过回归测试所引入的漏洞往往比你试图修补的漏洞更严重。当我们尝试让模型自己编写补丁时，我们学到了这一点：我们观察到一些补丁修复了原始漏洞，却悄悄地破坏了代码所依赖的其他部分。

更困难的问题在于，围绕漏洞的架构应该是什么样子。原则是即使漏洞存在，也要让攻击者难以利用，从而使得漏洞披露和修补之间的时间差变得不那么重要。这意味着需要在应用前端设置防御措施，阻止漏洞被触达。它意味着设计应用时，确保代码某部分的缺陷不会让攻击者访问到其他部分。它意味着能够同时将修复推送到代码运行的每一个地方，而不是等待各个团队单独部署。

我们也意识到这个话题具有两面性。帮助我们查找自身代码漏洞的相同能力，若落入恶意分子手中，将加速针对互联网上所有应用程序的攻击。Cloudflare 为数百万个应用程序提供防护，而上述架构原则正是我们产品为客户提供保护所遵循的核心准则。未来几周内，我们将进一步分享这对客户意味着什么。

如果您的团队正在进行类似工作并希望交流经验，请通过security-ai-research@cloudflare.com联系我们。

_我们使用Mythos Preview进行的研究是在受控环境中针对自身代码开展的；通过此项工作发现的所有漏洞均经过分级处理、验证，并根据Cloudflare正式漏洞管理流程在需要时进行了修复。_

_此项工作是团队合作的成果。感谢Albert Pedersen、Craig Strubhart、Dan Jones、Irtefa Fairuz、Martin Schwarzl和Rohit Chenna Reddy为本博客文章背后的研究、工程和分析工作做出的贡献。_

安全人工智能智能体威胁情报大语言模型风险管理威胁运营自动化工程