企业官网建设流程全解析

网络安全大模型这个方向，我前后折腾了快两年，这个系列也写到了第十四篇。后台被问得最多的，不是模型结构怎么调，不是训练框架怎么配，而是“数据到底从哪来”。我一开始觉得奇怪，后来想通了：环境能现装，代码能用开源，唯独训练数据这件事，没有任何一个开源仓库能直接给你一份“安全领域高质量数据集”，只能自己动手攒。

这篇就把网络安全大模型的数据获取链路完整捋一遍：从数据体系怎么分层、公开数据源有哪些、拿回来怎么清洗，到指令样本怎么构造、配比怎么定、后续怎么迭代，全部按我实际干过的流程来讲。目标是让准备训练安全告警分析、漏洞情报抽取、渗透测试辅助这类大模型的工程师，能拿着这篇文章直接开始攒数据，少走我踩过的那些弯路。

1. 先想清楚：网络安全大模型到底需要哪些数据

很多人一上来就问“去哪里下载网络安全数据集”，这个提问方式本身就错了。大模型训练不是一个“喂文本”的简单动作，不同训练阶段吃的数据形态完全不同，把数据混在一起灌进模型，结果就是训练完发现模型既不像懂安全，也不像会对话。

1.1 不把数据分层，后面全白干

以我训练安全大模型的经验，数据至少要分成四层，每层的作用和格式都不一样。

第一层是预训练语料。这一层让模型学会“安全领域的基本语言”，包括漏洞报告的行文方式、威胁情报里的术语体系、代码审计中的常见表述。数据形态就是长文本片段，可以从安全博客、漏洞库描述、厂商公告里收集。这一层如果太薄，后面做指令微调时模型会经常蹦出通用大模型里常见的“正确废话”，因为它根本没见过足够多的安全领域原文。

第二层是SFT指令数据，也就是“问题-回答”或“指令-输入-输出”这种结构化的样本。这一层让模型学会按你的要求完成任务，比如“请判断这个告警是不是误报”“请提取这条漏洞情报中的受影响版本”。数据形态是结构化JSON，通常用Alpaca或ShareGPT格式保存。

第三层是偏好对齐数据，用来做DPO或RLHF。它由一组一组“同一个问题、两个不同答案”的样本组成，其中一个答案更符合你的期望。我的经验是，安全场景下这一步常常被忽略，但效果差异非常大。比如“告警研判”任务，模型可能给出两种都能用的回答，一种只告诉你“是误报”，另一种会告诉你“为什么是误报，依据是什么”，后者显然更符合安全运营人员的需求。

第四层是评测集，规模不需要大，但必须有。我维护了一个大概100条左右的固定评测集，每次训练完先跑它，不通过就不用继续往下做。没有评测集，后面所有数据迭代都是盲人摸象。

我在早期犯过一个典型错误：找了一堆CVE描述，简单拼接成“问题：请解释这个漏洞，答案：这是……”，直接当SFT数据用。结果模型训练完确实能说出来漏洞编号，但回答极其空洞，没有任何可操作的信息。原因就是我把预训练语料和SFT数据混为一谈了，CVE描述只是“素材”，不是“答案”。

1.2 一个可复用的数据地图

想清楚分层之后，下一步是画一张数据地图。不同安全细分方向需要的数据源完全不一样，我列一个自己用的参考表：

这张表里最容易出效果的是“内部数据”。如果你所在团队有企业安全运营中心、红队检测报告、历史告警工单，这些数据的价值远超任何公开数据集。原因很简单，公开数据解决的是“模型懂不懂安全”的问题，内部数据解决的是“模型懂不懂你的业务”的问题。比如同一个告警，在你们的环境里可能是误报，在另一个环境里可能是真实攻击，这种场景差异只有内部数据能教给模型。

当然，用内部数据的前提是合规。所有数据必须先脱敏、过评审，再进入训练管道。

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, params=params, timeout=60) 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/ATT&CK

除了漏洞库，还有一类“织结构”数据非常值得抓取，就是CWE、CAPEC和MITRE ATT&CK。这些是安全领域的关系型知识库，适合用来教会模型理解漏洞成因、攻击模式和攻击链。

CWE是漏洞类型字典，可以下载XML格式，里面包含了每个弱点的描述、检测方法、缓解措施。CAPEC是攻击模式库，描述了攻击者怎么利用某些弱点完成攻击。ATT&CK则以矩阵形式整理了攻击者的战术和技术，有STIX和JSON两种格式可以在官网直接下载。

我拿这些数据主要做两件事。一是预训练语料扩充，把CWE描述、ATT&CK技术说明当成领域资料喂给模型，它很快就学会了“命令注入”“SQL注入”“横向移动”这些概念之间的关联。二是构造SFT的关系抽取样本，比如给定一段攻击描述，让模型输出用到的ATT&CK技术编号。

这里有个实操细节：ATT&CK的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模板，后来发现方向错了。模板只是表面，真正决定模型能力上限的是任务类型清单。任务类型定义得越清晰，数据的多样性就越有保障。

我整理的安全大模型核心任务类型如下：

任务类型清单做完之后，再回头设计模板，效率会高很多。因为你会清楚地知道，某一条素材可以派生成哪些任务。

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 常见问题速查表

做网络安全大模型这么久，我最大的感受是：这个方向真正的门槛不在训练环节，而是在数据环节。一套跑通的数据获取管道，比调几版训练参数值钱得多。也别指望一次性把数据做完美，更务实的做法是先用几百条高质量种子数据跑通整个流程，验证任务定义和标注规范，再逐步扩展到全量数据。数据管道一旦建好，后面每一轮训练，你都会比上一轮更强。这也是我个人一直坚持的做法：先解决“有和没有”，再解决“多和少”，最后才是“好和更好”。