企业官网建设流程全解析

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 现代化讨论的核心问题之一是数据结构。这个思路可以直接迁移到企业内部漏洞库建设上。不管外部数据源怎么变，内部漏洞库必须有自己的稳定核心字段。

有一个经验是：很多团队在做内部漏洞库时，只关心“能不能跑通”，忽略了字段的长期稳定性。等到要做趋势分析、合规报表、跨系统关联时，才发现关键字段要么缺失要么格式混乱。所以从一开始就按“主键清晰、来源可溯、状态可查”来设计，后续会省非常多事。

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 现代化讨论，也适用于企业内部任何一个漏洞数据管道。真正难的不是让模型写出结论，而是让结论能被验证、被审计、被放心使用。