网络安全大模型这个方向我前后折腾了快两年这个系列也写到了第十四篇。后台被问得最多的不是模型结构怎么调不是训练框架怎么配而是“数据到底从哪来”。我一开始觉得奇怪后来想通了环境能现装代码能用开源唯独训练数据这件事没有任何一个开源仓库能直接给你一份“安全领域高质量数据集”只能自己动手攒。这篇就把网络安全大模型的数据获取链路完整捋一遍从数据体系怎么分层、公开数据源有哪些、拿回来怎么清洗到指令样本怎么构造、配比怎么定、后续怎么迭代全部按我实际干过的流程来讲。目标是让准备训练安全告警分析、漏洞情报抽取、渗透测试辅助这类大模型的工程师能拿着这篇文章直接开始攒数据少走我踩过的那些弯路。1. 先想清楚网络安全大模型到底需要哪些数据很多人一上来就问“去哪里下载网络安全数据集”这个提问方式本身就错了。大模型训练不是一个“喂文本”的简单动作不同训练阶段吃的数据形态完全不同把数据混在一起灌进模型结果就是训练完发现模型既不像懂安全也不像会对话。1.1 不把数据分层后面全白干以我训练安全大模型的经验数据至少要分成四层每层的作用和格式都不一样。第一层是预训练语料。这一层让模型学会“安全领域的基本语言”包括漏洞报告的行文方式、威胁情报里的术语体系、代码审计中的常见表述。数据形态就是长文本片段可以从安全博客、漏洞库描述、厂商公告里收集。这一层如果太薄后面做指令微调时模型会经常蹦出通用大模型里常见的“正确废话”因为它根本没见过足够多的安全领域原文。第二层是SFT指令数据也就是“问题-回答”或“指令-输入-输出”这种结构化的样本。这一层让模型学会按你的要求完成任务比如“请判断这个告警是不是误报”“请提取这条漏洞情报中的受影响版本”。数据形态是结构化JSON通常用Alpaca或ShareGPT格式保存。第三层是偏好对齐数据用来做DPO或RLHF。它由一组一组“同一个问题、两个不同答案”的样本组成其中一个答案更符合你的期望。我的经验是安全场景下这一步常常被忽略但效果差异非常大。比如“告警研判”任务模型可能给出两种都能用的回答一种只告诉你“是误报”另一种会告诉你“为什么是误报依据是什么”后者显然更符合安全运营人员的需求。第四层是评测集规模不需要大但必须有。我维护了一个大概100条左右的固定评测集每次训练完先跑它不通过就不用继续往下做。没有评测集后面所有数据迭代都是盲人摸象。我在早期犯过一个典型错误找了一堆CVE描述简单拼接成“问题请解释这个漏洞答案这是……”直接当SFT数据用。结果模型训练完确实能说出来漏洞编号但回答极其空洞没有任何可操作的信息。原因就是我把预训练语料和SFT数据混为一谈了CVE描述只是“素材”不是“答案”。1.2 一个可复用的数据地图想清楚分层之后下一步是画一张数据地图。不同安全细分方向需要的数据源完全不一样我列一个自己用的参考表细分方向典型任务数据形态常见来源漏洞情报信息抽取、威胁问答、补丁分析CVE描述、CNVD公告、补丁diffNVD、CNVD、GitHub Advisory Database告警研判误报判断、告警摘要、事件分级告警日志、事件报告、SOC工单CICIDS、NSL-KDD、内部脱敏日志恶意代码分析家族分类、行为解读、规则生成YARA规则、沙箱报告、分析文章GitHub规则库、公开沙箱报告渗透测试辅助任务拆解、命令解释、工具用法CTF题解、writeup、工具文档CTF平台、安全博客合规与开发OWASP问答、代码审计建议OWASP文档、SRC报告、白皮书OWASP官网、安全厂商资料这张表里最容易出效果的是“内部数据”。如果你所在团队有企业安全运营中心、红队检测报告、历史告警工单这些数据的价值远超任何公开数据集。原因很简单公开数据解决的是“模型懂不懂安全”的问题内部数据解决的是“模型懂不懂你的业务”的问题。比如同一个告警在你们的环境里可能是误报在另一个环境里可能是真实攻击这种场景差异只有内部数据能教给模型。当然用内部数据的前提是合规。所有数据必须先脱敏、过评审再进入训练管道。2. 公开数据源实操清单这些地方能拿到干净数据公开数据源是起步的基础也是大部分人的第一桶金。我带团队做数据获取时常年维护一个数据源清单按类型分好方便随时取数。下面把最核心的几个讲清楚。2.1 漏洞库与情报源CVE/NVD/CNVD怎么抓NVD是美国国家标准与技术研究院维护的漏洞库数据最规整有公开的API 2.0接口支持按时间范围、关键词、CVSS评分过滤。CVE.org自己也提供了CVE Services API两者数据基本一致但字段结构略有不同。我习惯以NVD为主因为字段更丰富包含了CWE编号、CVSS向量、参考链接、影响产品等结构化信息。直接用Python请求NVD API就能拿到数据代码很简单import requests API_KEY your-nvd-api-key BASE https://services.nvd.nist.gov/rest/json/cves/2.0 params { pubStartDate: 2024-01-01T00:00:00.000, pubEndDate: 2024-01-31T23:59:59.999, resultsPerPage: 2000, apiKey: API_KEY } resp requests.get(BASE, paramsparams, timeout60) data resp.json() for item in data.get(vulnerabilities, []): cve item[cve] cve_id cve[id] # 取英文描述过滤掉非英文版本 desc for d in cve.get(descriptions, []): if d.get(lang) en: desc d[value] break cwes [weak[value] for weak in cve.get(weaknesses, [])] print(cve_id, cwes, desc[:120])没有API Key也能调但限流很严重建议申请一个免费Key否则拉全量数据时会被频繁断开。国内数据可以从CNVD获取CNVD的接口没有NVD那么开放我一般是下载它公开的漏洞列表页面解析HTML表格。注意CNVD的编号规则和CVE不同同一条漏洞可能在两个库里的描述、影响面都不一致做数据合并时要以CVE-ID为外键做关联。拿到原始JSON之后最关键的一步是字段展平。NVD的JSON是嵌套结构而大模型训练更希望见到“一段完整文本”。我会把一条CVE记录转换成类似下面这样的结构化文本漏洞编号CVE-2024-XXXXX 受影响产品某Web应用防火墙 3.1.2 漏洞类型命令注入CWE-77 CVSS评分9.8严重 漏洞描述...... 缓解措施升级到3.1.3及以上版本临时禁用相关接口。这样模型读到的不再是一堆嵌套字段而是一段通顺、信息完整的文本后面做SFT时也能直接复用。2.2 知识库与框架源CWE/CAPEC/ATTCK除了漏洞库还有一类“织结构”数据非常值得抓取就是CWE、CAPEC和MITRE ATTCK。这些是安全领域的关系型知识库适合用来教会模型理解漏洞成因、攻击模式和攻击链。CWE是漏洞类型字典可以下载XML格式里面包含了每个弱点的描述、检测方法、缓解措施。CAPEC是攻击模式库描述了攻击者怎么利用某些弱点完成攻击。ATTCK则以矩阵形式整理了攻击者的战术和技术有STIX和JSON两种格式可以在官网直接下载。我拿这些数据主要做两件事。一是预训练语料扩充把CWE描述、ATTCK技术说明当成领域资料喂给模型它很快就学会了“命令注入”“SQL注入”“横向移动”这些概念之间的关联。二是构造SFT的关系抽取样本比如给定一段攻击描述让模型输出用到的ATTCK技术编号。这里有个实操细节ATTCK的STIX格式虽然机读性好但直接当作训练文本会有一堆JSON字段噪音。我一般用官方提供的另一个简化版JSON把每个技术的name、description、procedure_example字段提取出来拼成纯文本再入训练管道。2.3 代码与告警日志源安全规则和流量数据安全大模型有一类重要能力是理解安全规则和检测逻辑比如YARA规则、Snort/Suricata规则、Sigma规则。GitHub上有大量开源规则仓库可以直接去克隆。我重点关注两类一类是规则的元数据和说明另一类是规则本身。YARA规则可以帮助模型学习恶意代码的识别模式Sigma规则和Snort规则则可以帮助模型理解威胁检测的日志特征。拿告警日志类数据时学术界常用的公开数据集有几个NSL-KDD、CICIDS2017、UNSW-NB15等。这些数据集主要用来做入侵检测的分类任务也可以作为SFT数据的基础。比如CICIDS2017里每条流量都有标签正常或某类攻击能把原始特征转成一段自然语言描述例如“源IP与目的IP建立连接后短时间内出现大量小包且目的端口为445判定为端口扫描行为”这种构造出来的样本就能用来训练“告警解释”任务。提醒一句这些学术数据集都有“过时”的问题网络攻击手段更新太快老数据里没有勒索软件、无文件攻击这类新威胁。所以它们只能做基础能力训练真正衡量模型水平还是要靠新数据和内部数据。GitHub上的GitHub Advisory Database也值得关注它是GitHub维护的漏洞通告库有API接口专门记录开源软件依赖中的安全漏洞。这个库的数据质量很高每条都包含漏洞描述、受影响版本、修复版本和参考链接特别适合做“版本咨询”类的问答数据。2.4 学术与竞赛数据集从CTF到大模型评测CTF竞赛数据是训练渗透测试辅助能力的好原料。CTF题目本身包含目标、漏洞类型、解题思路writeup更是天然的高质量问答对。我通常会从开放平台爬取题目描述和writeup把“题目描述提示”作为输入把“解题步骤最终flag获取方法”作为输出。写writeup的人风格差异很大有的写得太简略有的包含大量环境搭建内容。我的做法是先做一轮质量筛选只保留包含“漏洞定位攻击原理修复建议”三要素的writeup其他的先放下宁缺毋滥。学术数据集方面中文领域有一些安全知识图谱和语料集开源比如一些研究组发布的网络安全知识图谱、漏洞情报标注集在GitHub和HuggingFace上可以找到。英文语料相对更多在HuggingFace上搜索cybersecurity、cve、security texts等关键词能找到社区整理好的预训练语料和对话数据集。3. 拿到的数据不能直接用清洗与质量治理很多人最兴奋的时刻是把数据下载下来的那一刻然后直接开始训练。这在安全领域等于自杀。爬下来的数据里充斥着HTML标签、编码混乱、重复样本、敏感信息不洗根本没法用。3.1 网安数据清洗的四个步骤我的清洗管线固定走四步格式展平、编码统一、长短过滤、语言过滤。格式展平是最容易忽略的一步。无论NVD的JSON还是GitHub的API拿到的都是嵌套结构。模型不是不能读JSON但嵌套字段会让模型学到的是“数据结构”而不是“安全知识”尤其在预训练阶段。我用脚本把每一条记录转成“字段名内容”的扁平纯文本格式。编码统一针对的是中文语料。安全报告经常混着各种编码从某些官网直接抓下来的HTML页面还可能带BOM头和乱码。我统一转成UTF-8并做一轮不可见字符清理。长短过滤的核心目标是过滤噪声。太短的文本比如小于30个字通常没有训练价值太长的文档没有截断策略就直接灌进模型会导致注意力分散。我根据不同用途给文本设了上下限预训练语料限制在200到4000字之间超过的部分按段落切分处理。语言过滤不是只保留中文而是把中英文分开建目录。不同语言的语料如果混在一起模型容易学到中英夹杂的坏习惯。3.2 数据去重与去噪MinHash和相似度过滤安全数据源的重叠度非常高。同一个漏洞NVD会收录CNVD会收录安全厂商的公众号也会写一遍直接合并训练会让模型对高频样本产生严重过拟合出现“一问某个特定漏洞就滔滔不绝问别的就哑火”的情况。我用的方案是加近似去重。精确去重用哈希就能做但安全报告这种带改写的内容必须用近似去重。每个文本先做分字或分词然后计算MinHash签名再用LSH做候选集搜索最后对候选对计算Jaccard相似度超过0.8就只保留一条。用datasketch这个Python库几百GB的数据也能在可接受的时间内跑完。去噪则分两层。第一层是内容噪声比如网页里的导航、页脚、广告、评论这些在抓取时就要用正文抽取规则清掉。第二层是语义噪声比如一篇漏洞分析文章里大量重复出现免责声明、作者自我介绍这类内容虽然合法但对训练没有正向贡献比例过高会稀释真正的“安全知识密度”。3.3 敏感信息脱敏这条底线绝对不能碰安全领域的公开数据相对还好但一旦用到企业内部数据脱敏就变成了头等大事。内部告警日志里有真实IP、真实域名、员工账号、内网路径甚至还有明文密码片段这些都不能直接进训练集。我的脱敏规则分几类IP地址用随机IP替换域名用example.com后缀替换邮箱地址用随机用户名加占位域名替换密钥和Token类数据如果无法可靠识别就直接丢弃。对内网路径、主机名这类业务特有信息我会建一个自定义字典做替换保持格式不变但抹掉真实标识。脱敏是一个需要持续维护的工程不能只写一遍正则就完事。我的经验是每接入一种新数据源就先跑一轮样例脱敏肉眼检查替换结果再全量执行。同时建立“脏数据回溯”机制训练完成后如果发现某条输出泄露了疑似真实信息能通过数据版本反向查到源文件及时从后续版本中剔除。3.4 质量打分的快速方案先粗筛再精筛数据量一旦上来逐条人工审核不现实我的做法是“先机器粗筛再人工精筛”。粗筛用几个启发式指标文本长度、特殊字符占比、中英文比例、以及模型困惑度PPL。把这些指标合成一个0到100的质量分经验上能把一半以上的垃圾样本拦在门外。然后按质量分从低到高抽样抽200条人工看一遍发现问题再回来调整规则。4. 从“资料”到“训练样本”指令数据构造清洗完成之后得到的是“素材”还不是“训练样本”。从素材到SFT样本中间隔着最关键的一步指令构造。4.1 定任务类型比定模板更重要刚开始做指令数据时我花了大量时间研究Prompt模板后来发现方向错了。模板只是表面真正决定模型能力上限的是任务类型清单。任务类型定义得越清晰数据的多样性就越有保障。我整理的安全大模型核心任务类型如下任务类型输入输出建议样本量漏洞信息抽取CVE描述或漏洞报告受影响产品、版本、风险等级、缓解措施每条漏洞至少3-5个变体告警研判告警日志或事件描述是否误报、威胁等级、研判依据每个告警类型100条以上攻击链分析多阶段攻击日志ATTCK战术编号、攻击路径说明50个场景起修复建议生成漏洞描述或代码片段升级版本、临时缓解、代码修改建议800条以上日志摘要原始日志片段一段自然语言摘要2000条以上CTF解题题目描述与附件信息解题思路与最终答案按题目类型各500条任务类型清单做完之后再回头设计模板效率会高很多。因为你会清楚地知道某一条素材可以派生成哪些任务。4.2 从漏洞情报自动构造SFT样本一个可直接照抄的流程自动构造SFT样本是扩大数据量的主要手段。以漏洞情报为例我用NVD的JSON做原料每一条漏洞可以派生出多条问答对。比如原始CVE记录经过字段展平后我能自动生成这样一个Alpaca格式的样本{ instruction: 请根据以下漏洞信息回答该漏洞的受影响范围和修复方案。, input: 漏洞编号CVE-2024-12345受影响产品某CMS系统 5.0.1漏洞类型SQL注入漏洞描述由于用户输入过滤不严攻击者可通过特制请求执行任意SQL语句。, output: 该漏洞属于SQL注入类型影响某CMS系统5.0.1及更早版本。攻击者可利用特制请求窃取数据库敏感信息。修复方案升级至5.0.2及以上版本若暂时无法升级建议在Web应用防火墙中配置SQL注入拦截规则并限制数据库账号权限。 }生成这段output时不能凭空让语言模型自己“编”而是要从NVD字段里提取关键信息再套用固定的生成模板。影响版本从configurations字段解析修复方案优先从references里的补丁链接判断CVSS评分决定“严重”还是“高危”的措辞。这种自动构造法能很快造出几万条训练样本但也有副作用。最典型的是样本同质化严重指令问法单一、答案结构雷同模型训练完会变得“很模板化”。我的解决办法是给指令部分注入随机性把“请根据以下漏洞信息回答”换成十几种不同问法比如“这条CVE有什么风险”“如何修复该漏洞”“该漏洞会影响哪些版本”等。答案部分则在不同字段组合之间做排版变换避免模型把“某种固定输出结构”当成唯一标准。4.3 人工标注环节构造高质量交互样本自动构造的样本适合量大、信息明确的任务但像“告警研判依据怎么表述”“复杂攻击链怎么描述”这类需要经验判断的任务自动构造效果有限仍然需要人工标注。我组织标注时用的是“背靠背冲突裁决”的方式。每一条原始工单或告警事件至少两个人独立写答案写完后对比差异太大的第三个人来做裁决。标注规范要提前定死比如答案不超过200字、必须包含“结论-依据-建议”三段式结构、不得臆造证据等。这里有一个我对团队反复强调的点安全数据标注要的是“可解释性”而不是“唯一答案”。告警研判没有标准答案但好的回答一定是有依据的。数据里如果缺乏“因为A特征所以判断是误报”这类推理过程模型学到的就只是表面结论换个场景就不会用了。人工标注的产物一般以ShareGPT对话格式保存保留多轮结构。我早期的数据很多是单轮问答后来发现安全运营场景中用户经常追着问“为什么”“如何复现”所以逐步增加了多轮标注的比例。4.4 用“红队改题”方式做数据增强数据增强不是简单的同义替换。我借鉴红队思维把一组“正常样本”改写成各种刁钻版本提升模型鲁棒性。具体做法有几种。一是加干扰信息本来是一条告警判断样本我在日志里额外加一些无关流量看模型会不会被带偏。二是换场景描述同一个漏洞信息分别包装成“内网渗透测试场景”“护网场景”“等保测评场景”三种输入输出的表述要求相应调整。三是多轮追问用户先问“这是什么攻击”再问“那我该怎么处理”最后问“后续怎么预防”需要模型一步步给出可执行建议。数据增强之后一定要再过一遍质量过滤。我见过不少团队用大模型批量扩写指令数据结果扩完之后样本里大量出现事实性错误安全领域这种错误尤其致命。模型学了一个错误的“修复建议”比不学更糟糕。增强数据必须抽样人工验收确认事实一致性达标之后才能合入训练集。5. 数据配比与持续迭代数据准备得差不多了另一个高频问题浮现出来预训练语料、SFT数据、对齐数据到底按什么比例组合5.1 预训练/微调/对齐的数据配比建议我的经验值是预训练阶段安全领域语料占通用语料的比例控制在5%到10%之间太多会损害模型的通用能力太少则领域知识学不到位。这里说的是领域续训阶段不是从头训练一个完整的基础大模型。没有足够算力做全量预训练的团队直接用Qwen、LLaMA这类开源基座做领域增量预训练时安全语料比例更要保守一点。SFT阶段数据量在2万到20万条之间是比较常见的选择。低于2万模型很容易过拟合到指令模板超过20万收益就开始递减了除非你有大量全新的任务类型。每个具体任务最好不低于500条样本类别边界明显的任务比如告警类型分类可以用更少生成型任务比如报告摘要则需要更多。偏好对齐阶段数据量不需要大我通常准备几千到几万条偏好对就够了。安全场景里做对齐的收益很容易被低估经过偏好对齐的模型回答明显更有条理也更懂得在信息不足时说“需要更多上下文才能判断”而不是强行给结论。一条多年总结出来的建议数据配比不是拍脑袋定的而是靠评测集的反馈慢慢调出来的。先按经验值跑一版再根据错误类型反推是哪种数据缺了再有针对性地补数据。5.2 增量更新与版本管理像管理代码一样管理数据安全领域数据更新太快今天训练完的模型三个月后就可能不知道最新的勒索软件家族。所以数据获取必须是一个持续运行的过程而不是一次性的动作。我为每次数据变更都建立一个manifest文件记录文件名、来源URL、抓取时间、行数、哈希值、清洗版本等元信息。这样任何一个训练结果出了问题都能快速追溯到是哪个版本的数据引入的。增量更新的流程是新数据进来先走一遍清洗和脱敏管道然后和旧数据合并。合并时不能简单追加要做一次增量去重避免新旧数据在同一批训练里重复过多。合并完成后跑一遍固定评测集对比关键指标有没有回退。如果回退就要分析是新数据的分布引入了偏差还是合入比例失控。小团队可以先用Excel或CSV管理manifest数据规模上来之后建议用DVC这类工具把数据版本和训练版本严格绑定起来。5.3 数据质量评估闭环用评测集反推数据问题我固定维护了一份大约100条的评测集覆盖漏洞抽取、告警研判、修复建议、攻击链分析几个核心任务。每次训练完先跑这份评测集重点看两类问题一类是事实错误比如漏洞影响版本答错了这种错误八成是数据标注问题另一类是逻辑混乱比如给了修复建议但没有说明适用条件这种往往是任务定义不够清晰数据里的答案骨架有问题。这里的关键是“评测集本身也要迭代”。随着新攻击手段出现我每季度往评测集里加入一批新样本同时备注每个问题的来源和难度。偶尔发现评测集里老样本已经体现不出模型差异时就降权或替换掉避免模型在评测集上过拟合。6. 实战中遇到的坑与排查速查表最后这部分我把这几年在数据获取阶段踩过的坑整理出来。这些坑大多不在公开文档里写出来帮大家省点时间。6.1 我在数据获取阶段踩过的坑第一个坑是盲目信任公开数据源的字段。NVD的数据看起来规整但实际有很多CVE记录的description为空或者CVSS字段缺失references里也只有一条无关链接。如果直接用原始JSON做训练输入模型会学到“空字段”这种错误模式。我的对策是每条CVE记录在进入训练管道前做字段完整性校验缺失字段要么补默认值要么直接丢弃该条记录。第二个坑是把嵌套JSON直接丢给模型。第一次做漏洞情报数据时我图省事把CVE的JSON字符串直接当作文本喂给了模型。训练完模型确实学会了花括号和逗号的排列但让它回答“CVE-2024-12345影响哪些版本”时它竟然回答得像在解析JSON。从那以后所有数据必须经过“字段展平”这一步确保进入训练管道的是自然语言文本。第三个坑是公开数据集的时效性问题。用NSL-KDD和CICIDS2017训练告警研判基础能力确实有提升但模型对近几年的攻击手法完全没有概念。后来我专门加了一套“新威胁发现”的语料管道每周从威胁情报源拉取新报告做增量更新才算解决这个问题。第四个坑是合规问题。曾经有一版内部红队报告在脱敏完之后仍然可以通过特定关键词反推出某些资产信息幸好上线前被安全评审拦住了。从那以后我把“脱敏验证”这一步固化成了正式环节每次数据集上线前不仅要做规则检查还要做一次“模拟攻击式”的抽查用各种反推方法尝试定位原始信息。6.2 常见问题速查表现象可能原因解决方案训练loss稳定下降但回答内容重复指令多样性不足样本严重同质化增加指令模板随机性做红队改写增强模型把漏洞版本信息答错数据中版本字段缺失或清洗时被截断字段完整性校验修复版本解析逻辑数据里有大量乱码样本编码未统一统一UTF-8清理BOM和非法字符模型只会回答CVE描述原文SFT数据直接用了预训练语料把原始描述转成“指令-输入-输出”结构补充推理过程训练集很大但评测集分数不涨数据重复度过高用MinHash做近似去重合并相似样本模型对新漏洞完全没概念数据更新不及时建立增量更新管道定期合入新漏洞情报中文答案里夹杂英文术语混乱中英文语料混合训练未隔离按语言分桶处理控制语料比例做网络安全大模型这么久我最大的感受是这个方向真正的门槛不在训练环节而是在数据环节。一套跑通的数据获取管道比调几版训练参数值钱得多。也别指望一次性把数据做完美更务实的做法是先用几百条高质量种子数据跑通整个流程验证任务定义和标注规范再逐步扩展到全量数据。数据管道一旦建好后面每一轮训练你都会比上一轮更强。这也是我个人一直坚持的做法先解决“有和没有”再解决“多和少”最后才是“好和更好”。