NVD 现代化这个事放在 AI 背景下来看已经不是简单的“换个系统”或“加个自动化”了。NIST 这次公开征询意见核心是围绕一件事国家漏洞数据库 NVD 长期依赖人工审核面对漏洞数量快速增长已经明显吃力AI 能不能既提升处理效率又不破坏漏洞数据的可信任度。这篇文章会拆解 RFI 到底在问什么、哪些角色需要重点关注怎么准备一份能被认真对待的反馈材料以及 NVD 这套现代化思路能带给企业内部漏洞治理哪些可落地的参考。如果你是做漏洞管理、安全运营、安全研发或 AI 安全相关工作这篇值得往下看。1. 先弄清楚 NIST、NVD 和 RFI 到底在聊什么1.1 这一轮公开征询要解决的现实问题NVD 是业内使用频率极高的漏洞数据源很多漏洞管理平台、扫描器、情报服务都会拉取 NVD 的数据做关联分析。它和 CVE 的关系可以这样理解CVE 负责给漏洞分配编号和基础描述NVD 在 CVE 的基础上补充更结构化的信息比如受影响的产品版本范围、CVSS 严重性评分、CWE 弱点分类、参考链接、已知利用状态等。问题在于这些补充工作长期依赖人工。漏洞数量上涨之后人工分析的速度跟不上新增速度积压和延迟就成了老问题。如果你平时依赖 NVD 数据做漏洞筛选大概率遇到过这种情况某个漏洞的 CVE 编号早就公布了但 NVD 页面里的分析信息迟迟没有更新或者版本范围字段一直为空。这直接影响下游系统的漏洞匹配、风险评分和修复优先级。RFI 就是在这种背景下出现的。NIST 不是直接给出现成方案而是用公开征询的方式收集外部意见。它想弄清楚的是NVD 的现代化改造应该怎么做尤其在 AI 参与数据处理之后如何保持数据质量、透明度和生态兼容性。1.2 为什么 AI 会成为这次 RFI 的关键背景AI 进入漏洞管理看起来是顺理成章的事。模型可以读长文本可以抽取关键字段可以给漏洞描述做摘要可以在大量历史数据中找到相似模式。如果让模型辅助分析师完成一部分重复性工作理论上确实能缩短漏洞分析周期。但问题也恰恰在这里。模型输出不一定稳定可能提取错版本号可能编造不存在的组件可能对同一条漏洞描述给出前后不一致的结论。NVD 是公共基础设施下游有大量系统直接引用它的数据一条错误条目影响的不是单一个人而是整个生态。所以 NIST 考虑 AI 的时候不可能只看模型能力的上限更要看错误率、可校验性、审计链路和人工兜底机制。从这个角度看这次 RFI 不是在问“AI 好不好用”而是在问“AI 能不能以可靠的方式进入漏洞数据生产流程”。1.3 谁应该关注这次 RFI不同角色的关注点其实不一样。依赖 NVD 数据做漏洞管理的团队最关心的是数据结构和更新时效会不会变化如果字段调整自己的解析和关联逻辑要不要重写。做安全情报、漏洞评级和攻击面管理的团队更关心数据质量是否改善积压问题能否缓解。做 AI 安全、模型供应链安全的研究人员会关注新增漏洞形态能不能被 NVD 识别和分类。安全运营人员则关心的是AI 辅助分析之后漏洞信息什么时候能落到自己用的平台上。也就是说这不是一个只和政策研究人员相关的议题。只要你的工作流里有“拿 NVD 数据做判断”这一步这次 RFI 的方向就和你相关。2. AI 时代 NVD 现代化必须回答的几个核心问题2.1 自动化程度人工审核和模型生成怎么分工一个非常现实的判断是NVD 不可能完全靠人工也不可能完全靠模型。纯人工的瓶颈在过去几年已经很明显纯模型的风险又太大最后大概率会走分层处理模式。我理解的分层逻辑是原始漏洞描述进入系统之后先用规则和模型做预分析抽取版本、组件、厂商、参考链接等字段生成一个“待确认”版本的分析结果。然后根据漏洞的复杂度和风险等级分流低风险、结构清晰的漏洞可以走快速通道高风险、涉及多组件、描述模糊的漏洞必须人工复核。复核之后的数据才进入正式发布。这个思路里最关键的词是“待确认”。模型可以降低人工从零开始写分析的成本但发布前一定有一个验证环节。对于企业内部建设漏洞处理流程来说这个分层思想同样适用不要指望模型输出就是最终答案。2.2 新增漏洞形态AI 系统漏洞怎么分类传统漏洞体系主要覆盖软件组件、协议、硬件设备、Web 应用这些对象但 AI 系统引入之后漏洞对象出现了明显变化。提示注入、训练数据投毒、模型后门、向量数据库检索异常、Agent 调用外部工具时的权限失控这些都是过去 CWE 分类体系里覆盖不够好的方向。NVD 如果要现代化需要考虑的不是简单加几个关键词而是能不能在数据模型层描述“模型”“数据集”“推理框架”“Agent 工具”这类新资产。比如一个漏洞影响的是某个开源模型的特定版本这条信息怎么表达如果受影响对象是训练数据集CPE 匹配逻辑该怎么适配这个问题的答案会影响很多做 AI 安全产品的人。如果 NVD 的数据结构不扩展下游系统就很难用统一方式查询“哪些 AI 组件存在已知漏洞”安全团队只能靠厂商公告和公开情报手动整理。2.3 生态协作数据来源和验证闭环NVD 的数据生产不能只看 NIST 内部还要考虑数据从哪来、由谁补、怎么验证。目前 NVD 的主要数据源是 CVE 记录和厂商公开信息但 AI 时代漏洞信息可能散落在模型卡、技术报告、开源仓库 Issue、安全研究博客里。RFI 大概率会关注如何降低信息提交成本、如何让更多安全研究者和厂商参与补充、以及如何处理多方提交一致性的问题。这里有一个值得注意的点未来的漏洞数据不能只有“结论”还要有“依据”。每一条补充信息都应该能追溯到原始链接、提交者、采集时间和验证记录。也就是说NVD 现代化不只是“能不能更快”还包括“能不能说得清为什么是这个结论”。3. 参与 RFI 反馈像准备技术方案一样组织材料3.1 先从自己的业务场景出发NIST 公开征询意见时最有效的反馈不是泛泛说“AI 很重要”“数据质量很重要”而是有具体场景、具体案例和具体建议。我建议你在动笔之前先做一个动作梳理一下自己的工作流里NVD 数据到底被用在哪里、缺了什么、因为延迟或字段缺失造成了什么问题。如果你是漏洞管理平台的开发者可以写清楚当前解析 NVD 数据时遇到的字段覆盖问题。如果你是安全运营人员可以描述因为分析延迟导致漏洞处置节奏被拖慢的真实案例。如果你是做 AI 安全的研究人员可以说明现有漏洞类型体系在描述 AI 漏洞时的不足。身份不同看到的痛点不同反馈价值也不同。3.2 建议用可量化的方式描述痛点反馈材料里最忌讳的是只给结论、不给数据。不是说一定要给出非常精确的统计而是尽量用“数量、频率、时间、比例”这类指标来说明问题严重程度。比如可以这样组织组织内部每月需要处理的新增漏洞数量级依赖 NVD 字段做自动匹配的比例因为 NVD 分析延迟导致等待时间延长的漏洞占比人工分析单条漏洞平均需要多长时间对 AI 辅助结果的接受标准比如最低准确率要求。如果你有实际统计结果就直接写。如果没有精确统计就写清楚观察到的趋势。能用数字回答的问题尽量不要用形容词。3.3 注意反馈形式和后续动作NIST 的 RFI 一般会通过联邦公报或官网发布提交入口和截止时间需要以公开页面为准。反馈材料建议包含几个部分提交者身份说明、当前遇到的主要问题、建议的改进方向、预期收益、可能的风险和顾虑。如果你代表企业提交最好先走一遍内部合规审核确认哪些信息可以披露。如果以个人身份提交也建议保留草稿和提交确认记录。另一个容易被忽略的点是不要只写“应该做 A”还要写“做 A 的时候要注意避免 B”这样反馈的可读性和工程参考价值会高很多。4. NVD 现代化思路能平移给企业内部漏洞治理4.1 从 CVE 到内部漏洞库哪些字段是必备的NVD 现代化讨论的核心问题之一是数据结构。这个思路可以直接迁移到企业内部漏洞库建设上。不管外部数据源怎么变内部漏洞库必须有自己的稳定核心字段。字段含义为什么重要漏洞编号主键 ID关联外部情报避免重复记录受影响资产组件名、版本范围后续匹配机器和业务系统严重性评分CVSS 或自定义等级判断处理优先级漏洞描述原始文本分析基础保留语义信息弱点类型CWE 映射支持按类型聚合统计参考链接原始来源可追溯便于复查分析状态待分析、已确认、误报控制流程推进模型辅助信息模型输出、置信度、版本审计 AI 参与过程有一个经验是很多团队在做内部漏洞库时只关心“能不能跑通”忽略了字段的长期稳定性。等到要做趋势分析、合规报表、跨系统关联时才发现关键字段要么缺失要么格式混乱。所以从一开始就按“主键清晰、来源可溯、状态可查”来设计后续会省非常多事。4.2 AI 辅助分析在漏洞管理中的应用边界AI 辅助漏洞管理可以做和不应该做的界限需要分清楚。可以做的包括从长文本公告中抽取组件和版本、把非结构化描述转成结构化字段、对历史漏洞做相似度聚类、生成初始评估摘要供分析师参考。这些任务的特点是允许一定误差有人工复核环节输出结果有原始文本对照。不要做的包括让模型自动发布最终结论、让模型直接对接修复工单系统并触发变更、用不可追溯的模型输出替换原始数据。原因不复杂一旦模型出错下游无法快速定位问题会对生产环境造成实际影响。如果团队刚起步我建议选一个低风险场景验证比如用模型辅助抽取受影响版本再由人工确认跑一段时间看准确率和覆盖率再决定是否扩展到更大范围。4.3 小团队先从哪些环节入手小团队资源有限不适合一上来就搭完整平台。可以先把“最耗时”的环节找出来。通常最耗时的是收集信息、整理字段和初筛关联这部分适合用脚本和模型辅助。我建议从最近 100 条真实漏洞历史数据开始人工标注出标准答案再用模型跑一遍对比差异。关注三个指标字段抽取准确率、版本信息准确率、错误输出比例。准确率没有达到验收阈值之前不要直接放到生产流程里。注意这里不要一上来就追求全自动处理先用小样验证输入、输出和复核流程确认这些环节都稳了再考虑扩大任务范围。5. 实战中最容易踩的坑和排查顺序5.1 用 AI 提取漏洞信息时结果不稳定怎么办很多人遇到模型输出不稳定第一反应是换模型、调参数、改提示词。但在真实工程场景里最值得优先排查的往往是输入格式和上下文的规范化。不同数据源的漏洞描述格式差异很大。NVD 的 JSON 数据相对标准字段边界清楚但厂商安全公告、GitHub Issue、邮件列表里的描述就自由得多一个版本号可能出现在标题里也可能藏在正文中间还可能带着各种通配符和限定词。如果输入文本没有做预处理模型很容易被无关信息干扰。排查顺序可以先这样先确认输入文本是否完整有没有截断或编码问题再看抽出来的版本号、组件名、严重性等级是否在原始文本里有明确依据然后检查模型是稳定地出错还是随机出错最后再考虑调提示词或换模型。很多时候出现“同一个描述跑两遍结果不一样”的情况不是模型能力问题而是输入预处理、随机参数或者输出解析逻辑没统一。5.2 自动化带来的误报和漏报如何平衡AI 辅助抽取漏洞信息时最容易出问题的是版本号。版本号看起来简单实际上有“等于某个版本”“小于某个版本”“大于等于某个版本”这类范围语义还可能存在大小写、前缀、后缀和通配符问题。从一个工程的视角来看比较好的做法是把版本匹配从纯抽取改成“抽取加规则校验”。先用模型做初步抽取再用规则把明显的格式错误过滤掉。比如某个字段要求必须是“厂商-组件-版本”三段式结构如果模型输出不符合结构就标记为待人工确认不直接进库。这里需要设定一个边界先追求高准确率再追求覆盖率。优先保证“进去的信息是对的”不要为了追求数量把大量低质量结果推进流程。5.3 数据可追溯性从结论反推来源在大规模使用 AI 辅助处理之后最容易忽略的是数据可追溯性。每一条漏洞分析记录都应该是可以反推的最终结论是怎么来的原始依据是什么哪个环节生成了这个结果人工做了哪些修改。这个要求听起来像“流程规范”实际上很实用。当外界质疑某条数据有误时只有完整链路才能快速定位问题。如果只有模型输出而没有原始文本、没有中间结果、没有处理脚本版本排查会非常困难。比较稳妥的做法是在处理流程中保留一条 JSON 记录包含原始输入、模型输出、规则校验结果、人工修改内容和最终发布状态。这样即使后面发现数据有问题也能定位到具体环节。注意AI 辅助数据处理的第一原则不是“生成得快”而是“出问题时能找到原因”。链路清晰比模型更复杂更重要。6. 留给从业者的几点建议NVD 现代化不是一个短期项目它涉及数据结构、自动审核、模型引入、生态协作和下游系统适配要调整的环节非常多。对于普通从业者来说不一定要深度参与 RFI 反馈但一定要关注后续的方向变化因为 NVD 的数据格式和更新机制一旦变化会直接影响很多工具的解析逻辑。如果企业正在做内部漏洞治理可以借这次讨论重新审视自己的数据链路。重点关注三件事字段是否标准化、增量数据是否可追溯、AI 辅助结果是否有明确的人工复核环节。这三件事做扎实了无论外部数据源怎么调整内部都能快速适配。参与 RFI 反馈时带上你自己的场景和案例。NIST 需要的外部输入不是简单表态而是真正来自一线的使用反馈。你自己遇到的延迟、字段缺失、格式不一致等问题只要写清楚过程就是有价值的输入。我个人更建议先把“单条漏洞处理流程”跑稳再考虑批量化和自动化。这条经验不仅适用于 NVD 现代化讨论也适用于企业内部任何一个漏洞数据管道。真正难的不是让模型写出结论而是让结论能被验证、被审计、被放心使用。