网络安全大模型和普通大模型最大的区别，不在模型结构，也不在训练框架，而在数据。普通模型要的是语言通顺、知识广博，网络安全模型要的是“在正确的时候给出正确的攻击或防御动作”。差之毫厘，谬以千里。所以这个系列写到第十四篇，专门拿出一整篇来聊数据获取，我觉得是非常有必要的——数据这一关过不了，后面做对齐、做微调、做评测，全部是空中楼阁。
这篇内容我会按照我实际做项目时的思路来讲：先厘清网络安全大模型到底需要哪些数据，再逐一拆解可以从哪里拿、怎么拿、拿到之后怎么清洗和标注，最后聊一聊这个过程中我踩过的一些坑。整个过程里涉及的工具和平台，大部分都是公开的，你自己就能上手去试。
1. 先搞清楚：网络安全大模型到底需要什么数据
很多人一上来就急着到处爬数据，结果爬到的东西七零八落，喂进模型里跑了一轮，效果惨不忍睹。我个人的习惯是，动手之前先把“数据需求画像”画出来，也就是想清楚：我要训练的模型，将来在什么场景下用，输入是什么，输出是什么，需要具备哪些能力。
1.1 从能力反推数据需求
网络安全大模型通常需要具备以下几类核心能力，每类能力对应的数据来源和格式差异非常大：漏洞检测与利用、恶意流量识别、日志分析与告警研判、攻击溯源、代码审计、安全知识问答、合规与应急响应建议。不同的任务有不同的输入输出格式要求，比如漏洞检测需要以代码或请求包为输入，输出是漏洞类型和位置；而知识问答需要的是结构化的安全知识对。
如果这些能力混在一起，用一份“万能语料”去训练，效果会非常差。实际项目里我往往会按任务类型把数据强行拆分成多个子集，每个子集单独清洗、单独标注，在后续训练阶段再决定是混合采样还是分阶段训练。
1.2 数据量的“够用”标准
很多入门者都喜欢问：到底要多少数据才算够？这个问题没有标准答案，但是有一个经验值可以参考——对于微调场景（基于开源基座模型做SFT），一个任务方向如果能有2万条以上高质量的“指令-回答”对，基本就能看到一个比较明显的能力涌现；如果少于5000条，效果往往和随机噪声差不多。如果是从零预训练，那数据量就不是这个量级了，至少几十亿token打底，这种情况对个人开发者几乎不现实，所以本篇默认站在“微调开源模型”这个语境下讨论。
另外要说清楚：质量远比数量重要。我在实验里发现，3000条精心筛选、格式统一的漏洞分析数据，训练出来的模型在漏洞类型识别上的准确率，比用3万条从网上随手抓来的乱七八糟数据训出来的模型高出接近20个百分点。原因很简单，大模型对数据中的“噪声模式”非常敏感，垃圾进，垃圾出，这句话在网络安全领域体现得尤其明显。
2. 数据来源全景：公开数据集、安全社区与自建语料
网络安全领域有个好现象，就是行业内公开的数据集和知识库非常多，只是分布得很散，需要自己花时间去找、去整理。我按照来源把它们分成三大类，每一类拿到的数据在后续训练中的角色完全不同。
2.1 公开数据集：质量最稳的第一桶金
公开数据集是首选的启动数据，因为它们已经经过了一定程度的整理和验证，格式相对规范，拿过来做初步清洗就能用。我常用的几类包括：
- 漏洞描述与CVE数据：NVD、CVE Details、GitHub Advisory Database，这些地方能拿到结构化非常好的漏洞信息，包括漏洞编号、影响组件、危害等级、CVSS评分、漏洞描述和参考链接。这部分数据最适合用来训练模型对漏洞的基础认知。
- 安全公告与补丁信息：各大厂商的安全公告页面、Red Hat Security Advisories、Ubuntu CVE Tracker，这些数据时效性强，能帮助模型了解最新的漏洞态势。但这类数据噪声多，需要重点处理时间信息。
- 恶意样本与流量数据：MalwareBazaar、VirusShare、Stratosphere Lab的流量数据集、CICIDS系列数据集，这些偏二进制和流量抓包，适合做基于流量或样本分析的模型训练，但和纯文本大模型之间的格式转换成本比较高。
- CTF题目与WriteUp：GitHub上有大量CTF比赛存档（比如CTFd导出的题目、各大比赛的公开WriteUp仓库），这些是训练漏洞利用思路和解题逻辑的好材料，缺点是文本质量参差不齐，需要大量手工筛选。
在使用这些公开数据集的时候，有一个原则：不要贪多，要带着“这个数据对应模型哪个能力”的问题去筛选。比如我想让模型学会“从代码里找SQL注入”，那么我需要的核心数据就是包含漏洞代码片段和对应修复代码的pair，而不是一个笼统的漏洞描述文本。
2.2 安全社区与知识库：高质量语料的富矿
如果说公开数据集是骨架，那么安全社区的知识沉淀就是血肉。这些内容往往由一线安全研究员撰写，包含大量实战细节和判断逻辑，非常适合用来培养模型在真实场景下的“手感”。
我个人最常抓取的内容源有以下几类：
- 技术博客与深度分析文章：FreeBuf、先知社区、看雪论坛、安全客、Seebug Paper等，里面大量漏洞分析文章、红队攻击手法梳理、应急响应复盘。这些文章的特点是上下文完整、逻辑链条清晰，非常适合做“长文本理解类”训练数据。
- 安全工具使用文档与手册：Burp Suite官方文档、Metasploit官方文档、Nmap手册、sqlmap的Wiki、YARA规则编写指南。工具文档相对枯燥，但术语准确，指令性明确，对模型理解“具体操作步骤”很有帮助。
- OWASP类知识框架：OWASP Top 10、OWASP ASVS、OWASP Testing Guide，这些可以作为结构化知识框架的数据源，用来给模型建立安全知识的坐标体系。这类数据在安全问答场景中效果非常好。
采集方式上，可以用爬虫去抓，也可以去GitHub找别人已经爬好的镜像仓库。我自己的习惯是优先找现成的，因为自建爬虫的维护成本远高于大部分人的预期——目标网站改版、反爬策略调整、编码问题，哪一个都能折腾一整天。市面上很多开源爬虫脚本本身也是学习爬虫的好案例，直接改改比从头写省事得多。
2.3 自建语料：绕不开但价值最高的部分
仅仅靠公开数据和社区内容来训练网络安全大模型，最后得到的模型大概率只是一个“安全知识问答机器人”，而不是真正能动手解决问题的“安全助手”。要让模型具备实战能力，必须投入人力构建自建语料，这部分的产出才是模型的核心竞争力。
我常用的自建语料生成方法有几种：
- 基于渗透测试报告的改写：把真实的渗透测试报告脱敏后，改写成“输入一个靶标范围，输出测试思路和发现的问题”这种问答格式。这种数据对培养实战思维非常有用，但因为涉及脱敏和改写，成本最高。
- 用规则引擎自动生成带标签数据：比如写一套正则/Parser规则，从已有的漏洞数据库中自动生成“请求包-漏洞类型-修复建议”的样本，或者用GDB/objdump配合脚本从二进制中提取漏洞特征。这种方式效率高，但需要较强的工程能力。
- 模拟环境自动采集：自己在本地搭一套靶场（DVWA、vulhub、Sqli-labs等），通过自动化脚本模拟扫描和攻击，把流量和日志采集下来，作为训练“告警研判”能力的数据。这里有个重点：靶场环境相对简单，数据多样性有限，后期需要结合真实业务环境的脱敏数据一起用。
自建语料是一件费时费力的事情，但从我自己的实验结果来看，它带来的模型能力提升是其他任何数据来源都无法替代的。尤其是模型对任务指令的遵循能力，几乎完全取决于自建语料中“指令-预期输出”对的质量和数量。
3. 实操：搭建一个最小可用的数据采集流水线
这一节我会把前面提到的数据来源落到具体的操作层面。以“从公开渠道自动采集漏洞信息”这个最常见的场景为例，从环境搭建到采集入库，完整走一遍。这套流程我在自己的项目中跑过很多次，整体比较稳定，你可以直接照着搭。
3.1 环境准备
我用的主力语言是Python 3.10+，核心依赖库就几个：requests、BeautifulSoup4、pandas、SQLAlchemy，再加一个tqdm做进度展示。数据库方面我习惯先用SQLite做原型验证，等数据量上来之后再迁到PostgreSQL。
安装依赖非常简单：
pip install requests beautifulsoup4 pandas sqlalchemy tqdm另外强烈建议准备一个代理池，因为很多安全类网站对高频访问的IP封禁非常果断，我试过用一个固定IP去抓某知名漏洞库，抓了不到八百条就被限流了，后来换成轮换代理才好一些。
3.2 以NVD CVE数据为例的采集实现
NVD（National Vulnerability Database）提供了官方的REST API，这比直接爬HTML页面要稳定得多。API接口地址是：
https://services.nvd.nist.gov/rest/json/cves/2.0这个接口支持分页和关键词过滤，单次最多能拉取2000条记录，对于大多数场景完全够用。下面这段代码演示了如何拉取指定时间窗口内的CVE数据，并将其入库到SQLite：
import requests import sqlite3 import time from datetime import datetime, timedelta API_URL = "https://services.nvd.nist.gov/rest/json/cves/2.0" def fetch_cves(start_date, end_date): """拉取指定日期范围内的CVE漏洞信息""" all_results = [] start_index = 0 while True: params = { "pubStartDate": start_date, "pubEndDate": end_date, "startIndex": start_index, } resp = requests.get(API_URL, params=params, timeout=30) if resp.status_code != 200: print(f"请求失败，状态码: {resp.status_code}，等待30秒重试") time.sleep(30) continue data = resp.json() results = data.get("vulnerabilities", []) all_results.extend(results) total_results = data.get("totalResults", 0) print(f"已拉取 {len(all_results)} / {total_results} 条") if start_index + len(results) >= total_results: break start_index += len(results) # NVD API 限流，建议请求间隔不低于6秒 time.sleep(6) return all_results def save_to_db(cve_list, db_path="cve_data.db"): """将CVE数据存入SQLite""" conn = sqlite3.connect(db_path) c = conn.cursor() c.execute(""" CREATE TABLE IF NOT EXISTS cves ( id TEXT PRIMARY KEY, published_date TEXT, description TEXT, cvss_score REAL, severity TEXT ) """) for item in cve_list: cve = item.get("cve", {}) cve_id = cve.get("id", "") published = cve.get("published", "") desc_data = cve.get("descriptions", []) description = "" for desc in desc_data: if desc.get("lang") == "en": description = desc.get("value", "") break metrics = cve.get("metrics", {}) cvss_score = None severity = None if "cvssMetricV31" in metrics: cvss_data = metrics["cvssMetricV31"][0].get("cvssData", {}) cvss_score = cvss_data.get("baseScore") severity = cvss_data.get("baseSeverity") c.execute( "INSERT OR REPLACE INTO cves (id, published_date, description, cvss_score, severity) VALUES (?,?,?,?,?)", (cve_id, published, description, cvss_score, severity) ) conn.commit() conn.close() if __name__ == "__main__": end = datetime.now() start = end - timedelta(days=30) cves = fetch_cves( start.strftime("%Y-%m-%dT%H:%M:%S.000"), end.strftime("%Y-%m-%dT%H:%M:%S.000") ) save_to_db(cves) print(f"共入库 {len(cves)} 条CVE记录")这段代码里有两个比较重要的细节。一个是NVD API有严格的速率限制，参考官方文档是每30秒最多5个请求，所以我把请求间隔设成了6秒，宁可慢一点，也不要触发封禁。另一个是入库时用了INSERT OR REPLACE，这样重复运行采集脚本不会产生重复数据。
3.3 社区文章采集：尊重规则，控制频率
社区文章类的数据采集，本质上就是对目标站点做定制的爬取。这里有一个非常关键的合规提示：在抓取任何网站之前，先看对方的robots.txt，并严格遵守网站的条款。很多安全社区的规则非常严格，有些甚至明确禁止未经授权的爬虫。所以，抓取前先做一个简单的合规自查：
- 是否用于商业用途？如果是，需要获得授权。
- 目标站点是否明确禁止爬虫？如果是，就不要去碰。
- 抓取是否会影响到网站正常服务？如果会，就该降低频率或者换一种获取方式。
对于允许抓取的站点，我的建议是将抓取频率控制在每秒不超过一个请求，并且最好在非高峰时段运行。爬虫本身实现不复杂，核心就是找到文章列表页的分页规律和详情页的正文提取规则。这里给一个通用思路的伪代码：
import requests from bs4 import BeautifulSoup def crawl_article_list(list_url): resp = requests.get(list_url, headers={"User-Agent": "Mozilla/5.0"}) soup = BeautifulSoup(resp.text, "html.parser") # 这一步需要根据目标站点的DOM结构调整 for link in soup.select(".article-title a"): title = link.text.strip() url = link.get("href") content = crawl_article_detail(url) save_article(title, url, content) def crawl_article_detail(detail_url): resp = requests.get(detail_url, headers={"User-Agent": "Mozilla/5.0"}) soup = BeautifulSoup(resp.text, "html.parser") # 正文通常都在某个特定的容器中，需要按站点适配 content = soup.select_one(".article-content") return content.text if content else ""社区采集最大的问题在于网站的DOM结构经常变，今天能跑通的代码，下周可能就失效了。所以建议从一开始就把选择器和URL规则写成配置文件，不要硬编码在代码里，这样维护起来会轻松很多。
3.4 把非结构化文本变成训练语料
拿到原始数据之后，还不能直接拿去训练，因为这时的数据格式是“文章标题+正文”，而大模型微调需要的是“指令-回答”的问答格式。转换这一步是整个数据流水线里最需要花心思的地方。
对于CVE数据，可以设计以下指令模板：
- 指令：请分析这个漏洞的成因、影响范围，并给出修复建议。
- 输入：CVE编号、受影响的组件和版本、漏洞描述。
- 输出：包含漏洞成因分析、危害评级、利用难度评估、修复方案的完整回答。
数据转换的常用方法有两种：基于规则的模板转换和基于大模型本身的生成式转换。规则模板速度快、一致性高，但生成的内容比较死板；用大模型来改写则更灵活，但需要消耗一定量的token，并且生成质量需要人工抽检。
我实际项目里的做法是“两条腿走路”：对于结构化程度高的数据（如CVE、漏洞描述、工具输出），用规则模板直接转换；对于非结构化的长文章（如技术博客、应急响应报告），用现成的开源大模型做一次摘要与问答对生成，然后人工抽检。这样做既能保证效率，又能控制成本。
4. 数据清洗与去重：训练出好模型的分水岭
很多人在数据获取上花了大量时间，却在数据清洗上草草了事。这是非常可惜的。从我自己的实验经验来看，清洗环节决定了一个数据集的“可用上限”，清洗做不好，后面所有工作都要打折扣。
4.1 敏感信息与合规性处理
网络安全领域的数据清洗，有一个其他领域不常遇到的特殊要求：大量文本中会包含IP地址、域名、人员姓名、企业名称、真实漏洞详情等敏感信息。如果直接把这些数据喂给模型，模型在生成回答时有可能把这些敏感信息“吐”出来，这在真实业务场景中是不能接受的。
所以，清洗的第一件事就是做敏感信息脱敏。需要处理的内容包括：
- IP地址和端口号，替换为保留结构但不指向真实目标的占位符（如
x.x.x.x）； - 真实域名，替换为
example.com一类的公共保留域名； - 邮箱和手机号，统一替换为脱敏格式；
- 真实的人名和公司名，替换为虚构名称；
- 仍然在有效期内的未公开漏洞详情，直接删除相关段落，不要留。
这里要特别提醒一句：脱敏不是简单地把值替换掉就完事，而是要考虑上下文中的关联信息。比如一篇报告里同时出现了某公司名称和对应的系统架构信息，即使IP被替换了，这两条信息联合起来仍然可能指向真实目标。所以安全行业的脱敏，必须和领域专家一起做一轮“语义级”审查。
4.2 去重与质量过滤
去重是提高数据集质量最有效的手段。网络安全领域的文章相互引用、抄袭、转发的现象非常普遍，尤其是漏洞分析类文章，经常能在多个平台看到高度相似的版本。如果不去重，模型就会被同一内容的多个变体“带偏”，导致重复内容在训练集中占比过大。
去重我一般分两层做：第一层是精确去重，直接用内容的MD5或SHA256哈希值做比对，这个简单高效，能去掉完全重复的文本；第二层是语义去重，用SimHash或MinHash算法对文本做指纹提取，然后把海明距离小于某个阈值的文本判定为近似重复，再做合并或剔除。
质量过滤方面，我通常会设计一个多维度评分规则。最基本的几条规则包括：
- 文本长度不足200字的内容直接丢弃；
- 有效字符占比（去除标点和空白后的字符比例）低于85%的丢弃；
- 包含大量乱码、特殊符号、无意义重复词的内容丢弃；
- 明显是广告、招聘、灌水的内容，按关键词库过滤掉。
4.3 标注与格式统一
清洗完成后，最后一步就是让所有数据变成统一的“指令-回答”格式。这一步如果前面做得好，现在就是纯粹的执行工作。我常用的做法是维护一套JSONL格式的数据集，每行一个JSON对象，结构如下：
{ "instruction": "请分析以下代码中存在的SQL注入漏洞，并给出修复建议", "input": "SELECT * FROM users WHERE id = " + user_input", "output": "该代码存在SQL注入漏洞，因为user_input未经过滤直接拼接进入SQL查询...建议使用参数化查询..." }在指令设计上有一个比较容易忽略的点：指令的粒度要适中。指令太宽泛（比如“分析这个漏洞”），模型的输出会因为没有边界而跑偏；指令太狭窄（比如“列出CWE-89的修复方式中的第二条”），数据集的通用性又不足。我通常会把指令粒度控制在“任务类型+目标对象+输出约束”这个层级上。举个例子，“请分析这个PHP代码片段是否存在文件包含漏洞，如果存在，请指出触发路径并给出修复建议”，就是一个粒度合适的指令。
5. 常见问题与排错实录
数据获取和清洗这个环节，踩坑的概率远高于训练本身。我把经常遇到的问题整理成一个简要的清单，希望能帮你少走弯路。
5.1 反爬限制触顶怎么办
抓取过程中最常见的报错是403 Forbidden和429 Too Many Requests。前者通常是因为请求头缺失或不合法，后者是因为请求频率过高。解决办法很简单：加全的User-Agent、Referer等请求头，降低请求频率，必要时加随机延时。如果目标网站对特定IP的封禁时间较长，配置代理池基本上能解决。
但有一个底线要守住：不要对公开网站发起高强度抓取，这既是对目标站点的尊重，也是保护自己的方式。如果确实需要大量数据，优先通过官方API获取，或者邮件联系网站所有者说明用途，很多安全社区的维护者本身也是技术人，沟通得当的情况下能直接拿到脱敏后的数据。
5.2 数据集标注质量不稳定
这是自建语料阶段最难缠的问题。我最早做漏洞问答数据时，直接找了一批技术群的朋友帮忙标注，结果发现不同人的标注风格和理解水平差异极大，导致数据集的回答风格五花八门，训练出来的模型也表现得“人格分裂”。
后来我调整了策略：先自己花费一周时间梳理标注规范，把回答格式、语气、详略标准、边界情况全部写成文档，并做了二十条示范样本。标注人拿到规范后先做测试标注，我逐条审核通过后才让他们正式开工。同时在最终入库前，我会对所有标注数据做一次随机抽样审核，抽检比例不低于5%。这套流程走下来，数据集质量明显稳定了。
5.3 数据分布失衡
网络安全领域的数据分布天然是不均衡的，SQL注入和XSS的资料铺天盖地，而SSRF、反序列化、条件竞争这些方向的优质数据则相对稀缺。如果不加干预，训练出来的模型会对常见漏洞非常敏感，对冷门漏洞的判断能力会很差。
我的办法是对数据集做类别重采样。简单来说，对样本量少的类别做上采样（复制或通过改写扩增），对样本量多的类别做下采样（随机抽样或聚类去重），让各类别在最终数据集中尽量均衡。这个过程可以用一个非常简单的方式实现：
import pandas as pd df = pd.read_json("raw_dataset.jsonl", lines=True) # 按漏洞类型统计样本数量 counts = df["vuln_type"].value_counts() # 设置目标数量为最大类别的80% target_count = int(counts.max() * 0.8) balanced_dfs = [] for vuln_type in counts.index: sub_df = df[df["vuln_type"] == vuln_type] if len(sub_df) >= target_count: balanced_dfs.append(sub_df.sample(target_count, random_state=42)) else: # 样本量不足时，采取简单的文本改写扩增 balanced_dfs.append(sub_df) balanced_df = pd.concat(balanced_dfs).sample(frac=1, random_state=42) balanced_df.to_json("balanced_dataset.jsonl", orient="records", lines=True)需要注意，上采样如果只是简单复制，模型容易过拟合。更好的做法是结合同义词替换、句式改写等方式做数据增强，但这部分对领域理解的要求比较高，需要谨慎操作。
5.4 数据编码与格式混乱
从不同渠道抓来的数据，编码问题非常让人头疼。有的页面是UTF-8，有的是GBK/GB2312，有的还在UTF-8里混入了ISO-8859-1的二进制残留。我建议在数据入库前统一做一次编码检测和转换：
import chardet def normalize_encoding(content: bytes) -> str: """检测并将字节内容转换为UTF-8文本""" detection = chardet.detect(content) encoding = detection.get("encoding", "utf-8") try: return content.decode(encoding, errors="replace") except Exception: return content.decode("utf-8", errors="replace")chardet这个库对常见编码的识别率还是比较高的，虽然偶尔会误判，但结合errors="replace"策略，至少不会让程序崩溃。排序下来，编码问题在清洗环节中虽然烦人，但解决起来其实是最机械、最没有技术含量的。
6. 数据迭代与持续更新策略
最后聊一个很多教程不会讲、但实际项目中特别重要的点：数据不是一次性收集完就结束的，它是需要持续迭代的资产。
6.1 建立数据闭环
网络安全领域变化极快，新的漏洞类型、新的攻击手法、新的工具链几乎每天都在出现。如果你的模型只基于某一时刻的快照数据训练，那么它会在未来半年内迅速过时。所以，我建议在你整个训练体系中建立一条数据闭环：定期（比如每周或每两周）从各个源自动增量拉取最新数据，经过清洗和去重后合并到已有数据集中，再定期对模型做增量训练或全量重训。
这里面有一个工程上的小技巧：增量更新的关键是要有可靠的“最后更新时间”字段。无论是CVE数据还是社区文章，每条记录都应该记录首次入库时间和最后更新时间，这样不仅能追踪数据的时效性，还能在数据源出现问题后快速定位和回滚。
6.2 建一个自己的评测集
很多人把精力全放在训练数据上，却忘记留一部分高质量数据作为评测集。我自己的经验教训是：评测集的价值一点也不比训练集低。因为你无法确保训练出来的模型在真实任务上表现如何，除非有一批“标准答案”可以对照。
建议在数据积累过程中，每收集和清洗完一批数据，就抽取其中5%左右作为评测集。这5%的数据永远不进入训练集，只用来评估模型效果。评测集里要覆盖各类漏洞类型、不同难度的样本、不同格式的问法，这样才能比较全面地判断模型的真实水平。
我的个人体会是，评测集从第一天就开始积累，不要等模型训练一轮之后才想起来去构建。因为如果评测集是后补的，你很难证明它没有无意中受到训练数据的影响。那种“评测结果完美”的情况，很多时候只是评测集和训练集重叠过多造成的假象。
网络安全大模型的数据获取，说到底是在一个高度专业化的领域里做高质量语料的“淘金”。没有捷径，也没有一招鲜的标准方案，更多是把公开数据、社区知识、自建语料结合起来，反复迭代、持续积累的一个过程。我踩过不少坑，比如盲目追求数据量导致模型学习了很多噪声，比如清洗不到位导致模型输出敏感信息，再比如数据分布失衡把模型带偏。每一坑最后都是靠更细致的数据工程补回来的。希望这篇内容能让你在开始之前就建立起对数据获取这件事的基本判断，少走几步弯路。
