CyberFactory：把互联网上的漏洞碎片，炼成能打CTF的开源模型

2026年7月，OpenAI在自己的安全博客上发了一篇文章，标题挺扎眼：和Hugging Face合作处理一次安全事故，起因是模型评估过程中出了漏洞。你可能觉得这种新闻见怪不怪了，但仔细想想会发现一件挺矛盾的事：我们一边在担心AI模型会不会被拿去攻击系统，一边却发现，能真正帮我们防御这些攻击的开源模型，几乎不存在。

这不是危言耸听。闭源模型比如Mythos确实在网络安全任务上表现不错，但它们是黑箱，你没法知道它们是怎么训练出这种能力的，也没法复现。开源阵营呢？GLM、Kimi这些前沿的开放权重模型虽然也展示了不错的安全能力，但同样不告诉你训练方法。剩下的开源方案，大多是针对某个孤立任务做的，比如专门搞CTF（夺旗赛，一种网络安全竞赛形式，参赛者通过攻防技巧获取隐藏的"旗帜"字符串来得分）的，或者专门做漏洞检测的，彼此不成体系。

这篇论文要解决的，就是这个"有能力，没配方"的问题。研究团队做了一套叫CyberFactory的开源框架，试图把从数据构造、轨迹合成到模型训练这一整条链路都打通，并且用这套流程训练出了一个具体的模型，叫OpenAegis（名字来自希腊神话里宙斯和雅典娜的护盾，寓意防御性用途）。

漏洞不会自己讲故事，得靠人喂

要理解CyberFactory在解决什么问题，得先明白一件事：现实世界里的漏洞数据其实是一堆散乱的碎片。

一个CVE(Common Vulnerabilities and Exposures，通用漏洞披露编号，是安全社区给每个已知软件漏洞分配的唯一标识)条目里，你能拿到的往往只是一段模糊的描述、一个受影响的版本范围，可能还带个CWE类型(Common Weakness Enumeration，通用缺陷枚举，是对软件缺陷类型的标准化分类体系，比如"缓冲区溢出"就是一种CWE类型)。但这些信息离"训练一个能自己发现并修复漏洞的AI模型"还差得远：你需要知道具体是哪一次代码提交引入了漏洞、哪一次提交修复了它、用什么样的输入能触发它、触发之后系统表现出什么异常。这些东西CVE报告里通常不会写。

这就好比你收到一张寻人启事，上面只写着"某人在某个时间段的某个城市走丢了"，却没有照片、没有具体地址、没有体貌特征。你想去找这个人，光靠这张启事是不够的，你得自己去查监控、走访邻居、比对户籍资料，把这条线索一点点还原成一个可以按图索骥的完整档案。如果没人做这个还原工作，再多的寻人启事堆在那里也只是一堆废纸，没法真正用来找人。CyberFactory做的就是这个"还原档案"的工作，只不过对象换成了漏洞。

具体来说，团队用了三类原始素材。第一类是ARVO(Atlas of Reproducible Vulnerabilities for Open Source Software，一个收录了六千多个可复现的开源软件漏洞的图谱数据库)，这类素材质量最好，因为它自带修复前后两个版本的Docker镜像和验证用的PoC(Proof-of-Concept，概念验证，这里特指一段能够触发目标漏洞的具体输入或代码)，直接拿来用就行。第二类是OSS-Fuzz(Google维护的一个开源模糊测试平台，专门对开源项目做自动化漏洞挖掘)里的漏洞，这类素材通常只给出了引入漏洞的提交记录，团队得用二分查找的方法去定位对应的修复提交在哪。第三类，也是最难啃的一类，就是直接从CVE数据库里挖出来的"野生"漏洞，这类素材最原始，只有版本范围和类型标签，团队得自己去定位修复提交、构建可执行环境、验证漏洞是否真实存在。

难度依次递增，工作量也依次递增，这也是为什么论文标题里特意强调"来自荒野的实例"，因为这批最难处理的CVE恰恰是覆盖面最广、最贴近真实世界的部分。

先做减法，再做加法：只留下模型解不出来的题

拿到这些漏洞素材之后，团队没有把所有实例一股脑塞给模型训练，而是先做了一轮筛选，剔除那些"模型闭着眼睛都能做对"的简单题。

具体做法是，先让推理模型去尝试直接生成PoC，如果模型能轻松解出来，这道题就被扔掉，只留下那些模型解不出来、但确实存在解法的实例。这一步在论文里被称为"实例校验"。

这个逻辑其实很像出考卷。如果你是老师，出了一套卷子，结果发现全班都能考满分，这套卷子对区分学生水平就没什么意义，你会把那些送分题换掉，换成学生真正需要动脑筋、且经过努力确实能做对的题目。CyberFactory做的正是这件事：它要保证每一道被留下的题目都"有挑战性但可解决"，太简单的题目训练不出真本事，而无解的题目会让模型学到错误的挫败感，两头都不能要。

筛选完实例之后，还得给每道题配上"题干"，也就是漏洞描述。这里团队的策略是能省则省：如果原始的修复提交信息（commit message）写得足够清楚，就直接拿来当描述用；如果写得潦草或者信息不全，才会调用LLM结合漏洞证据重新生成一段清晰的描述。这算是一种务实的取巧，毕竟没必要事事都靠AI重写，能用现成的高质量素材就不浪费。

老师带着学生做题，比学生自己瞎撞的效率高得多

光有题目还不够，CyberFactory真正的核心创新，在于它怎么让一个"教师模型"去解题、并把解题过程录下来给"学生模型"学。

这里出现了一个很关键的设计，叫做漏洞分析技能(vulnerability-analysis skill，一套可复用的、与具体任务无关的标准工作流程，指导模型如何检查目标代码、结合领域先验知识来解决问题、并基于执行证据做验证)。

这个技能不是针对某一道具体题目的解法，而是一套通用的做题方法论：先去检查目标程序和它的构建约束条件，再用合适的分析和测试手段去探索可能触发漏洞的输入，验证拿到的证据是否站得住脚，如果验证失败就调整思路重新来。这套流程有点像给一个新手侦探配了一本"办案手册"，手册不会直接告诉你"凶手是谁"，但会规定你必须按顺序做勘查现场、收集证据、交叉验证这几个步骤，不能想到哪查到哪。

为什么这么设计很重要，看一组对比数据就明白了。团队把这个技能应用到GLM 5.2这个教师模型身上做了个对照实验：不给技能的时候，模型每道题给一个小时的时间去做一次，Pass@1（一次尝试就做对的比例）是43.3%；给了技能之后，每道题只给15分钟，但让模型独立尝试5次，Pass@1反而涨到了46.5%。

这个结果乍看有点反直觉：时间预算从60分钟砍到了15分钟，四分之一都不到，结果却做得更好了。这说明有技能指导的模型不是靠"多耗时间硬撑"提高成功率的，而是每一次尝试的效率本身就高了很多，团队进一步的行为分析也证实了这一点：给了技能之后，模型的"探索覆盖率"（有没有用到领域引导的探索方法）从3.78%飙升到99.85%，"验证覆盖率"（有没有做基于证据的验证）从0.13%涨到98.41%。

翻译成人话就是：没有技能指导的模型，绝大多数时候是在瞎撞，撞上了就撞上了，撞不上就直接提交草率的答案；有了技能指导之后，模型几乎每一次都会按部就班地先探索、再验证，做题的纪律性完全不一样了。

如果没有这套技能会怎样？团队也观察到了一个值得警惕的副作用：注入了技能的GLM 5.2会对这份"先验知识"产生一定程度的依赖，这提示我们，给模型一份操作手册虽然能提高解题效率，但也可能让它在手册之外变得不那么灵活。这算是这个设计里一个诚实的但书，团队并没有回避这一点。

教师做完题，学生不需要抄手册也能学会解题套路

有了这批由"技能引导"生成的高质量解题轨迹之后，下一步就是训练学生模型OpenAegis。

这里有个挺关键的设计选择：OpenAegis在推理阶段并不会拿到那份漏洞分析技能手册，它完全是靠监督微调(Supervised Fine-Tuning，SFT，一种用人工标注或筛选过的高质量样本去调整模型参数的训练方式)，把老师解题时展现出来的那套工作流程，内化成了自己参数里的东西。

这就好比一个学徒跟着老师傅学修车，老师傅手把手带着他检查发动机、听异响、拆零件、装回去、再试车，学徒看了足够多遍这样的完整流程之后，哪怕没有老师傅在旁边递手册，他自己上手修车时也会不自觉地按照同样的步骤来做，先听声音再拆零件，而不是直接抡起扳手瞎拆一通。如果这个学徒从没跟老师傅系统学过，只是自己瞎摸索了几次，遇到没见过的故障时大概率会乱来，成功率也没法保证。

论文里做了个很直接的验证，对比了Qwen3.5（也就是OpenAegis的基座模型，没有经过CyberFactory训练）和OpenAegis在解题时的行为模式。结果显示，OpenAegis的探索调用频率从每条轨迹0.01次涨到了1.32次，验证调用频率从0.00涨到了1.05次，几乎复刻了教师模型被注入技能之后的行为变化方向，尽管OpenAegis从头到尾都没见过那份技能手册。这个对应关系恰恰证明了监督微调确实把"怎么做题"这件事学进去了，而不只是记住了"这道题的答案是什么"。

除了做题的思路变了，OpenAegis连使用工具的习惯都变了。经过训练后，它做常规代码检查时，用read指令直接读文件的比例从28.4%降到了7.3%，转而更多用shell指令（从70.1%涨到89.9%），单次操作的调用比例从314%降到13.5%，一次性打包6到10个操作的调用比例则从4.3%涨到30.8%。这说明模型学会了把零散的检查动作打包成更完整的一次性操作，而不是每查一步就停下来问一句"下一步该干嘛"。

这些变化听起来琐碎，但放在实际场景里意义不小。想象你在装修房子，找一个只会一件件搬砖的工人，和找一个会提前规划好一整面墙需要多少砖、一次性搬齐的工人，效率差距是巨大的。前者每搬一块砖都要往返一次仓库，后者一次性把材料备齐再开工，中间浪费的时间和体力完全不是一个量级。

超长任务会把上下文撑爆，得学会"断舍离"

前面聊的都是"怎么做对题"，还有一个技术细节值得单独说说，就是模型在做真实漏洞复现任务时，经常会遇到上下文爆掉的问题。

CyberGym(本论文用来评测的基准测试平台，要求AI agent仅凭一段自然语言描述和对应代码库，就去复现一个真实存在的软件漏洞)这个评测环境里，很多任务需要反复检查代码、编译、运行、验证，一来二去整个对话历史很容易逼近256K token的上限（token是语言模型处理文本的最小单位，可以粗略理解为词或字的片段）。

团队的做法是设置了一个压缩触发阈值：当上下文占用达到90%的时候，就把已经积累的所有对话历史压缩成一个"续接状态"，只保留已验证的证据、失败过的尝试、还没验证的猜想、生成过的文件、构建状态和待办事项，把冗余的日志和重复的搜索结果都扔掉。压缩完之后，模型带着这个精简版的记忆继续往下做，任务、工具、验证方式全都不变，变的只是记忆的呈现方式。

这跟你收拾一个塞满东西的行李箱有点像。如果你把所有穿过的衣服、用过的票据、买的纪念品全都原样塞回箱子，箱子迟早会因为塞不下而合不上盖，你要么被迫扔掉重要的东西（比如把还没看完的地图硬塞进去导致箱子爆开），要么干脆放弃继续装东西。聪明的做法是定期把已经用不上的东西（脏衣服可以先揉成一团、票据可以先拍照存档丢掉纸质版）清理掉，只留下接下来的行程真正需要的东西，这样箱子才能一直装得下、不至于半路散架。

团队还专门做了阈值的消融实验，测试了80%、90%、95%三个触发点。结果显示90%是最优的：触发太早（80%）压缩次数太频繁，反而干扰了正常的解题节奏；触发太晚（95%）会导致压缩请求本身和后续的工具调用没有足够的空间展开。用了90%这个阈值之后，整体Pass@1达到58.1%，需要40次以上工具交互的长程任务上，Pass@1比对照组高出8.5个百分点，因为上下文耗尽而失败的比例也下降了11.7个百分点。相比之下，如果什么都不压缩，直接让完整历史一直堆到底，整体Pass@1只有52.1%；如果用最简单粗暴的截断方式（直接砍掉早期记录），效果反而更差，只有45.6%，因为简单截断可能一不小心就把关键证据也砍掉了。

最终成绩单：58.1%意味着什么

说了这么多设计思路，最终落地效果到底怎么样？

在CyberGym这个一小时任务预算的评测里，OpenAegis拿到了58.1%的Pass@1成绩，相比它的基座模型Qwen 3.5的29.6%，直接翻了近一倍，绝对提升28.5个百分点。这个提升幅度是整篇论文里最大的一组对比数据，意味着同样一个397B参数规模的模型，光是经过CyberFactory这套流程的训练，解题能力就能翻番。

更让人意外的是，OpenAegis还打赢了参数规模远大于它的两个通用型模型：GLM 5.2（744B总参数）和Kimi K2.7（1T总参数）。GLM 5.2的Pass@1是43.3%，Kimi K2.7是51.7%，OpenAegis分别领先它们14.8和6.4个百分点，而且用的还是同样的评测脚手架、同样的工具接口、同样的一小时预算，没有任何"作弊"式的额外优势。

这说明了一件事：在网络安全这种高度专业化的任务上，参数规模不是万能的，针对性的训练数据和训练流程可能比单纯堆大模型更有效。这也呼应了论文开篇提出的那个问题：与其等着更大的模型自然而然地学会安全技能，不如直接设计一套流程把这种能力"炼"出来。

下面这张表是核心结果的汇总：

| 模型 | 参数规模 | Pass@1 |

| Qwen 3.5 | 397B-A17B | 29.6% |

| Kimi K2.7 | 1T-A32B | 51.7% |

| GLM 5.2 | 744B-A40B | 43.3% |

| OpenAegis | 397B-A17B | **58.1%** |

除了PoC生成任务，CyberFactory的训练数据还覆盖了另外两类任务：漏洞修复（patch generation，让模型学会在保证功能不变的前提下修补安全漏洞）和网络安全问答（CyberQA）。针对问答数据，团队采取了一种叫"答案优先"的策略：先确定一个可信来源给出的标准答案，比如崩溃发生的具体位置、代码里哪个函数被改动过、权威报告里直接写明的结论，再让LLM把这些信息包装成问题和答案的形式，而不是让LLM自己凭空编答案。生成完之后还要过一道LLM裁判的关卡，检查答案是否能追溯回原始来源、问题里有没有意外泄露答案、一个问题是否只对应一个确定的答案，不合格的样本要么重新生成一次，要么直接丢弃。这套流程保证了问答数据的可信度建立在原始证据之上，而不是模型自己的臆测。

写在后面

读完这篇论文，最触动我的其实不是那个58.1%的成绩，而是团队做的一个"减法"实验：把技能手册塞给GLM 5.2之后，团队诚实地记录了一个副作用，模型会对这份先验知识产生依赖。这个细节很容易被忽略，但它其实揭示了一个更普遍的问题：任何一套"标准操作流程"，无论设计得多精巧，一旦给了模型，都有可能变成一种拐杖，让模型在没有拐杖的场景里反而站不稳。团队没有回避这个问题，也没有把它藏起来，这种诚实感在论文里其实不算常见。

还有一点值得单独拿出来聊聊：整个筛选实例的逻辑，本质上是在做"难度校准"，先让候选模型试做一遍，把它能轻松解决的题目直接踢出训练集。这个做法背后其实藏着一个更深的问题，你用来筛选难度的那个"候选模型"本身的能力边界，会不会反过来定义了整个数据集的难度分布？如果筛选用的模型本身能力有限，那些它做不出来、但换一个更强模型分分钟能解的题目，会不会被误判成"有价值的难题"留下来？论文没有细谈这个潜在的循环依赖，但这确实是个值得继续追问的地方。

论文末尾也坦诚地写了几处局限：目前的评测受限于现有CVE素材的覆盖范围和固定的一小时预算，某些目标其实更适合人工构造输入，而不是模糊测试优先的策略；漏洞修复和CyberQA两个任务还没有做同等严格程度的评测；未来还需要把语言和项目覆盖面进一步拓宽。这些留白算是给整个方向留了不少可以继续挖的坑。

Q&A

Q1：CyberFactory是什么？

A：CyberFactory是一套开源的网络安全模型训练框架，把互联网上真实存在的CVE漏洞、ARVO和OSS-Fuzz里的漏洞素材转化成可执行、可验证的训练任务，涵盖漏洞复现、补丁生成和安全问答三类任务。

Q2：OpenAegis模型表现怎么样？

A：在CyberGym评测中，OpenAegis一小时预算下拿到58.1%的Pass@1成绩，比基座模型Qwen 3.5提升28.5个百分点，还超过了参数规模更大的GLM 5.2和Kimi K2.7。

Q3：OpenAegis推理时需要那个漏洞分析技能手册吗？

A：不需要。这份技能手册只在生成训练数据阶段用来指导教师模型解题，OpenAegis通过监督微调把这套解题流程内化到了自己的参数里，推理时不依赖手册也能复现同样的工作方式。