做漏洞管理的同学最近一两年应该都有同一个感受NVD 的更新越来越慢很多新 CVE 发布了很久却一直没有 CVSS 分数也没有 CPE 匹配扫描器报出来的漏洞无法自动确认影响面最后不得不回到人工排查。这看起来只是某个数据库的效率问题但它影响的是整个安全自动化链条。NVD 不只是“美国政府的漏洞通告”它实际上是全球安全工具链最底层的数据供给方。从漏洞扫描、资产测绘、SRC 运营到供应链风险管理几乎都要先消费 NVD 的数据。这个环节一旦堵住下游再智能也没用。所以当 NIST 围绕 NVD 现代化发出 RFI并把 AI 放到讨论中心位置时它不只是在问“要不要用 AI”而是在问一个更实际的问题怎么把漏洞数据从“人肉分析”升级为“机器自动分析为主、人工审核兜底”的生产流水线。这篇文章会从 NVD 为什么会走到这一步讲起拆解 NIST RFI 关心的方向然后给出一套 AI 辅助 CVE 分析的落地思路和最小可运行代码。无论你是做安全工作、运维、研发还是数据工程看完应该能判断NVD 的 AI 化改造为什么一定会发生技术难点在哪里对你的工具链意味着什么以及你可以怎么提前布局。1. 为什么 NVD 突然成为安全行业的焦点NVD 全称 National Vulnerability Database由美国国家标准与技术研究院NIST运营是 CVE 数据最重要的“分析增强层”。CVE 体系只负责给漏洞分配 ID 和保存基础描述真正让一个漏洞可以被自动化工具使用需要 NVD 补充三类关键信息CVSS 评分衡量漏洞严重程度。CPE 匹配把漏洞影响范围映射到厂商、产品、版本。CWE 分类给漏洞定性比如是 SQL 注入还是缓冲区溢出。这三个字段恰恰是最难自动化的部分。CVE 描述是自然语言写描述的作者可能是安全研究员、厂商也可能是自动化工具格式千差万别CPE 需要把“log4j-core 2.14.1 及之前版本”这种描述映射成结构化的cpe:2.3:a:apache:log4j:2.14.1一个版本写错就可能导致漏报或误报CVSS 评分则要求判断攻击路径、利用复杂度、影响范围这本身就接近一次简化的威胁建模。过去 NVD 靠人工完成这些工作质量没问题但产量跟不上。近几年 CVE 申请量持续增长每年新增数万个而 NVD 的分析能力并没有同步提升。公开的报道多次提到 NVD 存在大量积压CVE 发布后迟迟拿不到 CVSS 和 CPE包括 CISA 在内的多个机构也公开表达过关切。下游生态很快感受到了连锁反应扫描器无法自动评估风险漏洞管理平台只能显示“未评分”。供应链安全团队无法快速判断某个开源组件是否受影响。EPSS、KEV 这类依赖基础数据的预测模型输入质量变差输出自然也不可靠。当数据供给出现系统性延迟安全行业就会意识到NVD 不是一个“公共服务网站”它是整个漏洞管理链条的“上游水库”。水库水位下降下游所有农田都会受影响。所以 NIST 围绕 NVD 现代化发出 RFI本质上是承认现有模式不可持续并且希望借助社区和 AI 的力量重新设计漏洞数据生产体系。这也是为什么这次 RFI 的关注度远超普通政府采购文件。2. NVD 的核心概念与 AI 介入点要把“NVD 现代化”讲清楚先要理解 NVD 里的几个核心数据项。下面这张表把概念、人工耗时点和 AI 切入点放在一起看数据项作用人工耗时点AI 切入点CVE ID 与描述漏洞的基础身份提炼技术要点摘要、实体抽取CWE 分类漏洞类型归类判断边界模糊的攻击模式语义分类CPE 匹配影响产品与版本从描述匹配厂商、产品、版本号实体识别 规则校验CVSS 评分严重性评估判断攻击路径和影响范围结构化抽取 推理参考链接公告、补丁、PoC去重、验证来源可信度链接分类、关联分析这里最容易误解的一点是很多人以为 AI 会直接替代 NVD 分析师给出最终结论。实际上NVD 里最有价值、也最难做的任务是把非结构化文本转成结构化字段。CVE 描述是一条自然语言文本它不会告诉你“这里应该填一个 CPE 2.3 版本字符串”你需要从“Apache Log4j2 versions 2.0-beta9 through 2.15.0”这种句子里定位产品名、版本区间、版本号再生成一条甚至多条 CPE 匹配记录。再例如 CWE 分类。一个漏洞可能同时符合“输入验证不当”和“资源管理错误”人工分类时会考虑攻击效果和常见分类习惯纯规则难以覆盖。而 LLM 在语义理解上的优势正好用于这类任务只需要提供足够清晰的分类标准和示例。还有一个关键概念是历史包袱。NVD 里已经存在几十万条历史数据这些数据不可能全部重新人工标注。现代化的一个重要环节就是用 AI 对这些历史条目做“回填”或“修正”比如重新计算 CPE、补充缺失的 CWE。这里对模型的要求不是“创新”而是“稳定”和“可批量执行”。AI 在 NVD 现代化的第一个价值不是做花哨的漏洞预测而是把海量文本转成机器可读、下游可直接消费的结构化数据。3. NIST RFI 想听什么现代化的方向拆解RFI 全称 Request for Information可以理解为“需求信息征集”。它不是采购招标不是马上宣布用哪个厂商的方案而是 NIST 在正式制定方案之前向行业、科研机构和公众收集反馈你们认为 NVD 的问题在哪里应该怎么改AI 应该以什么角色介入。从公开信息看这次 RFI 涉及的方向可以大致拆成六类。3.1 自动化与 AI 的应用边界最核心的问题是用 AI 做自动化分析。NIST 需要知道目前哪些环节适合自动做哪些环节必须保留人工比如 CPE 生成和 CVSS 评分能不能做到“AI 初筛 人工复核”当模型给出某个漏洞属于CWE-89时置信度低于阈值怎么办这类问题决定了 AI 在 NVD 中是“辅助工具”还是“生产主力”。3.2 数据模型与开放格式NVD 数据是 JSON 格式但字段划分、嵌套关系、版本兼容性一直存在历史包袱。RFI 大概率会关注是否需要重新设计数据模型如何让数据更容易被机器消费比如是否引入 SBOM、VEX 这类供应链安全标准让 CPE 匹配结果更贴近现代软件组合分析的需求。3.3 社区参与与开放治理NVD 目前是 NIST 主导的集中式运营模式积压问题暴露了单点运营的脆弱性。RFI 很可能希望了解是否允许第三方贡献分析结果能否建立类似开源社区的审核机制社区和官方如何分工这里需要解决的是“信任”问题社区贡献不能被随便合入必须有评审和质量门槛。3.4 质量评估与可信机制如果 AI 参与分析就必须有一套质量度量体系。RFI 关注的可能包括如何抽样检查 AI 的分析结果如何跟踪人工纠错记录并反馈到模型迭代里如何避免模型在不同时段、不同数据上表现漂移没有评估体系AI 化只会把人工瓶颈变成黑盒风险。3.5 资金与持续运营模式NVD 的运营依赖公共资金而漏洞数量只增不减。RFI 也想了解除了政府投入是否可以让商业公司参与如果数据免费开放如何避免“用公共数据喂模型、再反过来卖分析服务”的利益冲突这个问题的最终结果会影响下游工具链的成本结构。3.6 过渡期的兼容性很多企业已经在基于 NVD 的旧 API 构建系统。现代化不能“停服式改造”必须考虑兼容策略旧的 JSON 数据还保留多久API 版本切换是否有缓冲期历史数据是否重新处理这些看似不性感的问题恰恰是工程落地的难点。从技术视角看这六类问题的共同点是把 NVD 从一个“政府维护的数据库”重新定义为一个“现代数据产品”。RFI 的结果不一定马上变成代码但它会给出 NVD 未来 5 年发展的底层框架直接影响所有下游安全厂商和开发者。4. AI 驱动 NVD 现代化的可行技术路径如果 NVD 要真正走向 AI 化不能把一个模型扔到历史数据上就期望得到好结果。从工程实践看更可能是一条混合流水线下面这条路径具有代表性。4.1 数据采集与清洗层NVD 的数据来源包括 CVE 描述、参考链接、厂商公告、CNA 提交内容甚至社交媒体上的漏洞报告。第一步不是建模而是设计一套能持续抓取、解析、去重、存储这些数据的管道。这个环节的技术难度不高但决定了后续 AI 的输入质量。很多团队做漏洞 AI 项目失败不是因为模型不行而是因为数据管道太乱。4.2 规则与实体识别兜底层在引入 LLM 之前可以先做一轮规则处理从 CVE 描述中提取版本号、厂商名、产品名、漏洞类型关键词。经典做法是用正则表达式匹配版本区间用命名实体识别识别厂商和产品。规则层速度快、结果稳定但召回率有限。它的意义不是替代 AI而是降低 AI 的输入复杂度让模型只处理规则层无法判断的模糊文本。4.3 LLM 结构化抽取层这是 AI 介入最深的一层。通过 Few-shot 提示或结构化输出约束让 LLM 把 CVE 描述转成 JSON Schema 指定的字段包括漏洞类型、受影响产品、攻击向量、所需权限等。现代 LLM 一般支持 JSON Mode可以强制模型按照约定 Schema 输出极大降低解析成本。这一层真正要解决的是“输出质量”问题。模型可能把版本号解释错误可能把产品名和厂商名搞反也可能把攻击复杂度推断成过高的等级。所以不能天真地直接写llm.invoke(prompt)就完事。更稳妥的做法是让模型在输出每个字段时附带置信度或者用多个模型投票再设定阈值进入人工审核。4.4 人工审核与反馈闭环NVD 是权威数据库输出必须可靠。AI 化落地时最优结构不是“AI 替代人”而是“AI 做初稿人做终审”。审核人员不是从零开始打标签而是在 AI 结果上做修改每一个修改都进入反馈数据集。这些反馈数据可以定期用于微调模型或者用于改进提示词。时间越久AI 的准确率越高人工介入比例越低。4.5 回测与漂移监控模型上线后不是一劳永逸。漏洞描述的语言习惯会变新的攻击模式会出现厂商产品命名也会调整。必须建立持续回测机制每个月从历史样本里抽一批用当前版本重新分析和人工标注结果对比评估准确率是否下降。同时监控输入分布的漂移比如某个厂商的新产品命名方式开始出现识别率就明显下降这时需要补充示例数据。用一句话概括这套架构规则层保证稳定LLM 层解决语义理解人工层保证权威性反馈层驱动持续改进。这个思路不仅适用于 NVD也适用于任何需要规模化处理非结构化数据的领域比如安全告警分诊、威胁情报抽取、合规文档分析。5. 一个最小可用的 CVE 信息抽取示例下面我们用一套最小代码演示“NVD API 拉取数据 LLM 结构化抽取 批量处理”的核心流程。这个示例不需要修改任何系统配置只需要一个 OpenAI 兼容的接口本地模型或云端 API 均可。5.1 从 NVD API 拉取 CVE 记录NVD 提供公开的 REST API可以直接使用requests拉取。这里以CVE-2021-44228为例即 Log4Shell历史上影响面最大的漏洞之一。# 文件路径nvd_fetch.py import requests def fetch_cve(cve_id: str, api_key: str ): 从 NVD API 2.0 拉取单个 CVE 的原始 JSON 数据。 api_key 可以留空但填写后配额更高。 url https://services.nvd.nist.gov/rest/json/cves/2.0 params {cveId: cve_id} headers {} if api_key: headers[apiKey] api_key resp requests.get(url, paramsparams, headersheaders, timeout30) resp.raise_for_status() return resp.json() if __name__ __main__: data fetch_cve(CVE-2021-44228) cve_item data[vulnerabilities][0][cve] print(cve_item[id]) print(cve_item[descriptions][0][value])NVD API 有速率限制免费apiKey可以显著提高每日配额。具体配额数字以 NIST 官方文档为准生产环境使用前一定要先看限流说明。5.2 用 LLM 抽取结构化字段拿到 CVE 描述后接下来让模型输出结构化 JSON。这里使用requests直接调用 OpenAI 兼容接口这样本地模型和云端模型都能接入。# 文件路径llm_extract.py import json import requests EXTRACT_PROMPT 你是资深漏洞分析专家。请基于 CVE 描述输出一个 JSON 对象。 字段说明 - vulnerability_type: 漏洞类型取值参考 CWE 类别用英文短横线命名。 - affected_product: 受影响产品名纯文本即可。 - vendor: 厂商名。 - version_conditions: 受影响版本的条件用自然语言描述保留原文细节。 - attack_vector: 攻击向量只允许取 NETWORK / ADJACENT / LOCAL / PHYSICAL。 - privileges_required: 所需权限只允许取 NONE / LOW / HIGH。 - confidence: 你对以上判断的置信度0 到 1 之间。 只输出 JSON不要输出解释。 CVE 描述 {description} def extract_cve_info(description: str, api_url: str, api_key: str, model: str): payload { model: model, messages: [ {role: system, content: 你是一个严格按 JSON 输出的安全分析助手。}, {role: user, content: EXTRACT_PROMPT.format(descriptiondescription)} ], temperature: 0, response_format: {type: json_object}, } headers {Authorization: fBearer {api_key}} resp requests.post( f{api_url}/chat/completions, headersheaders, jsonpayload, timeout60, ) resp.raise_for_status() raw resp.json()[choices][0][message][content] return json.loads(raw) if __name__ __main__: # 支持 OpenAI 兼容协议的接口云端或本地均可 result extract_cve_info( descriptionApache Log4j2 versions 2.0-beta9 through 2.15.0 are vulnerable to a JNDI injection attack. An attacker who can control log messages can execute arbitrary code., api_urlhttps://api.openai.com/v1, api_keyYOUR_API_KEY, modelgpt-4o-mini, ) print(json.dumps(result, ensure_asciiFalse, indent2))这段代码的关键点有三个temperature0降低随机性漏洞分析场景不能“自由发挥”。response_format要求 JSON 输出避免解析大段 Markdown。confidence字段给人工审核提供判断依据置信度低于阈值时应进入人工队列。如果你没有云端 API key可以在本地用 Ollama 起一个模型把api_url改成http://localhost:11434/v1model改成你本地拉的模型名例如qwen2.5:7b。这种方式的数据不出本地适合处理敏感内部数据。5.3 批量处理与人工审核保存单个 CVE 抽取没有工程意义。实际场景是处理一个 CVE 列表生成结果后落盘方便人工审核。下面是一个带审核状态的批量处理骨架。# 文件路径batch_process.py import json import csv from pathlib import Path from nvd_fetch import fetch_cve from llm_extract import extract_cve_info def process_cve_list(cve_list, output_path: str, **llm_kwargs): rows [] for cve_id in cve_list: try: raw fetch_cve(cve_id, api_keyllm_kwargs.get(nvd_api_key, )) description raw[vulnerabilities][0][cve][descriptions][0][value] extracted extract_cve_info(description, **llm_kwargs) rows.append({ cve_id: cve_id, description: description, vulnerability_type: extracted[vulnerability_type], affected_product: extracted[affected_product], vendor: extracted[vendor], version_conditions: extracted[version_conditions], attack_vector: extracted[attack_vector], privileges_required: extracted[privileges_required], confidence: extracted[confidence], review_status: pending, # pending / approved / rejected }) except Exception as e: rows.append({ cve_id: cve_id, error: str(e), review_status: error, }) Path(output_path).write_text( json.dumps(rows, ensure_asciiFalse, indent2), encodingutf-8, ) if __name__ __main__: process_cve_list( [CVE-2021-44228, CVE-2022-22965], output_pathcve_review_queue.json, api_urlhttp://localhost:11434/v1, api_keynot-needed, modelqwen2.5:7b, )这里的review_status是核心。所有 AI 生成的结果都需要人工确认确认后的数据才能进入自己的知识库。人工每改一次字段就是一条反馈样本后续可以用来做评测或微调。6. 运行结果与效果验证运行batch_process.py后如果没有报错会在当前目录生成cve_review_queue.json内容大致如下{ cve_id: CVE-2021-44228, vulnerability_type: jndi-injection, affected_product: Log4j2, vendor: Apache, version_conditions: 2.0-beta9 through 2.15.0, attack_vector: NETWORK, privileges_required: NONE, confidence: 0.95, review_status: pending }请注意不同模型输出不完全一样这属于正常现象重点是字段结构能通过 JSON 解析。判断一套 AI 抽取管线是否跑通可以从四个维度验证字段完整性JSON 是否包含所有定义字段有无缺失。关键字段正确性vendor、affected_product、version_conditions是否和描述原文对得上。置信度分布如果大量样本的confidence都低于 0.6说明提示词或模型需要调整。人工抽检随机抽 10 条和人工标注结果比对准确率不到预期就说明生产环境还不能直接用。如果运行失败先按下面顺序排查网络错误确认能访问 NVD API 和模型接口地址。限流错误API 返回 403 或 429检查是否加了apiKey或者降低请求频率。JSON 解析错误模型返回了非 JSON 内容确认接口是否真正支持response_format。字段不含description检查 CVE 数据是否取到了正确的descriptions[0]。这套最小方案不适合直接上线但它展示了核心链路拉取原文、生成结构化结果、进入人工审核队列。理解这一条链路后NVD 的 AI 现代化方向就变得具体了。7. 常见问题与 AI 落地的坑AI 做漏洞分析表面上是“读文本、出 JSON”实际落地时有很多细节问题。下面按问题、原因、排查、方案整理问题现象可能原因排查方式解决方案模型把版本号解释错描述中的版本区间歧义对比原文和输出版本条件在提示词中强调“保留原文版本条件不要推算”CPE 匹配漏掉某个产品产品名与厂商名识别错误抽检vendor和affected_product增加厂商词表规则层先纠正实体LLM 返回非 JSON接口不支持结构化输出检查响应原始内容换用支持 JSON Mode 的接口或增加解析重试同一 CVE 重复抽取出不同结果temperature 过高固定temperature0多次运行取多数结果旧漏洞数据抽取出当前知识模型训练语料包含“未来信息”检查version_conditions是否有后来版本限定仅从描述文本抽取不让模型自行补知识大量 CVE 处理时触达速率限制并发请求太高查看 HTTP 状态码增加限速和退避重试人工审核工作量不减反增AI 置信度阈值设置过低分析置信度分布提高置信度阈值或补充示例这里特别要强调两个安全边界问题。第一模型幻觉在漏洞数据场景不是“开个玩笑”而是可能导致严重误判。一个“受影响版本”的幻觉可能让企业漏掉真正的攻击面或者错误地给不存在的漏洞打补丁。所以 AI 结果必须保留原文引用让人工能快速对照。第二数据来源合规。NVD 数据公开可用但 CVE 描述可能来自不同 CNA不同来源的许可证和转载要求不同。如果把 NVD 数据作为商业产品的一部分建议先核对 NVD 的授权条款和 CVE 内容的版权边界避免在工具层面无意超过授权范围。如果团队资源有限最稳妥的落地策略是“小范围试点”先选 100 条历史 CVE 做测试集人工标注后跑通抽取管线再评估准确率。不要一上来就追求处理全量数据因为全量处理只是数据处理问题准确率才是业务问题。8. 给安全团队和开发者的最佳实践无论 NVD 的 RFI 最终结论如何目前已经可以确定的是漏洞数据的人工分析模式一定会被 AI 改造下游工具链也一定会跟着变。对团队和个人来说有几件事值得提前做。8.1 不要把 NVD 当作唯一数据源NVD 的积压问题已经证明依赖单一数据源会让整个安全体系变得脆弱。建议同时订阅 CISA KEV已知被利用漏洞目录、OSV、GitHub Advisory并且保留一份本地缓存。多个数据源交叉校验可以显著降低某个源延迟带来的风险。EPSS 也值得接入它和 CVSS 是不同维度的判断一个看严重性一个看被利用可能性。8.2 构建自己的数据管道而不是手动下载很多团队还在用“每周手动下载一次 NVD JSON”的方式维护数据这在旧时代可用现在明显不够。应该搭建一个定时增量更新任务每天读取 NVD API 或官方数据馈送记录增量在本地库中维护历史版本。这样即使 NVD API 发生变化也可以快速迁移。8.3 AI 结果必须带置信度和原文引用如果你在自己的工具链里引入 AI 分析一定要让模型的输出附带两样东西置信度和原文引用。没有置信度就无法做自动分流没有原文引用就无法快速回溯错误。这是 AI 辅助漏洞分析区别于普通文本摘要的关键要求。8.4 人工审核不是瓶颈而是数据资产很多人把人工审核当成“不得不做”的成本但换个角度看每一次人工修改都是微调数据集的样本。建议团队把人工审核记录保存下来统一格式定期用于模型评测。时间一长你在漏洞分析场景会积累出别人没有的高质量评测集这是最硬的资产。8.5 关注标准化进展但要控制升级节奏SBOM、VEX、CVE JSON 5.0、CPE 2.3 等标准都在演进。NVD 现代化过程中很可能调整数据格式和 API 版本。建议给自己的消费端做一个轻量抽象层把 NVD 的字段映射集中在一个模块避免上游改格式时全链路跟着改。这是所有第三方数据依赖场景的通用工程原则。8.6 安全与合规边界必须前置涉及漏洞数据时合规风险不可忽略。获取公开漏洞数据要遵守对方 API 规则和许可证使用 AI 模型处理内部漏洞库时要确认数据是否允许发送到外部接口在团队协作中分配 API key 时遵循最小权限原则。如果数据敏感优先部署本地模型数据不出内网。这些不是“额外成本”而是生产环境的基本要求。9. 总结与后续学习方向NVD 的 AI 现代化表面上是一个政府数据库的技术升级实际上是在重新定义整个安全行业获取漏洞数据的方式。过去我们默认 NVD 的数据是“人工审过的权威数据”未来可能要接受一种新形态AI 生成的初稿 专家审核的结果质量由流程和评估体系保证而不是单个人工的“权威性”。这个转变对所有安全工具的架构设计都有直接影响。如果你希望跟着这次现代化趋势做技术储备有几条线索值得持续跟踪漏洞优先级技术研究 EPSS、CVSS v4、KEV 的组合判断方式理解数据评分如何影响决策。结构化抽取工程深入 LLM 的 JSON Mode、函数调用、Few-shot 和微调把通用模型变成安全分析专用模型。供应链数据治理学习 SBOM、VEX、CPE 的规范和互操作这是 NVD 数据消费端最可能变化的领域。数据管道稳定性实践增量更新、幂等消费、字段兼容映射应对上游格式变动。最后提醒一点RFI 的结果还没有落地NVD 的具体改造方案存在不确定性。不要基于猜测调整生产系统更不要贸然把关键流程寄托在某个未定方案上。建议你现在就做的是把上面的最小示例跑通一遍理解 AI 漏洞分析链路的能力和局限。等 NVD 现代化方案正式推出时你已经有能力判断它到底是“换皮”还是“换引擎”也知道自己的系统应该怎么接。这才是对技术变化最靠谱的准备。
