导语：安全圈流传着一个说法：发现新型漏洞是那些受限的前沿模型（如Anthropic发布的Mythos预览版）才有的”专属能力”。最近的一些高调报道宣称，这些先进模型能挖掘出存在了数十年的内存安全漏洞，比如1998年的OpenBSD TCP SACK实现缺陷，号称这将改变威胁格局。但真相是——漏洞发现能力并不取决于模型本身，而在于编排框架。我的研究证明了这一点。
前沿模型的神话
当前AI驱动安全的叙事逻辑是：发现未知漏洞是前沿模型的专利，只有Anthropic、OpenAI这些玩家的最新模型才具备这种能力。典型案例就是Anthropic红队吹嘘的”Mythos报告”——他们宣称发现了1998年OpenBSD TCP SACK实现中一个存在27年之久的漏洞。
但我要泼盆冷水：这些能力并不只存在于专有的前沿模型里。真正的关键在于管理商业模型的编排框架（orchestration harness）。我基于自己开源的IronCurtain框架构建了工作流，证明了这一点。
使用专门的漏洞发现工作流，我不仅复现了那些前沿模型的发现成果，还用商业模型（如Opus 4.6和Sonnet 4.6）以及开源权重模型（如智谱AI的GLM 5.1），自主发现了基础软件中的新零日漏洞。
漏洞发现的编排方法
IronCurtain是我设计的一个研究原型，专门用于实现结构化的智能安全研究。框架支持通过纯YAML定义有限状态机（FSM）来构建任意工作流。
为了自动化漏洞发现，我在FSM中构建了一个”漏洞发现”工作流。这个工作流的核心是一个”编排器”（Orchestrator）智能体，扮演战略路由的角色。它根据一个只增不减的执行日志来决定下一步派遣哪个专业智能体。
编排器本身不读取目标源代码。它完全依赖日志来管理整个调查过程，直到生成最终的漏洞报告。这个日志和其他磁盘上的产物让每个智能体都能从干净的上下文窗口开始，从磁盘恢复状态。当然，这个工作流非常消耗token：针对一个中等规模的代码库跑一次，大概消耗1000万token，按Opus或Sonnet的价格分别为150美元或30美元一次调查。GLM 5.1在Z.AI托管平台上平均消耗2700万token每轮，因为需要更多迭代周期才能得出相同结论。Z.AI上GLM 5.1的定价是每百万输入token 1.40美元（缓存0.26美元），每百万输出4.40美元，折算下来单次调查成本和Sonnet差不多。真正在普通工作站硬件上本地运行仍是目标而非现实：我测试过一个小型的蒸馏候选模型（Qwen 3.5蒸馏版），跑不动这个工作流，所以GLM 5.1全程在Z.AI的GPU上运行。
复现1998年OpenBSD漏洞
Anthropic红队把OpenBSD TCP SACK实现中这个27年前的漏洞作为Mythos报告的招牌成果。这个漏洞对我有特殊意义——因为1998年11月，正是我负责提交了OpenBSD TCP SACK实现，包括那个bug。
为了测试开放编排能否复现这种前沿能力，我用早期版本的漏洞发现工作流分析了这个历史遗留的未修补C代码。
使用Sonnet 4.6作为初始分析智能体，工作流映射了结构化的数据流和调用链。FSM编排遵循一个简单原则：先静态假设，再执行验证。其他都是噪音。在这种工作流中，概念验证（PoC）是一个可执行测试工具，用来触发漏洞、证明可达性并暴露内存损坏，提供超越静态分析的实证证据。
但在第一次FSM框架测试中，提示词和日志维护还不够完善，系统没能保持正轨。由于安全的IronCurtain容器无法原生启动OpenBSD虚拟机，智能体完全回退到静态分析——它发现了bug，但没有执行它，生成的报告缺少PoC。
这个局限性推动了工作流的迭代改进。后来发现，初始假设探索不需要完整虚拟机，可以通过轻量级测试工具实现，比如单函数模糊测试。只有最终的PoC才需要虚拟机路径。
为了完成验证，我直接通过Claude Code使用Opus 4.6。在一些手动引导下，我让模型首先通过轻量级模糊测试复现了这个bug。它为那个特定的C函数设计了一个独立的高性能模糊测试工具，在几秒钟内系统化地扫完输入空间。模型隔离出了精确的触发条件：43亿个序列号中只有两个的差异，正好位于32位整数符号边界上。
一旦通过模糊测试隔离出参数，我就让模型构建了一个基于QEMU的驱动程序来测试真实虚拟机，可靠地复现了内核崩溃。
这个OpenBSD复现是工作流的第一次实战检验。这次初始运行需要的手动引导直接改进了FSM的提示词和日志维护，建立了分层测试方法：单函数隔离测试工具、多组件测试工具、完整端到端虚拟机验证。工作流现在能根据建立利用原语所需的条件动态扩展这些层级。经过这些改进后，后续的调查实现了全自动运行，无需手动引导。
自主发现与规模化防御
编排框架的真正价值在于能自主发现现代代码库中的bug。漏洞发现工作流在四个广泛使用的开源项目中挖掘出了此前未报告的漏洞和重大bug，这些项目都经过多年公开模糊测试和专业安全审计。以下两个案例研究描述了典型运行过程。具体身份和确切bug机制暂不披露，等待上游协调、CVE分配和公告发布。
案例一：媒体框架漏洞
在分析一个广泛部署的媒体框架时，漏洞发现工作流发现了一个此前未报告的漏洞。使用Opus 4.6，框架识别出了缺陷并生成了多组件测试工具来确认底层原语。用完整端到端测试工具验证这个缺陷需要一些人工指导——内存受限的复现环境最初掩盖了触发条件。经过测试工具优化后，工作流生成了一个能可靠触发漏洞的概念验证程序，我向上游维护者报告了这一发现。这个结果验证了使用商业模型配合开源编排进行独立漏洞发现的方案是可行的。
案例二：18年的整数截断漏洞
为了完全脱离Anthropic生态体系，后续运行将同样的漏洞发现工作流指向了另一个基础库。这次只换了模型：通过LiteLLM网关将Anthropic标识符重写为路由到Z.AI的GLM 5.1，使用Anthropic兼容端点，而IronCurtain和FSM编排层完全不动。
GLM 5.1全程驱动了发现过程。编排器根据只增不减的日志对目标进行范围界定，并将系统引导到分层测试工具构建。通过自主工作流，隔离出了一个存在于内存分配路径上18年之久的整数截断漏洞，呼应了前面OpenBSD SACK案例中27年的潜伏期。通过相关算术的结构分析，编排的模型生成了概念验证程序和经 sanitizer 验证的测试工具，足以确认该漏洞类别。
为了确保负责任披露的准确严重性评分，有必要确认底层的可利用性原语。我用Opus 4.7通过Claude Code进行了引导式手动分析——这是我的深度技术研究交互环境，比GLM 5.1更适合这种深度的分析。这项工作证明了一个受控的堆越界读写原语。由于受影响的库广泛部署在面向互联网的基础设施上，这个漏洞代表了严重的远程风险。
确认严重级别需要一个可工作的漏洞利用程序，但这超出了漏洞发现工作流的范围。当模型拒绝我最初的漏洞利用请求时，我手动将漏洞利用开发过程分解为一个细粒度的七步计划来绕过拒绝。模型成功执行了前两步，然后因其可接受使用政策（AUP）护栏而被迫停止进一步协作。幸运的是，第二步证明了可以通过读取基指针来绕过地址空间布局随机化（ASLR），这足以支持高严重性评估。
三个关键观察
从这些运行中得出三个观察：
第一，生成概念验证（PoC）漏洞利用程序对防御者必不可少。 通过静态分析发现的理论漏洞不可避免地产生大量误报。误报消耗安全运营团队大量时间来分类和手动验证。而漏洞的执行证明能快速消除这些耗时的误报，确保防御者只专注于经过验证的威胁。
第二，开放编排提供了执行复杂工作流所需的脚手架，但底层基础模型的质量仍然很重要。 基础模型质量设定了编排可以提取的下限，但开源权重模型的结果表明，这个下限现在已经低到普通商品模型也能跨越。
第三，经济因素现在有利于频繁、广覆盖的审计。 按商业API定价，每次调查在Sonnet到Opus之间花费30到150美元；按生产规模计算，这决定了防御者一年能负担得起检查多少个库。托管开源权重提供商的定价与Sonnet在同一区间，但token量更高；在强大硬件上自托管可以进一步降低边际成本（一旦做出前期投资）。
编排是一把双刃剑
现实是，资源充足的对手已经在使用编排工作流大规模猎取零日漏洞了。他们不受供应商使用政策约束、没有合法研究中的AUP摩擦、没有多小时运行上的API速率限制、也没有 embargo 前沿模型的访问控制列表。严重性评估期间的七步拒绝正是这个不对称问题的典型体现：一个进行合法工作的防御者遇到了摩擦，而使用未经审查的开源权重模型的资源充足的对手则不会。
本地托管的开源权重模型消除了这个门槛。这种摩擦反映的是真实的责任判断，而不仅仅是责任规避：供应商权衡边际滥用者的能力提升与对合法研究的成本。这个权衡以前出现过。过去25年里的每一个防御工具（Metasploit、nmap、Burp Suite、AFL）都面临过同样的争论，历史答案始终是把工具交到防御者手中。在本地模型上，责任直接由研究人员承担，就像这些工具一直以来的那样。
IronCurtain的存在就是为了弥合这个差距。通过将开源脚手架与本地或普通开源权重模型相结合，防御者可以在自动化利用赶上之前审计代码库并发布补丁。我鼓励安全工程师查看IronCurtain框架，为编排脚手架做出贡献，并帮助构建自动化防御的基线工具。由于入门流程仍在完善中，对简化设置流程的贡献尤其受欢迎。
版权声明：本文由华盟网原创发布，保留所有权利。配图由华盟网授权使用。
暂无评论内容