从漏洞线索到修复验证：安全模型训练数据如何留证

安全任务的数据集经常被做成一问一答：输入是代码，输出是“存在漏洞”或“建议升级”。这种格式看起来整齐，却可能丢掉最重要的信息：模型当时看到了什么、结论依赖什么、谁确认过，以及修复后到底验证了哪一个实例。

OpenAI披露的NASK合作案例提供了一个很好的数据工程背景。CERT Polska借助模型在MikroTik RouterOS中发现6个漏洞，厂商发布修复后，CERT Polska又确认修复能够阻止观察到的攻击。对训练团队真正需要保存的是从线索到确认的证据链，而不只是一句“AI发现漏洞”。

一条样本至少要有四层记录

第一层是任务上下文：目标是什么、是否有授权、允许使用哪些工具、何时必须停止。第二层是原始材料：代码版本、配置、日志、公告和采集时间。第三层是教师输出：模型版本、提示模板、工具调用、可见结果和失败状态。第四层是核验记录：谁复现了问题、依据在哪里、影响结论是否被修改、修复后如何复测。

这四层不能被拼成一段“最终答案”。最终答案只适合阅读，不能替代可追溯的实验记录。若模型输出“未认证远程控制”，但原始材料只有一次进程崩溃，那么数据标签必须保留这个证据缺口，而不是为了让答案完整而补齐中间推理。

记录对象	建议保留的字段	解决的问题
授权范围	目标、允许动作、禁止动作、停止条件	防止训练出越权行为
原始材料	来源、版本、时间、摘要校验值	确认模型当时看到了什么
生成过程	模型标识、提示、工具、返回状态	区分模型贡献与人工补充
验证过程	复现条件、观察结果、核验人、修复状态	防止把猜测当事实
数据版本	纳入理由、排除原因、转换规则	支持回滚和重建

证据不足也要成为训练目标

假设一条输入只有“设备运行RouterOS，是否安全”。一个可靠助手不应该直接回答安全或不安全，而应要求具体版本、配置、暴露面和补丁来源。把这种追问标记成“信息不足处理”比强行生成一个结论更有价值。

同样，模型看到一个公告中提到“厂商已经修复”，也不能据此推断所有用户都已经完成更新。上游修复、发行版回移补丁、云平台部署和实际运行实例是不同层次。数据集应把这些状态拆开，让学生模型学会条件判断。

在147AI等统一API接入环境中做教师调用时，可以把请求、返回状态和消耗记录与样本编号关联，便于比较不同模型的输出。统一记录只解决追踪问题，不能代替授权审查、数据脱敏和人工核验。

不要只保留成功答案

训练库若只留下最后那版漂亮报告，模型会学到一种危险习惯：无论证据是否充分，都要给出确定结论。应当保留被退回的线索、复现失败、环境不匹配和修复后仍未验证的样本，并明确它们的状态。

失败记录不一定原样作为正向示范。可以把它改造成纠错样本：指出“把崩溃写成远程执行”的原因，要求模型补充缺失条件；或者要求它把“补丁已发布”改写成“需要确认运行实例”。关键是保留错误发生的位置和正确的后续动作。

还要避免同一个漏洞的多篇转载同时进入训练和测试。应按漏洞、项目或缺陷家族分组，再做数据划分。否则学生模型可能只是记住了公开结论，却被包装成具备泛化能力。

脱敏要保护关系而不只是删字符串

日志中的API Key、内部域名、用户请求和资产标识需要在进入教师服务前处理。简单把所有路径换成同一个占位符，可能破坏样本之间的关系；只删除明显的密钥，也可能遗漏组合信息。脱敏后要再次检查任务是否仍可成立，并记录规则版本。

公开漏洞报告也不能自动视为可任意训练的素材。来源许可、服务条款和组织内部授权应分开确认。尚未核实的内容可以放在候选区，不能无标记地进入生产训练集。

训练数据的验收问题

交付前可以抽查五个问题：这条结论的证据在哪里？模型是否越过了授权范围？修复状态是否与实际实例对应？同源材料是否被错误地分到训练和测试两边？未来能否找到受影响的样本批次？

回答不了其中任何一个问题，说明这只能算一段无法追溯的文字，尚未达到可复用安全训练样本的要求。安全能力的训练不应只教模型“怎么说”，还要教它在什么证据下可以说、什么时候必须停下来。

结语

一次漏洞发现可以成为重要的教师材料，但它不是现成的学生能力证明。只有把授权、原始材料、模型条件、人工核验和修复复测完整留下，团队才有可能判断训练迁移了什么，也才有机会在新漏洞、新版本和信息不全的情况下发现模型仍然会错在哪里。