Project Glasswing: what Mythos showed us¶

Ch01.281 Project Glasswing: what Mythos showed us¶

📊 Level ⭐⭐ | 13.2KB | entities/cloudflare-glasswing-mythos-security.md

核心要点¶

Mythos Preview 是 Anthropic 在 Project Glasswing 框架下提供的安全专用 LLM，在漏洞发现与利用链构造上相比通用模型有质的飞跃
Mythos Preview 能将低危漏洞链式组合成可利用的高危漏洞（Exploit Chain Construction），而不仅是报告孤立问题
模型自带的有机拒止（organic refusals）行为不一致，无法作为唯一安全边界，需额外防护层
通用编码 Agent 不适合仓库级漏洞挖掘——需要窄作用域 + 多 Agent 并行 + 对抗性验证的 Harness 架构
对安全团队而言，仅加快扫描/修补速度不够，架构层面的深度防御才是关键

背景¶

Project Glasswing 是 Anthropic 推出的安全研究合作项目，邀请外部团队在其受控环境中测试 Mythos Preview 等安全专用 LLM 。Cloudflare 在过去数月对多种安全 LLM 进行了内部测试，随后获得邀请，将 Mythos Preview 用于扫描其五十余个代码仓库。

Mythos Preview 的核心能力跃升¶

Exploit Chain Construction（利用链构造）¶

真实攻击极少使用单一漏洞，而是将多个小的攻击原语（attack primitives）链接成完整利用。例如：将 use-after-free 转换为任意读写原语 → 劫持控制流 → 用 ROP 链完全接管系统。Mythos Preview 能够接收多个原语并推理如何将其组合成可工作的 Proof，其推理过程看起来像是资深安全研究员的思路而非自动化扫描器的输出。

Proof Generation（证明生成）¶

发现漏洞与证明其可利用性是两回事。Mythos Preview 能编写触发可疑漏洞的代码，在沙盒环境中编译运行，根据结果调整假设并重试——形成闭环。未能触发预期的程序崩溃意味着假设需修正；成功触发则构成证明。这弥合了"可疑缺陷"与"可行动漏洞"之间的鸿沟。

与通用模型的关键差距¶

通用前沿模型在单独漏洞识别上表现尚可，但往往止步于"找到漏洞→描述影响"的阶段，无法将碎片拼接成完整利用链。Mythos Preview 的本质差异在于：能将传统模式下沉在 backlog 中的低危漏洞链式组合为单一高危漏洞。

模型拒止行为的不一致性¶

Mythos Preview（Project Glasswing 版本）不含通用版本（如 Opus 4.7、GPT-5.5）的额外安全护栏，但模型本身仍涌现出有机拒止行为——对某些合法安全研究请求主动推回。问题是这些有机拒止不一致：同一任务，换一种表述或上下文，可能得到完全相反的结果。Cloudflare 观察到：

模型先拒绝研究某个项目，更改项目环境后（代码本身未变）又同意了同一研究请求
模型发现并确认了多个严重内存漏洞，随后拒绝编写演示利用程序；换一种表述方式后请求获得同意
相同请求在不同运行中因模型概率特性产生不同结果这意味着任何面向公众的网络安全前沿模型都必须叠加额外安全护栏，而非依赖模型自身的有机行为。

信噪比问题¶

编程语言因素¶

C/C++ 提供直接内存控制，引入缓冲区溢出、越界读写等漏洞类，而 Rust 等内存安全语言在编译时消除这类问题。Cloudflare 观察到内存不安全语言项目的误报率显著更高。

模型偏见¶

人类研究员会告知发现内容和置信度；模型不会。模型会对"是否存在漏洞"这个问题回答"是"——无论代码是否真的有问题。返回结果充满"possibly"、"potentially"、"could in theory"等修饰词，这类试探性发现远多于确定性发现。在分流队列中，每条试探性发现都消耗人工注意力和 Token，且成本随发现数量指数增长。 Mythos Preview 在减少噪声方面有明显改善：更少的修饰性发现、更清晰的复现步骤、更少的三言两语决定。

为什么通用编码 Agent 不适合仓库级漏洞挖掘¶

上下文错配¶

编码 Agent 针对单一聚焦工作流调优：构建特性、修复 bug、重构代码。摄入大量源码、保持单一假设、迭代验证——这恰恰是漏洞研究的反面。人类研究员每次专注研究一个具体问题（特定复杂特性、安全边界穿越、命令注入等漏洞类），然后重复数千次。一个 Agent 会话面对十万行代码仓库，有用覆盖率约千分之一，且模型上下文窗口填满后早期发现可能被丢弃。

吞吐量局限¶

单流 Agent 一次只做一件事，但真实代码库需要同时多假设多组件验证，并在发现有趣线索时进一步扩散。在达到模型能力上限前，交互形态本身已成为瓶颈。

Cloudflare 的漏洞发现 Harness 架构¶

Cloudflare 总结出四方面经验，最终形成八阶段管道： 1. 窄作用域产生更好发现 — 告知模型"在这特定函数中查找命令注入，信任边界如附所述"比让其自由发挥更接近真实研究过程 2. 对抗性审查减少噪声 — 在初步发现与队列之间加入第二个 Agent（不同提示、不同模型、无独立发现能力），catch 住第一个 Agent 会遗漏的大量噪声 3. 将链拆解到多个 Agent 产生更好推理 — "这段代码有漏洞吗？"与"攻击者能否从系统外部 reach 这个漏洞？"是两个不同问题，分开询问时模型对每个问题表现更优 4. 并行窄任务优于单一穷举 Agent — 多个 Agent 处理紧密限定的问题、事后去重，比让一个 Agent 穷举更有效

八阶段管道详解¶

阶段	功能	意义
Recon	Agent 自顶向下读取仓库，扩散到各子系统子 Agent，产出架构文档（含构建命令、信任边界、入口点、攻击面）并生成下一阶段任务队列	为所有下游 Agent 提供共享上下文；解决漫游问题
Hunt	每任务 = 一个攻击类 + 作用域提示；Hunters（实际找漏洞的 Agent）并发运行（约五十个），各自扩散到若干探索子 Agent，可编译运行 PoC 代码	主要工作量发生地；多窄任务并行，非单一穷举 Agent
Validate	独立 Agent 重读代码并尝试推翻原始发现；使用不同提示、无独立发现能力	catch 住 Hunter 自查时遗漏的大量噪声
Gapfill	Hunters 标记已触及但未充分覆盖的区域；重新排队进行第二轮	对抗模型倾向于向已有成功经验的攻击类漂移的倾向
Dedupe	共享根因的发现合并为单条记录	变体分析是特性，非重复队列膨胀方式
Trace	对共享库中每个确认发现，Tracer Agent 扩散（一库一实例），利用跨库符号索引判断攻击者控制输入是否真正从系统外部 reach 该漏洞	将"存在缺陷"转化为"存在可达漏洞"；这是最关键的阶段
Feedback	可达 traces 成为实际暴露漏洞的消费仓库中的新 Hunt 任务	闭环；管道随运行越发精确
Report	Agent 按预定义 Schema 撰写结构化报告，自修 validation 错误，提交到 ingest API	输出为可查询数据，非自由文本

对安全团队的影响¶

业界对 Mythos Preview 的最强烈反应集中在速度——更快扫描、更快修补、压缩响应周期。一些团队已设定 CVE 发布到生产修补两小时 SLA 。

速度不够¶

加快修补速度不改变产生补丁的管道形态。如果回归测试需要一天，强行达成两小时 SLA 意味着跳过回归测试，而那样发布的 bug 往往比被修补的 bug 更严重。Cloudflare 曾尝试让模型自写补丁，结果修好了原 bug 但悄悄破坏了代码其他依赖。

架构优先¶

真正的问题是漏洞周围应该是什么架构。原则是：即使漏洞存在也让攻击者更难利用，使漏洞披露与修补之间的窗口期变得不那么关键。这意味着：

在应用前方设置防御，阻断对漏洞的 reach
设计应用使代码某一部分的缺陷不能导致攻击者访问其他部分
能够同时将修复部署到代码运行的每一个位置，而非等待各团队独立部署

深度分析¶

安全 LLM 的能力跃升不是增量而是质变 — Mythos Preview 的 Exploit Chain Construction 将传统安全扫描的"报告孤立漏洞"升级为"构造完整利用链"，这意味着同样一批低危漏洞，Mythos 可以将其链式组合为可远程利用的高危漏洞，使原本被忽略的 backlog 变成真实攻击面
有机拒止是真实但不可靠的安全边界 — 模型涌现的拒止行为确实存在，但因上下文敏感性、表述方式和概率特性而不一致。这意味着部署安全 LLM 时必须叠加额外的规则层和人工审核，而非假设模型自身能正确拒止所有恶意请求
Agent 形态决定漏洞挖掘质量上限 — 通用编码 Agent 的单流、长程、穷举式交互范式与漏洞研究的窄作用域、多假设、并行验证需求存在根本性错配；瓶颈不在模型能力而在交互架构本身
Reachability（可达性）是漏洞发现的核心分水岭 — Cloudflare 八阶段管道中最关键的是 Trace 阶段——将"代码存在缺陷"转化为"缺陷从系统外部可达"。无法 reach 的漏洞实际攻击价值极低，这一筛选步骤直接决定安全团队资源的分配效率
速度型响应 SLA 是危险的误导 — 两小时 CVE 到生产修补的 SLA 隐含假设是漏洞披露与修补之间的窗口是主要风险来源；但如果为此跳过回归测试或放弃架构防御，实际上是在加速引入更严重的 bug

实践启示¶

为安全 LLM 构建专用 Harness 而非直接对话 — 采用 Cloudflare 的八阶段管道思路：Recon（建立共享上下文）→ Hunt（多窄任务并行找漏洞）→ Validate（对抗性审查过滤噪声）→ Trace（可达性验证）→ Feedback（闭环迭代），而非让单一 Agent 自由探索代码库
在安全 LLM 输出层叠加确定性规则过滤 — 由于有机拒止不一致，安全 LLM 的输出必须经过规则引擎和人工审核双重关卡；对利用代码生成、Exploit PoC 编写等高危操作尤其需要明确的黑名单策略和审批流程
以可达性而非漏洞存在性作为修复优先级依据 — 建立 Reachability 分析流程，对每个确认漏洞追踪其从外部入口点的可达路径；仅对可达漏洞触发紧急修复流程，不可达漏洞可进入常规迭代队列
将深度防御架构置于响应速度之上 — 优先建设应用前方防御层（阻断 reach）、代码隔离架构（限制横向移动）和统一部署能力（同时修复所有运行实例），而非单纯压缩修补周期
安全 LLM 应针对编程语言风险做差异化配置 — C/C++ 项目的误报率显著更高，应为内存不安全语言项目配置更激进的后验证阶段和更严格的可利用性门槛，同时优先推动关键路径迁移至 Rust 等内存安全语言

关联阅读¶

待补充