网络安全大模型和普通大模型最大的区别不在模型结构也不在训练框架而在数据。普通模型要的是语言通顺、知识广博网络安全模型要的是“在正确的时候给出正确的攻击或防御动作”。差之毫厘谬以千里。所以这个系列写到第十四篇专门拿出一整篇来聊数据获取我觉得是非常有必要的——数据这一关过不了后面做对齐、做微调、做评测全部是空中楼阁。这篇内容我会按照我实际做项目时的思路来讲先厘清网络安全大模型到底需要哪些数据再逐一拆解可以从哪里拿、怎么拿、拿到之后怎么清洗和标注最后聊一聊这个过程中我踩过的一些坑。整个过程里涉及的工具和平台大部分都是公开的你自己就能上手去试。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题目与WriteUpGitHub上有大量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数据为例的采集实现NVDNational Vulnerability Database提供了官方的REST API这比直接爬HTML页面要稳定得多。API接口地址是https://services.nvd.nist.gov/rest/json/cves/2.0这个接口支持分页和关键词过滤单次最多能拉取2000条记录对于大多数场景完全够用。下面这段代码演示了如何拉取指定时间窗口内的CVE数据并将其入库到SQLiteimport 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, paramsparams, timeout30) 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_pathcve_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(days30) 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, linesTrue) # 按漏洞类型统计样本数量 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_state42)) else: # 样本量不足时采取简单的文本改写扩增 balanced_dfs.append(sub_df) balanced_df pd.concat(balanced_dfs).sample(frac1, random_state42) balanced_df.to_json(balanced_dataset.jsonl, orientrecords, linesTrue)需要注意上采样如果只是简单复制模型容易过拟合。更好的做法是结合同义词替换、句式改写等方式做数据增强但这部分对领域理解的要求比较高需要谨慎操作。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, errorsreplace) except Exception: return content.decode(utf-8, errorsreplace)chardet这个库对常见编码的识别率还是比较高的虽然偶尔会误判但结合errorsreplace策略至少不会让程序崩溃。排序下来编码问题在清洗环节中虽然烦人但解决起来其实是最机械、最没有技术含量的。6. 数据迭代与持续更新策略最后聊一个很多教程不会讲、但实际项目中特别重要的点数据不是一次性收集完就结束的它是需要持续迭代的资产。6.1 建立数据闭环网络安全领域变化极快新的漏洞类型、新的攻击手法、新的工具链几乎每天都在出现。如果你的模型只基于某一时刻的快照数据训练那么它会在未来半年内迅速过时。所以我建议在你整个训练体系中建立一条数据闭环定期比如每周或每两周从各个源自动增量拉取最新数据经过清洗和去重后合并到已有数据集中再定期对模型做增量训练或全量重训。这里面有一个工程上的小技巧增量更新的关键是要有可靠的“最后更新时间”字段。无论是CVE数据还是社区文章每条记录都应该记录首次入库时间和最后更新时间这样不仅能追踪数据的时效性还能在数据源出现问题后快速定位和回滚。6.2 建一个自己的评测集很多人把精力全放在训练数据上却忘记留一部分高质量数据作为评测集。我自己的经验教训是评测集的价值一点也不比训练集低。因为你无法确保训练出来的模型在真实任务上表现如何除非有一批“标准答案”可以对照。建议在数据积累过程中每收集和清洗完一批数据就抽取其中5%左右作为评测集。这5%的数据永远不进入训练集只用来评估模型效果。评测集里要覆盖各类漏洞类型、不同难度的样本、不同格式的问法这样才能比较全面地判断模型的真实水平。我的个人体会是评测集从第一天就开始积累不要等模型训练一轮之后才想起来去构建。因为如果评测集是后补的你很难证明它没有无意中受到训练数据的影响。那种“评测结果完美”的情况很多时候只是评测集和训练集重叠过多造成的假象。网络安全大模型的数据获取说到底是在一个高度专业化的领域里做高质量语料的“淘金”。没有捷径也没有一招鲜的标准方案更多是把公开数据、社区知识、自建语料结合起来反复迭代、持续积累的一个过程。我踩过不少坑比如盲目追求数据量导致模型学习了很多噪声比如清洗不到位导致模型输出敏感信息再比如数据分布失衡把模型带偏。每一坑最后都是靠更细致的数据工程补回来的。希望这篇内容能让你在开始之前就建立起对数据获取这件事的基本判断少走几步弯路。
