1. 网络安全大模型的数据困局先从最容易被忽略的问题说起去年我在帮一家安全公司搭训练管线对方CTO一上来就说“模型架构我们跑得通GPU也到位了就是不知道喂什么数据。”后来我翻了下他们已有的数据集发现一堆从GitHub爬来的POC脚本标签乱得没法看还有大量重复的扫描日志。最要命的是他们拿这些数据训练出的模型检测精度看着还行一上真实流量就疯狂误报。这个场景太典型了。做网络安全大模型难的不是模型设计而是数据获取。很多人都以为数据就是“拿来喂模型的东西”其实在安全这个垂直领域数据本身就是一种对抗资源是攻防双方博弈的产物。我经常跟朋友打一个比方通用大模型的数据像自来水打开水龙头就有最多过滤一下网络安全大模型的数据像深井水你必须先找到地下哪里含水再打井、装水泵、净化而且你打出来的水还可能被人下过毒。这篇内容就是围绕“数据获取”这一个环节把我在多个安全大模型项目里踩过的坑、试对的路、沉淀下来的流程完整讲一遍。它适合谁看两类人一类是想从零搭安全大模型的数据工程师另一类是已经在跑模型但数据集质量一直上不去的算法工程师。我会讲清楚数据源怎么选、清洗怎么做、标签怎么打、质量怎么控以及那些踩完一次就不想再踩的坑。2. 数据获取的整体设计别急着爬数据先想清楚模型到底要什么2.1 先回答“模型要学什么”再回答“数据从哪来”网络安全领域太大漏洞、恶意流量、钓鱼邮件、Web攻击、二进制分析、日志审计每个方向的数据形态完全不同。如果一上来就满天撒网搜集数据最后得到的必然是一堆“看似很多、用起来全废”的杂货铺。我常用的方式是把“模型能力需求”拆成一张表先想清楚目标再找数据源模型能力期望输入输出所需数据类型漏洞情报问答输入漏洞描述输出修复建议CVE描述、漏洞PoC分析、补丁公告、CWE分类Web攻击检测输入HTTP流量输出攻击类型正常流量攻击流量SQL注入、XSS、命令注入等恶意URL识别输入URL字符串输出风险等级良性URL样本、钓鱼URL样本、恶意重定向链日志异常分析输入告警日志序列输出是否异常正常访问日志、真实入侵日志、模拟攻击日志安全代码审计输入代码片段输出漏洞类型与位置带漏洞代码修复后代码GitHub安全公告、CWE案例钓鱼邮件识别输入邮件正文输出是否钓鱼正常邮件、钓鱼邮件、垃圾邮件含附件类型这张表列完数据获取的目标就从“找安全数据”变成了“为每个能力项找到最匹配的数据源组合”。实操中我一般要求每个能力项至少准备两到三种不同来源的数据防止单一数据源带来偏见这一点后面会详细说。2.2 三条数据主线的选择逻辑公开、半公开、自研三条腿走路我把安全大模型的数据源分成三条主线对应的获取成本和质量保障完全不同。第一条主线是公开数据。CVE漏洞库、NVD、Exploit-DB、GitHub安全公告、OWASP、安全厂商公开的威胁情报报告、CTF比赛题目及Writeup这些都是免费可用的。优点是容易获取、覆盖面广缺点是噪声多、重复率高而且很多安全报告都是PDF格式解析起来非常费劲。第二条主线是半公开数据。厂商发布的威胁情报API如国内外的安全厂商多提供了免费额度的IOC查询接口、各类安全社区公开的样本包需要申请或脱敏、SRC平台公开的部分漏洞报告去除敏感信息后。这类数据质量比公开数据高一个档次但要办手续、签协议获取周期长不能临时抱佛脚。第三条主线是自研数据。利用已有的安全设备WAF、IDS、EDR从真实业务流量中采集并在内部沙箱中模拟攻击生成数据。这条线成本最高但产出的数据是最贴合自己业务场景的。我的建议是公开数据打底60%-70%半公开数据补强20%-30%自研数据定向优化10%-20%。这个比例不是拍脑袋定的是我测过多个项目后得出的经验值自研数据比例太高模型容易过拟合到自己的网络环境换一个用户场景就失灵太低又起不到特定优化作用。2.3 避开“自建爬虫大军”的无底洞能拉的数据千万别自己造轮子很多团队一上来就想自己写爬虫去抓CNNVD、CVE、各大安全博客的数据。我的态度是能用现成接口的绝不自研能半自动化的绝不全人工。以漏洞数据为例NVD和CNNVD都提供了CVE JSON数据格式直接按年份批量下载即可CVE涵括1999年至今的所有漏洞条目每条记录包含CVE编号、描述、CVSS评分、参考链接、影响产品等关键信息。GitHub的API也可以用来批量拉取安全相关仓库的commit记录和issue讨论。自己写爬虫去抓网页类数据成本高在三个方面一是目标站点的反爬机制一直在变今天是UA检测明天上JS渲染后天加验证码维护成本是无底洞二是网页结构改版一次解析规则就全废三是从网页里抽出来的信息质量参差不齐描述、PoC、时间线混在一起清洗成本比采集成本还高。所以数据获取的第一步不是“动手写代码”而是“摸清楚现有数据源能提供什么格式、什么质量、什么更新频率”。这一步做扎实了后续能省掉至少三分之一的返工时间。3. 核心数据源的解析与获取要点每个源都有它自己的脾气3.1 CVE/NVD漏洞库数据基础中的基础但不要盲信CVE是安全大模型最基础的数据源几乎所有做安全模型的项目都绕不开。但这里有个经典误区很多人以为拿到了CVE JSON就拿到了“干净的漏洞知识”大错特错。NVD的CVE记录里描述部分description写得极其模板化比如“A vulnerability was found in xxx. It has been classified as critical. Affected component is xxx”一段描述翻来覆去就是那些话。直接把这种原文喂给模型模型学到的不是漏洞本质而是“套话生成能力”。我处理CVE数据的实操流程是这样的先按年份下载CVE JSONNVD提供按年打包用Python解析出CVE编号、描述、CVSS向量、CWE编号、参考链接把描述拆成结构化字段受影响产品/版本、漏洞类型、攻击路径、影响后果手工写一套正则规则模板做初筛再从参考链接中提取Patch链接和厂商公告去补全“怎么修”的信息最后用OpenAI或其他通用大模型对描述做重写把“套话型描述”转换成“普通人能看懂的漏洞讲解型描述”。注意第4步存在信息幻觉风险通用大模型可能把不存在的攻击条件写得一本正经。所以我要求通用模型重写时必须是“不新增信息、只调整表达”并强制输出“原文信息点检查清单”再走人工抽检。3.2 Git与代码仓库数据漏洞代码与修复代码的黄金配对代码类数据是做安全代码审计模型和漏洞检测模型的重点。我认为最佳代码数据形态是“漏洞代码修复代码”的配对样本模型要学的是从“有漏洞”到“修复后”的变化模式。获取路径主要有三条一是GitHub Security Advisories安全公告里面会关联受影响的仓库和对应的修复commit二是GitHub API搜索commit信息用关键词如“fix security vulnerability”“patch XSS”“fix CVE”去检索提交记录然后通过commit的diff拿到修复前后的代码变化三是从开源漏洞库项目如Vul4J、VulDeePecker的数据集直接拉取别人整理好的配对数据但这些数据集的时效性通常偏旧单靠它不够。这里有个重要细节GitHub搜索API有速率限制40个积分每分钟刷一次一次搜索请求会扣掉好几个积分大批量拉取时必须控制速率否则很快被限流。实操中我是用定时任务匀速跑每小时拉一个批次用SQLite做本地去重缓存避免重复入库。代码数据清洗时还有两个容易被忽视的点删除测试目录和自动生成代码比如lock文件、minified JS否则模型很容易学到噪声注意许可证问题。GitHub上的代码有不同开源协议虽然训练用数据在法律边界上还在讨论中但出于稳妥考虑我会优先选MIT、Apache-2.0协议的项目GPL协议的慎用。3.3 安全社区与威胁情报半公开数据怎么拿安全社区和威胁情报的价值在于时效性强CVE库还没收录的攻击手法安全研究员可能已经写成了分析文章。这些内容往往包含攻击链、样本哈希、C2地址、检测规则YARA、Suricata规则等对模型来说简直是浓缩精华。常见的半公开数据源包括安全厂商的威胁情报报告如年度APT报告、季度DDoS报告、运营商安全年报这类报告在厂商官网通常可免费下载PDF安全社区平台如FreeBuf、安全客、先知社区有大量技术分析文章部分平台开放了文章列表接口可以通过RSS或搜索爬取开源威胁情报源如Abuse.ch系列项目、PhishTank、URLhaus提供IOC数据下载格式规范非常友好CTF赛题与Writeup涵盖了大量攻击技巧的代码级细节但由于题目是模拟环境数据分布跟真实攻击差异大。这类数据的最大难点是清洗。PDF报告要先做文本抽取用常见的文档解析工具都可能出现排版错乱表格信息丢失尤为常见。我的经验是优先找厂商同时发布的HTML版本或Markdown版本实在只有PDF再走解析流程解析后必须做人工抽检抽查比例不低于10%。还有一点从威胁情报报告提取IOC指标时不要只存字符串要把上下文一起截取下来。比如一条C2域名单独存一个域名对模型没什么用但如果同时保留“该域名常与XX木马家族关联通信特征为XX格式”这个样本的信息量就完全不同了。3.4 自研数据采集真实业务流量里的金子与噪声真实业务流量是最贴近实际场景的数据但也是清洗成本最高的一块。我在帮银行客户做安全模型时他们内部每天产生数TB的Web访问日志真正有价值的攻击流量可能不到万分之一更大的问题在于日志脱敏和合规。自研数据采集主要有三类做法第一类是在WAF或网关层面镜像流量。通过旁路部署抓包工具将HTTP/HTTPS流量记录为PCAP格式然后按会话切分再对payload做脱敏和特征提取。这个做法对硬件和存储要求很高PCAP文件非常占空间一小时能产生几十GB。第二类是在内网沙箱中主动模拟攻击。用自动化攻击工具去扫描并攻击自建的靶场环境这样能精确知道哪些流量对应哪种攻击数据标注成本低、标注准确率高。缺点是攻击工具产生的流量模式相对固定跟真实攻击者千变万化的手法有差距。第三类是部署蜜罐。在内网和公网部署低交互/高交互蜜罐记录攻击者的探测和利用行为。蜜罐的数据最接近真实攻击但噪声极大扫描器全互联网乱扫的流量占了绝大多数。不论哪类做法自研数据都必须过“脱敏”这一关。URL中的会话ID、请求头中的Cookie、请求体中的手机号/身份证号/银行卡号这些都要统一用占位符替换。合规不是小事一旦出问题模型没训成公司先摊上事。4. 数据清洗与预处理实操安全数据为什么这么脏4.1 去重你以为在去重其实是在做情报关联安全数据去重和通用数据去重不太一样不能只做文本层面的“一模一样算重复”。很多安全报告的重复是部分重复——同一家安全厂商发出报告其他媒体转载内容经过删改同一个漏洞CVE库、NVD、厂商公告、分析文章四个来源都有描述说法截然不同。所以安全数据的去重一定要做“语义级去重”和“事件级归并”。以CVE编号作为唯一键把不同来源的表述归并起来再通过SimHash或embedding相似度对没有CVE编号的文本做模糊匹配最后再做精确查重。这个流程实现起来稍微复杂但效果立竿见影我做过一个项目初版数据集3万条事件级归并后直接砍到1.6万条而且剩下的样本的信息密度远高于原来。同时去重完成后要统计数据分布防止某一类攻击在数据集中过度膨胀。比如SQL注入的样本网上最多、最好收集一个不留神它就能占到整体样本的40%以上模型会对SQL注入极度敏感对其他攻击类型反应迟钝这就是严重的数据偏斜问题。4.2 文本清洗安全文本里的“脏”和通用文本完全不同通用文本清洗是删HTML标签、去停用词、统一大小写安全文本的清洗要复杂得多。我踩过几个坑列出来给大家避雷第一个是代码与文本混杂。安全文章里经常嵌入代码块、终端输出、HTTP请求报文这些内容直接被tokenizer切碎之后只能当噪声但全删又太可惜。我的做法是把代码块和文本内容分开处理代码块单独作为代码样本入库文本部分做漏洞知识语料保持两条线并行。第二个是Base64与编码文本。攻击日志里有大量Base64、URL编码、十六进制编码的payload这些编码文本直接泛化能力极差。处理时先判断编码格式再做解码尝试能解的就解出来解完还是乱码的才丢弃。解码后的攻击语句对模型训练价值巨大它能让模型理解攻击的本质逻辑而不只是记住编码形态。第三个是不同字符集的语言混杂问题。安全社区的文章中英混杂非常常见专业术语、漏洞利用代码用英文分析描述用中文。清洗时不要强行统一语言安全大模型本来就要具备中英文混合理解能力这是该领域模型的特色。4.3 数据标注只靠人力会疯只靠规则会废标注是安全数据获取里最磨人的环节。安全数据的标注和图像分类不同需要标注者对攻击原理有深入理解一个“SQL注入”和“命令注入”分不清的标注员产出的数据会让模型学到完全错误的知识。我采用的标注架构是“三级流水线”第一级规则标注。把容易判断的样本交给正则和规则引擎比如CVE编号可以直接关联CWE分类攻击payload特征库里能精确命中的直接打标HTTP方法路径能判断攻击类型的先给初标。这一级能处理60%左右的样本。第二级模型辅助标注。让已经跑通的通用模型对未标样本做预标注并要求模型给出标注理由。再设置置信度阈值高置信度样本直接入池低置信度样本留给人工。第三级人工复核。由安全工程师对模型预标注的结果做抽检和修正重点关注模型容易混淆的类型比如XSS与HTML注入、SSRF与CSRF。抽检比例建议不低于20%遇到敏感样本必须100%核对。整个标注流程做完我还会强制做一次“一致性检验”随机抽取一批样本让两个不同的安全工程师背靠背各自标一遍算一下标注一致性系数。如果低于0.8说明标注标准本身定义不清需要回头修改标注手册这时候模型还没开始训练返工成本最低。5. 数据质量验证与常见问题排查别等模型训完才发现数据全是坑5.1 质量评估指标体系哪些指标才是真正有用的数据质量不能只靠感觉“看起来不错”要有一套可量化的指标来卡门槛。我在项目里一般会盯这六个指标指标定义合理范围达不到的处理方式重复率语义级重复样本占比5%加强归并策略标签准确率人工抽检中标签正确的比例95%修复标注规则攻击类型覆盖率覆盖OWASP Top 10及常见攻击类别的比例核心类别全覆盖定向补采数据时间新鲜度近一年数据的占比至少30%抓取最新威胁情报信噪比有效信息样本/全部样本70%加强清洗过滤对抗鲁棒性已知绕过技巧在样本中的体现度核心攻击至少5种变体人工构造对抗样本这六个指标是做数据发布前的“闸门”任何一个不达标都不能进入训练环节。特别是时间新鲜度安全攻击手法一年一小变、三年一大变五年前的数据对当前威胁的参考价值已经很低了。我的原则是老数据保留作为基础语料但模型微调时必须保证一定比例的最新数据做增强。5.2 常见问题速查与排查记录我把在多个项目里反复踩过的数据问题整理成了一张速查表新项目碰到类似情况时可以快速对照现象可能原因排查方法解决建议模型对某一类攻击极度偏好该类攻击样本占比过高统计训练集类别分布做类别均衡采样或过采样模型在真实流量上误报率很高训练数据缺乏正常流量样本检查正常样本与攻击样本比例补充真实业务正常流量模型回答漏洞修复建议不具体数据中“怎么做”的信息太少检查样本是否只含漏洞描述补充补丁公告和修复commit数据模型在编码攻击面前失效训练数据以解码后文本为主检查原始payload保留比例保留20%左右原始编码样本模型中文回答夹生中英文混合语料比例失调统计语料语言分布补充高质量中文安全语料脱敏数据与真实数据分布差异大脱敏规则过度替换对比脱敏前后特征分布采用保格式加密或差分隐私其中“编码攻击失效”这个坑我印象特别深刻。有一版模型在测试集上表现很好一上线就被一个简单的Base64编码的SQL注入绕过原因就是训练时我把所有payload都解码了模型根本没学会识别编码形态的攻击。后来调整策略保留20%原始编码样本作为对抗训练数据模型的鲁棒性立刻上来了。5.3 对抗样本与数据投毒防范做安全模型要充分想象“有人要害你”网络安全大模型有一个特殊的风险是攻击者会故意构造样本引导模型学错东西。如果你用了爬来的数据且不检查攻击者可以在公开的GitHub仓库里塞入带恶意逻辑的高星项目代码或者在某些安全社区发布包含错误结论的分析文章而你的爬虫会把它们当成优质数据采走。我踩过这个坑。有一次我在一个开源代码数据集中发现一个仓库的commit信息大量写着“fix vulnerability”但仔细看diff内容修复前后的代码根本没有实质变化有些甚至还把原本安全的写法改成有漏洞的写法。我怀疑是某些仓库为了蹭热度故意提交这样一种“伪修复”的commit来污染数据集。防范手段有三个层面第一是源层面优先使用可信源的官方API或数据打包对社区内容设置较高的准入标准第二是样本层面代码数据必须做编译或静态检查保证“修复前后代码均可运行”才能入库第三是训练层面引入数据溯源机制每条数据都记录来源URL和采集时间一旦发现某个来源存在投毒迹象可以精确追溯到该来源的全部样本并及时清理。另外一个实用小技巧对采集的每条数据做一个“来源信誉分”官方机构数据源5分、知名社区3分、个人博客2分、匿名分享1分。训练时可以按信誉分做加权采样这是个很土但很有效的方法能显著减少低质数据的干扰。6. 数据获取流程落地一条可以照着抄的完整工作流6.1 从零启动一个安全数据项目的最小步骤清单我把整个数据获取流程压缩成了一张可执行清单按顺序做就行定义模型能力范围。列出模型必须支持的攻击类型、数据形态和输出要求这一步输出是一张《能力-数据需求对照表》盘点存量数据。把团队手头已有的数据全部集中起来做一次摸底清点包括格式、数量、来源、标签情况很多团队做完这一步发现自己的存量数据没想象中少制定数据源接入计划。按“公开-半公开-自研”三条线列出待接入的数据源标注优先级、评估周期和对接联系人搭建采集框架。用工作流调度平台定期跑采集任务数据入库统一走消息队列原始数据与处理后数据分开存储启动清洗与标注流水线。规则、模型、人工三级流水线并行跑先跑一小批验证效果再全量跑执行质量检验。跑完六个质量指标不达标的数据集不允许进入训练环节。这套流程如果只有一个人执行第一版数据大概需要三到四周如果有三到五人的小团队可以压缩到两周左右。关键瓶颈不在爬数据的速度而在清洗规则和标注标准的反复打磨。6.2 自动化采集框架示例最小可用版本的实现思路很多朋友会问做这类采集需要什么基础设施。坦白说刚开始不需要很重的框架一台4核16G的云服务器加一个分布式调度工具就够用了。我用的是Airflow做定时调度配合SQLite做元数据管理所有采集脚本用Python封装成独立DAG任务互不干扰。# 一个最小可用的CVE数据增量采集示例 import requests import json from datetime import datetime, timedelta def fetch_recent_cves(days7): 从NVD API获取最近days天的CVE增量数据 base_url https://services.nvd.nist.gov/rest/json/cves/2.0 params { pubStartDate: (datetime.now() - timedelta(daysdays)).strftime(%Y-%m-%dT00:00:00.000), pubEndDate: datetime.now().strftime(%Y-%m-%dT23:59:59.999), resultsPerPage: 2000 } resp requests.get(base_url, paramsparams, timeout30) if resp.status_code 200: data resp.json() vulns data.get(vulnerabilities, []) print(f获取到 {len(vulns)} 条CVE记录) for item in vulns: # 入库前先做字段精简只保留核心字段 cve item.get(cve, {}) record { id: cve.get(id), description: extract_desc(cve), published: cve.get(published), lastModified: cve.get(lastModified), cvss_score: extract_cvss(cve), cwe_ids: extract_cwes(cve) } # 这里调用预定义的入库函数示例中省略 insert_to_db(record) else: print(f请求失败: {resp.status_code}) def extract_desc(cve_obj): 从CVE对象中提取英文描述字段 descriptions cve_obj.get(descriptions, []) for desc in descriptions: if desc.get(lang) en: return desc.get(value, ) return def extract_cvss(cve_obj): 从CVE对象中提取CVSS评分 metrics cve_obj.get(metrics, {}) for key in [cvssMetricV31, cvssMetricV30, cvssMetricV2]: if key in metrics: cvss_data metrics[key][0] return cvss_data.get(cvssData, {}).get(baseScore) return None def extract_cwes(cve_obj): 从CVE对象中提取CWE编号 weaknesses cve_obj.get(weaknesses, []) return [w.get(description, [{}])[0].get(value) for w in weaknesses]这段代码演示的是从NVD增量拉取CVE记录的核心逻辑核心点在于一是用时间范围做增量更新不重复拉全量二是入库前做字段精简只保留模型训练真正需要的字段避免数据库无限膨胀三是所有异常都要有日志和告警采集任务挂了一晚上没人发现是会出大事的。6.3 数据版本管理与更新节奏做安全数据跟做软件版本一样严肃数据不是一次采集完就一劳永逸的。安全领域变化太快今天刚训练完的模型下周可能就有一个新的高危漏洞家族出现。数据要持续更新但更新不能是“随手抓一把”。我的做法是给数据集建立版本机制。每次新增或删改数据都记录版本号、变更内容、采集时间、处理脚本版本保证模型训练数据可追溯。比如“dataset_security_v3.2_20250115”含义是安全数据集第三版第二次迭代数据截至2025年1月15日。更新节奏上我一般会给不同数据源设置不同的更新频率CVE/NVD漏洞数据每日增量更新GitHub安全公告与commit数据每周全量扫描一次遇到重大安全公告触发即时增量威胁情报报告每周更新一次重大事件即时更新自研流量数据每月做一批采集季度做一次全面重新标注和质量评估。这样设置的原因是不同数据源的时效敏感度不同CVE是模型知识库的基础底座需要保持最新代码类数据变化相对集中每周扫描就够了自研数据采集成本高采集太频繁会导致存储爆炸。也要为恶性紧急事件留出“热更新通道”比如Log4j这种级别的漏洞爆发时要在24小时内完成数据采集、清洗、标注和增量训练。7. 一些实际操作后的心得体会写到最后分享几个这些年做安全数据积累下来的零散经验。第一数据获取这个环节千万不要想着一步到位。我见过很多团队花两三个月做了一整套超庞大的数据平台结果模型v0.1还没跑通平台需求就已经变了。更务实的做法是先用一条最简单的数据流跑通端到端确认模型能收敛再逐步往里面加数据源、加清洗规则。第二数据格式的设计要留有冗余。刚开始做数据表结构时我习惯把source_url、timestamp、raw_content这类字段都保留下来。当时团队有人抱怨浪费存储但后来做数据审计和溯源时这些字段帮了大忙特别是涉及数据合规和模型行为排查时。第三人工抽检比例绝对不能省。自动化清洗和标注再完善安全数据的语义复杂度过高总有规则覆盖不到的死角。我现在的标尺是代码类数据抽检10%威胁情报类数据抽检20%涉及具体业务环境的日志数据抽检30%。看着费时间其实是在给模型质量上保险这比模型训完再发现问题回头改数据划算得多。最后想说的一点是网络安全大模型的数据获取本质上是一个持续对抗的过程。你在收集数据攻击者也在试图污染数据。永远保持对数据来源的警惕心对每一条数据的“出生背景”都了然于胸这才是做安全模型数据工程最基本也最重要的素养。数据没问题了模型就成功了一大半。 网络安全大模型数据获取实战：从数据源选择到质量验证全流程
1. 网络安全大模型的数据困局先从最容易被忽略的问题说起去年我在帮一家安全公司搭训练管线对方CTO一上来就说“模型架构我们跑得通GPU也到位了就是不知道喂什么数据。”后来我翻了下他们已有的数据集发现一堆从GitHub爬来的POC脚本标签乱得没法看还有大量重复的扫描日志。最要命的是他们拿这些数据训练出的模型检测精度看着还行一上真实流量就疯狂误报。这个场景太典型了。做网络安全大模型难的不是模型设计而是数据获取。很多人都以为数据就是“拿来喂模型的东西”其实在安全这个垂直领域数据本身就是一种对抗资源是攻防双方博弈的产物。我经常跟朋友打一个比方通用大模型的数据像自来水打开水龙头就有最多过滤一下网络安全大模型的数据像深井水你必须先找到地下哪里含水再打井、装水泵、净化而且你打出来的水还可能被人下过毒。这篇内容就是围绕“数据获取”这一个环节把我在多个安全大模型项目里踩过的坑、试对的路、沉淀下来的流程完整讲一遍。它适合谁看两类人一类是想从零搭安全大模型的数据工程师另一类是已经在跑模型但数据集质量一直上不去的算法工程师。我会讲清楚数据源怎么选、清洗怎么做、标签怎么打、质量怎么控以及那些踩完一次就不想再踩的坑。2. 数据获取的整体设计别急着爬数据先想清楚模型到底要什么2.1 先回答“模型要学什么”再回答“数据从哪来”网络安全领域太大漏洞、恶意流量、钓鱼邮件、Web攻击、二进制分析、日志审计每个方向的数据形态完全不同。如果一上来就满天撒网搜集数据最后得到的必然是一堆“看似很多、用起来全废”的杂货铺。我常用的方式是把“模型能力需求”拆成一张表先想清楚目标再找数据源模型能力期望输入输出所需数据类型漏洞情报问答输入漏洞描述输出修复建议CVE描述、漏洞PoC分析、补丁公告、CWE分类Web攻击检测输入HTTP流量输出攻击类型正常流量攻击流量SQL注入、XSS、命令注入等恶意URL识别输入URL字符串输出风险等级良性URL样本、钓鱼URL样本、恶意重定向链日志异常分析输入告警日志序列输出是否异常正常访问日志、真实入侵日志、模拟攻击日志安全代码审计输入代码片段输出漏洞类型与位置带漏洞代码修复后代码GitHub安全公告、CWE案例钓鱼邮件识别输入邮件正文输出是否钓鱼正常邮件、钓鱼邮件、垃圾邮件含附件类型这张表列完数据获取的目标就从“找安全数据”变成了“为每个能力项找到最匹配的数据源组合”。实操中我一般要求每个能力项至少准备两到三种不同来源的数据防止单一数据源带来偏见这一点后面会详细说。2.2 三条数据主线的选择逻辑公开、半公开、自研三条腿走路我把安全大模型的数据源分成三条主线对应的获取成本和质量保障完全不同。第一条主线是公开数据。CVE漏洞库、NVD、Exploit-DB、GitHub安全公告、OWASP、安全厂商公开的威胁情报报告、CTF比赛题目及Writeup这些都是免费可用的。优点是容易获取、覆盖面广缺点是噪声多、重复率高而且很多安全报告都是PDF格式解析起来非常费劲。第二条主线是半公开数据。厂商发布的威胁情报API如国内外的安全厂商多提供了免费额度的IOC查询接口、各类安全社区公开的样本包需要申请或脱敏、SRC平台公开的部分漏洞报告去除敏感信息后。这类数据质量比公开数据高一个档次但要办手续、签协议获取周期长不能临时抱佛脚。第三条主线是自研数据。利用已有的安全设备WAF、IDS、EDR从真实业务流量中采集并在内部沙箱中模拟攻击生成数据。这条线成本最高但产出的数据是最贴合自己业务场景的。我的建议是公开数据打底60%-70%半公开数据补强20%-30%自研数据定向优化10%-20%。这个比例不是拍脑袋定的是我测过多个项目后得出的经验值自研数据比例太高模型容易过拟合到自己的网络环境换一个用户场景就失灵太低又起不到特定优化作用。2.3 避开“自建爬虫大军”的无底洞能拉的数据千万别自己造轮子很多团队一上来就想自己写爬虫去抓CNNVD、CVE、各大安全博客的数据。我的态度是能用现成接口的绝不自研能半自动化的绝不全人工。以漏洞数据为例NVD和CNNVD都提供了CVE JSON数据格式直接按年份批量下载即可CVE涵括1999年至今的所有漏洞条目每条记录包含CVE编号、描述、CVSS评分、参考链接、影响产品等关键信息。GitHub的API也可以用来批量拉取安全相关仓库的commit记录和issue讨论。自己写爬虫去抓网页类数据成本高在三个方面一是目标站点的反爬机制一直在变今天是UA检测明天上JS渲染后天加验证码维护成本是无底洞二是网页结构改版一次解析规则就全废三是从网页里抽出来的信息质量参差不齐描述、PoC、时间线混在一起清洗成本比采集成本还高。所以数据获取的第一步不是“动手写代码”而是“摸清楚现有数据源能提供什么格式、什么质量、什么更新频率”。这一步做扎实了后续能省掉至少三分之一的返工时间。3. 核心数据源的解析与获取要点每个源都有它自己的脾气3.1 CVE/NVD漏洞库数据基础中的基础但不要盲信CVE是安全大模型最基础的数据源几乎所有做安全模型的项目都绕不开。但这里有个经典误区很多人以为拿到了CVE JSON就拿到了“干净的漏洞知识”大错特错。NVD的CVE记录里描述部分description写得极其模板化比如“A vulnerability was found in xxx. It has been classified as critical. Affected component is xxx”一段描述翻来覆去就是那些话。直接把这种原文喂给模型模型学到的不是漏洞本质而是“套话生成能力”。我处理CVE数据的实操流程是这样的先按年份下载CVE JSONNVD提供按年打包用Python解析出CVE编号、描述、CVSS向量、CWE编号、参考链接把描述拆成结构化字段受影响产品/版本、漏洞类型、攻击路径、影响后果手工写一套正则规则模板做初筛再从参考链接中提取Patch链接和厂商公告去补全“怎么修”的信息最后用OpenAI或其他通用大模型对描述做重写把“套话型描述”转换成“普通人能看懂的漏洞讲解型描述”。注意第4步存在信息幻觉风险通用大模型可能把不存在的攻击条件写得一本正经。所以我要求通用模型重写时必须是“不新增信息、只调整表达”并强制输出“原文信息点检查清单”再走人工抽检。3.2 Git与代码仓库数据漏洞代码与修复代码的黄金配对代码类数据是做安全代码审计模型和漏洞检测模型的重点。我认为最佳代码数据形态是“漏洞代码修复代码”的配对样本模型要学的是从“有漏洞”到“修复后”的变化模式。获取路径主要有三条一是GitHub Security Advisories安全公告里面会关联受影响的仓库和对应的修复commit二是GitHub API搜索commit信息用关键词如“fix security vulnerability”“patch XSS”“fix CVE”去检索提交记录然后通过commit的diff拿到修复前后的代码变化三是从开源漏洞库项目如Vul4J、VulDeePecker的数据集直接拉取别人整理好的配对数据但这些数据集的时效性通常偏旧单靠它不够。这里有个重要细节GitHub搜索API有速率限制40个积分每分钟刷一次一次搜索请求会扣掉好几个积分大批量拉取时必须控制速率否则很快被限流。实操中我是用定时任务匀速跑每小时拉一个批次用SQLite做本地去重缓存避免重复入库。代码数据清洗时还有两个容易被忽视的点删除测试目录和自动生成代码比如lock文件、minified JS否则模型很容易学到噪声注意许可证问题。GitHub上的代码有不同开源协议虽然训练用数据在法律边界上还在讨论中但出于稳妥考虑我会优先选MIT、Apache-2.0协议的项目GPL协议的慎用。3.3 安全社区与威胁情报半公开数据怎么拿安全社区和威胁情报的价值在于时效性强CVE库还没收录的攻击手法安全研究员可能已经写成了分析文章。这些内容往往包含攻击链、样本哈希、C2地址、检测规则YARA、Suricata规则等对模型来说简直是浓缩精华。常见的半公开数据源包括安全厂商的威胁情报报告如年度APT报告、季度DDoS报告、运营商安全年报这类报告在厂商官网通常可免费下载PDF安全社区平台如FreeBuf、安全客、先知社区有大量技术分析文章部分平台开放了文章列表接口可以通过RSS或搜索爬取开源威胁情报源如Abuse.ch系列项目、PhishTank、URLhaus提供IOC数据下载格式规范非常友好CTF赛题与Writeup涵盖了大量攻击技巧的代码级细节但由于题目是模拟环境数据分布跟真实攻击差异大。这类数据的最大难点是清洗。PDF报告要先做文本抽取用常见的文档解析工具都可能出现排版错乱表格信息丢失尤为常见。我的经验是优先找厂商同时发布的HTML版本或Markdown版本实在只有PDF再走解析流程解析后必须做人工抽检抽查比例不低于10%。还有一点从威胁情报报告提取IOC指标时不要只存字符串要把上下文一起截取下来。比如一条C2域名单独存一个域名对模型没什么用但如果同时保留“该域名常与XX木马家族关联通信特征为XX格式”这个样本的信息量就完全不同了。3.4 自研数据采集真实业务流量里的金子与噪声真实业务流量是最贴近实际场景的数据但也是清洗成本最高的一块。我在帮银行客户做安全模型时他们内部每天产生数TB的Web访问日志真正有价值的攻击流量可能不到万分之一更大的问题在于日志脱敏和合规。自研数据采集主要有三类做法第一类是在WAF或网关层面镜像流量。通过旁路部署抓包工具将HTTP/HTTPS流量记录为PCAP格式然后按会话切分再对payload做脱敏和特征提取。这个做法对硬件和存储要求很高PCAP文件非常占空间一小时能产生几十GB。第二类是在内网沙箱中主动模拟攻击。用自动化攻击工具去扫描并攻击自建的靶场环境这样能精确知道哪些流量对应哪种攻击数据标注成本低、标注准确率高。缺点是攻击工具产生的流量模式相对固定跟真实攻击者千变万化的手法有差距。第三类是部署蜜罐。在内网和公网部署低交互/高交互蜜罐记录攻击者的探测和利用行为。蜜罐的数据最接近真实攻击但噪声极大扫描器全互联网乱扫的流量占了绝大多数。不论哪类做法自研数据都必须过“脱敏”这一关。URL中的会话ID、请求头中的Cookie、请求体中的手机号/身份证号/银行卡号这些都要统一用占位符替换。合规不是小事一旦出问题模型没训成公司先摊上事。4. 数据清洗与预处理实操安全数据为什么这么脏4.1 去重你以为在去重其实是在做情报关联安全数据去重和通用数据去重不太一样不能只做文本层面的“一模一样算重复”。很多安全报告的重复是部分重复——同一家安全厂商发出报告其他媒体转载内容经过删改同一个漏洞CVE库、NVD、厂商公告、分析文章四个来源都有描述说法截然不同。所以安全数据的去重一定要做“语义级去重”和“事件级归并”。以CVE编号作为唯一键把不同来源的表述归并起来再通过SimHash或embedding相似度对没有CVE编号的文本做模糊匹配最后再做精确查重。这个流程实现起来稍微复杂但效果立竿见影我做过一个项目初版数据集3万条事件级归并后直接砍到1.6万条而且剩下的样本的信息密度远高于原来。同时去重完成后要统计数据分布防止某一类攻击在数据集中过度膨胀。比如SQL注入的样本网上最多、最好收集一个不留神它就能占到整体样本的40%以上模型会对SQL注入极度敏感对其他攻击类型反应迟钝这就是严重的数据偏斜问题。4.2 文本清洗安全文本里的“脏”和通用文本完全不同通用文本清洗是删HTML标签、去停用词、统一大小写安全文本的清洗要复杂得多。我踩过几个坑列出来给大家避雷第一个是代码与文本混杂。安全文章里经常嵌入代码块、终端输出、HTTP请求报文这些内容直接被tokenizer切碎之后只能当噪声但全删又太可惜。我的做法是把代码块和文本内容分开处理代码块单独作为代码样本入库文本部分做漏洞知识语料保持两条线并行。第二个是Base64与编码文本。攻击日志里有大量Base64、URL编码、十六进制编码的payload这些编码文本直接泛化能力极差。处理时先判断编码格式再做解码尝试能解的就解出来解完还是乱码的才丢弃。解码后的攻击语句对模型训练价值巨大它能让模型理解攻击的本质逻辑而不只是记住编码形态。第三个是不同字符集的语言混杂问题。安全社区的文章中英混杂非常常见专业术语、漏洞利用代码用英文分析描述用中文。清洗时不要强行统一语言安全大模型本来就要具备中英文混合理解能力这是该领域模型的特色。4.3 数据标注只靠人力会疯只靠规则会废标注是安全数据获取里最磨人的环节。安全数据的标注和图像分类不同需要标注者对攻击原理有深入理解一个“SQL注入”和“命令注入”分不清的标注员产出的数据会让模型学到完全错误的知识。我采用的标注架构是“三级流水线”第一级规则标注。把容易判断的样本交给正则和规则引擎比如CVE编号可以直接关联CWE分类攻击payload特征库里能精确命中的直接打标HTTP方法路径能判断攻击类型的先给初标。这一级能处理60%左右的样本。第二级模型辅助标注。让已经跑通的通用模型对未标样本做预标注并要求模型给出标注理由。再设置置信度阈值高置信度样本直接入池低置信度样本留给人工。第三级人工复核。由安全工程师对模型预标注的结果做抽检和修正重点关注模型容易混淆的类型比如XSS与HTML注入、SSRF与CSRF。抽检比例建议不低于20%遇到敏感样本必须100%核对。整个标注流程做完我还会强制做一次“一致性检验”随机抽取一批样本让两个不同的安全工程师背靠背各自标一遍算一下标注一致性系数。如果低于0.8说明标注标准本身定义不清需要回头修改标注手册这时候模型还没开始训练返工成本最低。5. 数据质量验证与常见问题排查别等模型训完才发现数据全是坑5.1 质量评估指标体系哪些指标才是真正有用的数据质量不能只靠感觉“看起来不错”要有一套可量化的指标来卡门槛。我在项目里一般会盯这六个指标指标定义合理范围达不到的处理方式重复率语义级重复样本占比5%加强归并策略标签准确率人工抽检中标签正确的比例95%修复标注规则攻击类型覆盖率覆盖OWASP Top 10及常见攻击类别的比例核心类别全覆盖定向补采数据时间新鲜度近一年数据的占比至少30%抓取最新威胁情报信噪比有效信息样本/全部样本70%加强清洗过滤对抗鲁棒性已知绕过技巧在样本中的体现度核心攻击至少5种变体人工构造对抗样本这六个指标是做数据发布前的“闸门”任何一个不达标都不能进入训练环节。特别是时间新鲜度安全攻击手法一年一小变、三年一大变五年前的数据对当前威胁的参考价值已经很低了。我的原则是老数据保留作为基础语料但模型微调时必须保证一定比例的最新数据做增强。5.2 常见问题速查与排查记录我把在多个项目里反复踩过的数据问题整理成了一张速查表新项目碰到类似情况时可以快速对照现象可能原因排查方法解决建议模型对某一类攻击极度偏好该类攻击样本占比过高统计训练集类别分布做类别均衡采样或过采样模型在真实流量上误报率很高训练数据缺乏正常流量样本检查正常样本与攻击样本比例补充真实业务正常流量模型回答漏洞修复建议不具体数据中“怎么做”的信息太少检查样本是否只含漏洞描述补充补丁公告和修复commit数据模型在编码攻击面前失效训练数据以解码后文本为主检查原始payload保留比例保留20%左右原始编码样本模型中文回答夹生中英文混合语料比例失调统计语料语言分布补充高质量中文安全语料脱敏数据与真实数据分布差异大脱敏规则过度替换对比脱敏前后特征分布采用保格式加密或差分隐私其中“编码攻击失效”这个坑我印象特别深刻。有一版模型在测试集上表现很好一上线就被一个简单的Base64编码的SQL注入绕过原因就是训练时我把所有payload都解码了模型根本没学会识别编码形态的攻击。后来调整策略保留20%原始编码样本作为对抗训练数据模型的鲁棒性立刻上来了。5.3 对抗样本与数据投毒防范做安全模型要充分想象“有人要害你”网络安全大模型有一个特殊的风险是攻击者会故意构造样本引导模型学错东西。如果你用了爬来的数据且不检查攻击者可以在公开的GitHub仓库里塞入带恶意逻辑的高星项目代码或者在某些安全社区发布包含错误结论的分析文章而你的爬虫会把它们当成优质数据采走。我踩过这个坑。有一次我在一个开源代码数据集中发现一个仓库的commit信息大量写着“fix vulnerability”但仔细看diff内容修复前后的代码根本没有实质变化有些甚至还把原本安全的写法改成有漏洞的写法。我怀疑是某些仓库为了蹭热度故意提交这样一种“伪修复”的commit来污染数据集。防范手段有三个层面第一是源层面优先使用可信源的官方API或数据打包对社区内容设置较高的准入标准第二是样本层面代码数据必须做编译或静态检查保证“修复前后代码均可运行”才能入库第三是训练层面引入数据溯源机制每条数据都记录来源URL和采集时间一旦发现某个来源存在投毒迹象可以精确追溯到该来源的全部样本并及时清理。另外一个实用小技巧对采集的每条数据做一个“来源信誉分”官方机构数据源5分、知名社区3分、个人博客2分、匿名分享1分。训练时可以按信誉分做加权采样这是个很土但很有效的方法能显著减少低质数据的干扰。6. 数据获取流程落地一条可以照着抄的完整工作流6.1 从零启动一个安全数据项目的最小步骤清单我把整个数据获取流程压缩成了一张可执行清单按顺序做就行定义模型能力范围。列出模型必须支持的攻击类型、数据形态和输出要求这一步输出是一张《能力-数据需求对照表》盘点存量数据。把团队手头已有的数据全部集中起来做一次摸底清点包括格式、数量、来源、标签情况很多团队做完这一步发现自己的存量数据没想象中少制定数据源接入计划。按“公开-半公开-自研”三条线列出待接入的数据源标注优先级、评估周期和对接联系人搭建采集框架。用工作流调度平台定期跑采集任务数据入库统一走消息队列原始数据与处理后数据分开存储启动清洗与标注流水线。规则、模型、人工三级流水线并行跑先跑一小批验证效果再全量跑执行质量检验。跑完六个质量指标不达标的数据集不允许进入训练环节。这套流程如果只有一个人执行第一版数据大概需要三到四周如果有三到五人的小团队可以压缩到两周左右。关键瓶颈不在爬数据的速度而在清洗规则和标注标准的反复打磨。6.2 自动化采集框架示例最小可用版本的实现思路很多朋友会问做这类采集需要什么基础设施。坦白说刚开始不需要很重的框架一台4核16G的云服务器加一个分布式调度工具就够用了。我用的是Airflow做定时调度配合SQLite做元数据管理所有采集脚本用Python封装成独立DAG任务互不干扰。# 一个最小可用的CVE数据增量采集示例 import requests import json from datetime import datetime, timedelta def fetch_recent_cves(days7): 从NVD API获取最近days天的CVE增量数据 base_url https://services.nvd.nist.gov/rest/json/cves/2.0 params { pubStartDate: (datetime.now() - timedelta(daysdays)).strftime(%Y-%m-%dT00:00:00.000), pubEndDate: datetime.now().strftime(%Y-%m-%dT23:59:59.999), resultsPerPage: 2000 } resp requests.get(base_url, paramsparams, timeout30) if resp.status_code 200: data resp.json() vulns data.get(vulnerabilities, []) print(f获取到 {len(vulns)} 条CVE记录) for item in vulns: # 入库前先做字段精简只保留核心字段 cve item.get(cve, {}) record { id: cve.get(id), description: extract_desc(cve), published: cve.get(published), lastModified: cve.get(lastModified), cvss_score: extract_cvss(cve), cwe_ids: extract_cwes(cve) } # 这里调用预定义的入库函数示例中省略 insert_to_db(record) else: print(f请求失败: {resp.status_code}) def extract_desc(cve_obj): 从CVE对象中提取英文描述字段 descriptions cve_obj.get(descriptions, []) for desc in descriptions: if desc.get(lang) en: return desc.get(value, ) return def extract_cvss(cve_obj): 从CVE对象中提取CVSS评分 metrics cve_obj.get(metrics, {}) for key in [cvssMetricV31, cvssMetricV30, cvssMetricV2]: if key in metrics: cvss_data metrics[key][0] return cvss_data.get(cvssData, {}).get(baseScore) return None def extract_cwes(cve_obj): 从CVE对象中提取CWE编号 weaknesses cve_obj.get(weaknesses, []) return [w.get(description, [{}])[0].get(value) for w in weaknesses]这段代码演示的是从NVD增量拉取CVE记录的核心逻辑核心点在于一是用时间范围做增量更新不重复拉全量二是入库前做字段精简只保留模型训练真正需要的字段避免数据库无限膨胀三是所有异常都要有日志和告警采集任务挂了一晚上没人发现是会出大事的。6.3 数据版本管理与更新节奏做安全数据跟做软件版本一样严肃数据不是一次采集完就一劳永逸的。安全领域变化太快今天刚训练完的模型下周可能就有一个新的高危漏洞家族出现。数据要持续更新但更新不能是“随手抓一把”。我的做法是给数据集建立版本机制。每次新增或删改数据都记录版本号、变更内容、采集时间、处理脚本版本保证模型训练数据可追溯。比如“dataset_security_v3.2_20250115”含义是安全数据集第三版第二次迭代数据截至2025年1月15日。更新节奏上我一般会给不同数据源设置不同的更新频率CVE/NVD漏洞数据每日增量更新GitHub安全公告与commit数据每周全量扫描一次遇到重大安全公告触发即时增量威胁情报报告每周更新一次重大事件即时更新自研流量数据每月做一批采集季度做一次全面重新标注和质量评估。这样设置的原因是不同数据源的时效敏感度不同CVE是模型知识库的基础底座需要保持最新代码类数据变化相对集中每周扫描就够了自研数据采集成本高采集太频繁会导致存储爆炸。也要为恶性紧急事件留出“热更新通道”比如Log4j这种级别的漏洞爆发时要在24小时内完成数据采集、清洗、标注和增量训练。7. 一些实际操作后的心得体会写到最后分享几个这些年做安全数据积累下来的零散经验。第一数据获取这个环节千万不要想着一步到位。我见过很多团队花两三个月做了一整套超庞大的数据平台结果模型v0.1还没跑通平台需求就已经变了。更务实的做法是先用一条最简单的数据流跑通端到端确认模型能收敛再逐步往里面加数据源、加清洗规则。第二数据格式的设计要留有冗余。刚开始做数据表结构时我习惯把source_url、timestamp、raw_content这类字段都保留下来。当时团队有人抱怨浪费存储但后来做数据审计和溯源时这些字段帮了大忙特别是涉及数据合规和模型行为排查时。第三人工抽检比例绝对不能省。自动化清洗和标注再完善安全数据的语义复杂度过高总有规则覆盖不到的死角。我现在的标尺是代码类数据抽检10%威胁情报类数据抽检20%涉及具体业务环境的日志数据抽检30%。看着费时间其实是在给模型质量上保险这比模型训完再发现问题回头改数据划算得多。最后想说的一点是网络安全大模型的数据获取本质上是一个持续对抗的过程。你在收集数据攻击者也在试图污染数据。永远保持对数据来源的警惕心对每一条数据的“出生背景”都了然于胸这才是做安全模型数据工程最基本也最重要的素养。数据没问题了模型就成功了一大半。