随着 AI 推动漏洞增长，NIST 优先处理高风险漏洞

NIST 在调整软件漏洞审查方式后登上了 Google News，尽管其处理的记录数量比以往任何时候都多。该机构表示，2020 年至 2025 年间，CVE 提交量增长了 263%。人工智能如今处于这一压力的两端：它帮助生成和检查更多代码，同时 NIST 正在探索利用自动化技术管理随之产生的漏洞数据。

这正是该事件背后的核心反转。更快的 AI 辅助开发扩大了需要审查的软件规模。AI 驱动的安全工具也能更快发现弱点，从而产生大量需要人工验证、排序和修复的报告。

NIST 无法通过同等对待每一项报告的缺陷来解决这个问题。其国家漏洞数据库，即 NVD，必须区分紧急风险暴露与低影响噪声。因此，该机构已从全面补充信息转向基于风险的优先级排序，同时开发更多自动化工作流。

这一变化的影响远不止一个联邦数据库。安全扫描器、资产平台、政府团队、保险公司和软件供应商都依赖 NVD 数据。即使原始 CVE 记录仍可获取，信息补充的任何延迟或减少都可能将不确定性传递至下游。

Google News 的读者或许会看到一个颇具吸引力的答案：用 AI 管理由 AI 驱动的漏洞海啸。但现实更为复杂。自动化分流可以提升处理能力，却也可能规模化放大薄弱证据、错误分类和虚假的信心。

NIST 调整了哪些漏洞会获得即时关注

NIST 已不再将即时补充每一条 CVE 信息视为可持续的运营模式。

通用漏洞与暴露记录，即 CVE，为公开披露的安全缺陷提供标准标识符。NVD 信息补充则会增加帮助防御者解读该记录的信息，其中可能包括严重程度、受影响产品、弱点类别和配置数据。

2026 年 4 月 15 日，NIST 宣布为 NVD 采用基于风险的运营模式。该机构表示，所有提交的 CVE 仍会出现在数据库中，但只有符合既定标准的记录会获得即时信息补充。

第一优先级涵盖网络安全与基础设施安全局的已知已利用漏洞目录中的漏洞。该目录追踪有现实世界利用证据的缺陷。NIST 的目标是在一个工作日内完成这些记录的信息补充。

第二优先级涵盖联邦政府使用的软件。第三优先级涵盖与第 14028 号行政命令相关定义下的关键软件。其他 CVE 将进入不立即补充信息的最低优先级类别。

这不只是队列管理的调整。NIST 此前的目标是分析每一条 CVE，并添加其自身的支持数据。新模式承认，全面且快速的信息补充已无法匹配不断涌入的报告规模。

NIST 还调整了其严重程度评分方法。当 CVE 编号机构已经提供评分时，NIST 通常不会再另行创建独立评分。CVE 编号机构是获授权分配标识符并发布记录的组织。

该机构将 2026 年 3 月 1 日前发布的积压记录归入“Not Scheduled”类别。已知已利用漏洞不受这一积压处理方式影响。如果用户认为较低优先级记录值得关注，可以请求补充信息。

NIST 的 NVD 运营更新说明了这一决定背后的规模。2020 年至 2025 年间，CVE 提交量增长了 263%。2026 年第一季度的提交量比 2025 年同期高出近三分之一。

据 NIST 称，该机构在 2025 年补充了近 42,000 条 CVE 信息，比此前任何一年都多 45%。然而，这一创纪录的产出仍未能跟上提交量的增长。

这些数字削弱了用人员配置简单解释问题的说法。NIST 并非只是因为分析人员效率下降而处理了更少记录。涌入的数量增长速度快于以人工为中心的信息补充流程所能扩展的速度。

公开的 NVD 仍在运行，并继续接收 CVE。真正的变化在于每条记录获得标准化背景信息的速度。这些背景信息往往决定漏洞平台能否将某项缺陷与组织的实际系统关联起来。

对安全团队而言，一条基本 CVE 与一条经过 NVD 信息补充的记录并不能互换。记录可以标识出缺陷，却未必提供足够的结构化数据以支持可靠的优先级排序。产品映射和严重程度详情会影响扫描器、仪表板和修复队列。

这种差异构成了 Google News 所关注的矛盾。NIST 必须维持广泛的公共覆盖，同时将有限的分析能力集中于具有系统性重要性的风险。自动化提供了一条前进路径，但优先级排序已经在塑造今天的数据库。

为什么 Google News 正在关注 AI 驱动的漏洞激增

漏洞激增反映了多重因素，而 AI 放大了其中不止一种。

AI 编程助手可以生成函数、测试、配置文件，以及完整的应用组件。这种生产力创造了更多需要组织审查的代码，也降低了在缺乏深厚安全经验的情况下构建软件所需的门槛。

更多代码并不必然意味着更多漏洞。代码质量取决于模型、提示词、架构、审查实践和部署控制。不过，更高的产出扩大了可能出现错误的范围。

安全研究一再发现，功能正确的代码与安全的代码之间存在差距。模型可以生成能够正常运行的软件，却遗漏授权检查或不安全输入控制。因此，功能上的成功可能掩盖安全上的失败。

Veracode 在其 2025 年安全研究中，针对编程任务测试了超过 100 个大型语言模型。该公司报告称，45% 的生成样本未能通过安全测试。其 AI 代码发现还表明，更强的功能表现并不保证输出更安全。

该研究并未证明 AI 导致了 NVD 的积压。NIST 将运营调整归因于不断增长的 CVE 提交量，而不是归因于由生成代码造成的某个已测量比例。由于漏洞发布由多种因素驱动，这种关系需要谨慎表述。

安全研究人员如今使用 AI 分析源代码、比较补丁、生成测试，并调查可疑行为。这些工具可以发现此前未公开的弱点。即使软件质量保持不变，更好的检测能力也会增加有价值的报告。

组织还通过开源仓库、云服务、插件、联网设备和依赖生态系统发布更多软件。CVE 项目扩大了其获授权发布者网络。这两种变化都增加了进入公共系统的记录数量。

AI 也降低了低质量报告的生成成本。模型可以生成看似可信的漏洞叙述、严重程度评估和概念验证大纲。这些内容在维护者测试其底层主张之前，可能显得很有说服力。

cURL 项目曾说明这种压力：其维护者描述了收到包含虚假主张的 AI 生成报告。即使这些提交最终永远不会成为有效 CVE，它们仍会消耗时间。成本从生成报告转移到了证伪报告。

这造成了两种不同的洪流。一种包含通过更快研究发现的真实漏洞。另一种则包含重复报告、薄弱发现、不可利用条件和伪造报告。在防御者能够负责任地采取行动之前，两者都需要审查。

AI 辅助发现还压缩了软件发布与安全审查之间的时间。研究人员可以让智能体追踪数据流、检查依赖关系并提出利用路径。人类专家仍需验证这些路径是否真正有效。

因此，数量问题在 NVD 信息补充之前就已开始。维护者必须评估收到的报告。CVE 编号机构必须决定问题是否符合项目规则。供应商必须准备补丁并协调披露，之后 NIST 才会增加下游背景信息。

通过 Google News 了解此事的读者应当抵制一种方便却缺乏支持的结论：AI 生成代码并非 CVE 创纪录增长的唯一原因。它只是软件生产和漏洞发现更大变化中的一个加速器。

更可靠的结论更为有限。AI 降低了生成代码和在其中搜寻弱点的成本。除非验证与修复能力也能随这些活动同步扩展，否则安全队列会在多个环节同时增长。

这种压力会直接传导至开发者。一个团队可以合并更多 AI 辅助变更，而其安全人员规模却保持不变。如果分析人员无法判断哪些模式会带来可达、可利用的风险，那么发现十倍之多的可疑模式也无济于事。

它也会影响被广泛使用的开源项目维护者。他们往往没有专职安全团队。一份 AI 生成报告即使最终被证明结论错误，也可能需要数小时的复现工作。

政府系统面临相关问题。各机构需要在庞大的资产清单中获得一致的漏洞数据。缺失或延迟的产品映射，可能让真实缺陷难以与已安装软件关联。

NVD 的变化承认了这种失衡。NIST 正在为后果重大的漏洞进行优化，而不是承诺同等的信息补充速度。在超负荷状态下，这一选择合乎逻辑，但它将更多判断责任转移给供应商、安全平台和用户。

AI 既是规模的来源，也是 NIST 提出的应对方案

NIST 正在探索 AI，因为人工信息补充无法承受无限增长，但自动化改变了失效模式，并未消除它。

NIST 多年来一直开展软件保障测量工作。其软件保障指标与工具评估项目支持对识别安全相关弱点工具的研究。该项目早于当前这一波生成式编程助手浪潮。

其中一个项目如今尤具相关性。NIST 将其 AI Bug Finder 描述为一个模块化测试平台，用于评估可在源代码中发现缺陷的 AI 方法。测试平台为比较不同系统提供受控任务和数据。

该项目属于 NIST 更广泛的 Bugs Framework 工作。该框架旨在以正式结构描述 bug、故障、弱点和漏洞。这些结构可以支持机器可读分析，而非完全依赖自然语言描述。

基于 Bugs Framework 的 AI 系统可以帮助识别、分析、排序和缓解漏洞。NIST 公开的 AI 漏洞系统描述了模型如何生成可由解析器和验证步骤检查的正式规范。

这一差异十分重要。让通用聊天机器人总结一条 CVE，与构建受约束的分析工作流并不是一回事。正式模式提供了可由软件验证、比较和拒绝的字段。

自动化可以协助完成多项 NVD 任务。它可以提取产品名称、关联版本范围、建议弱点分类、比较供应商公告，并识别缺失字段。它还可以标记与已知已利用模式相似的记录。

AI 可以在分析人员进行深入审查前帮助分流待处理队列。系统或许能够将相关报告归类、标出相互矛盾的证据，或建议哪些记录需要人工关注。这能减少花在重复数据转换上的时间。

然而，每项好处都伴随着相应风险。产品名称在不同供应商、包管理器和操作系统之间各不相同。错误的映射可能会让组织误以为安全，而其已安装的软件实际上正受影响。

版本范围带来另一项挑战。公告通常通过措辞、分支、构建编号或回移补丁来描述受影响版本。模型可以将这类文本转换为结构化数据，却可能在不知不觉中改变其含义。

严重性也取决于具体环境。同一代码弱点会因权限、网络访问、配置以及所需用户交互不同而产生不同后果。自动化评分可能用一个精确数字掩盖不确定性。

利用状态则更加敏感。公开讨论、演示代码和已观察到的攻击属于不同形式的证据。若分类器将它们混为一谈，可能会抬高推测性报告的重要性，或忽略正在发生的利用活动。

因此，应该将 NIST 的方向理解为经过评估的自动化，而非取代专家判断。该机构历来的职责聚焦于测量、标准和测试方法。任何 AI 系统都需要能够揭示准确性与失效情况的基准测试。

NIST 当前对 NVD 的变更已纳入来自该机构外部的结构化优先级信息。2026 年 6 月，它添加了来自 CISA 的特定利益相关方漏洞分类数据。SSVC 是用于确定漏洞响应优先级的决策框架。

NVD 状态页面称，此次架构更新影响了约 95% 的现有漏洞。它向 NVD 数据源和 API 添加了计算得出的 SSVC 信息及受影响产品数据。NIST 警告使用者预计会出现更大的载荷和暂时性延迟。

这次部署表明，NVD 现代化如何能够影响整个生态系统。架构变更改善了可用上下文，但每条下游数据管道都必须正确接收这些信息。只有集成保持可靠，自动化才能创造处理能力。

因此，这个故事中的主要对立并非 NIST 与软件供应商之间的对立，而是自动化规模与经过验证的判断之间的对立。AI 编程和 AI 分流都让信息流动更快，而验证仍是稀缺资源。

Google News 的报道可能会将这种张力压缩成一个简洁的循环：AI 制造漏洞，然后 AI 发现漏洞。但实际运营中存在多个关卡。必须有人确认缺陷、评估受影响系统、判断利用情况、发布补丁并传达修复措施。

AI 可以加速每一道关卡。它无法让相互矛盾的证据消失。成熟的系统应当呈现不确定性、保留来源溯源信息，并将模糊案例转交给人。

对于企业而言，同一原则也适用于开发管道内部。若缺乏优先级排序，产生数千条发现结果的 AI 扫描器反而可能加重安全工作负担。当大多数告警并不对应有意义的暴露面时，工程师会开始忽略它们。

有用的指标并不是生成了多少警告，而是在漏洞遭利用前修复了多少经过验证、可被触达的风险。只有当 NIST 的现代化工作能在所有 NVD 用户中改善这一结果时，它才算成功。

基于风险的扩充将压力传导至下游

NIST 的分流模型为紧急漏洞保护了注意力资源，但较低优先级的记录对个别组织而言仍可能极为重要。

某个漏洞可能不涉及联邦软件、关键软件或已知遭利用目录，却仍会威胁一家特定公司。专用工业工具、区域性产品和规模较小的开源软件包可能不会立即获得 NVD 扩充。

NIST 承认这一局限。其标准围绕系统性风险设计，而不是每家组织的本地暴露面。用户可以请求扩充，但这一流程仍要求有人识别出缺失的优先级。

安全供应商将填补部分空白。许多平台会将 NVD 记录与供应商公告、利用情报、软件包元数据和客户资产数据结合。这些额外来源可以在 NIST 完成扩充前支持决策。

大型供应商也可以提供自己的严重性评分和受影响版本数据。新的 NVD 流程更依赖由 CVE 编号机构提供的信息。当上游数据完整时，这种方法可避免重复工作。

困难出现在上游质量参差不齐时。一些组织发布包含补丁链接和精确版本范围的详细记录。另一些则只提供简短描述，留下关键问题未得到回答。

独立研究人员也可能在严重性评估或所报告行为是否构成漏洞方面与供应商意见不一。NIST 此前提供了另一层分析。减少常规评分可能会让用户不得不比较彼此不一致的评估。

CISA 的已知遭利用漏洞目录提供了强信号，因为其要求具备遭利用的证据。其目录标准使 KEV 对紧急修复具有重要价值。但该目录有意比危险漏洞的整体范围更窄。

等待利用证据可能对暴露系统来说为时已晚。新披露的漏洞可能在防御者观察到攻击前就已呈现明显风险。因此，组织不能将 KEV 作为唯一的优先级来源。

新模式也产生了值得关注的激励因素。研究人员和供应商知道，联邦使用、关键软件状态或纳入 KEV 可能加速扩充。围绕这些标签的争论可能变得更具影响力。

自动化请求可能成为另一种噪声来源。如果用户能够请求 NIST 扩充较低优先级记录，AI 系统可能生成大量看似合理的升级请求。NIST 将需要既保留访问渠道、又不重建原始积压问题的控制措施。

误报呈现出最直观的 AI 风险，但漏报可能造成更大伤害。错误地抬高无害模式重要性的模型会浪费分析人员时间。漏掉可被远程利用漏洞的模型则会让防御者失去预警。

训练数据中的偏差会塑造这两类错误。模型更容易从文档完善的产品和常见弱点类型中学习。冷门软件、非常规语言和新颖的利用链可能得到较弱的分析。

攻击者也可能操纵自动化管道。恶意公告可能包含误导性的产品名称、精心构造的描述或旨在影响提取系统的引用。任何基于 AI 的扩充工作流都需要防御不可信输入。

这并非拒绝自动化的理由。纯人工处理已达到能力上限。相关问题在于自动化在哪里发挥作用，以及其建议如何得到验证。

低风险任务包括规范格式、检测缺失字段和关联重复引用。高风险任务包括判断可利用性、修改受影响版本范围，以及在未经审查的情况下分配修复紧急程度。

NIST 可以通过公布自动化组件的评估方法和错误率来维护信任。用户需要知道哪些字段来自供应商、CISA、NIST 分析人员或机器生成的建议。

溯源信息至关重要，因为使用者将 NVD 数据视为基础设施。安全团队应能够检查为何一条记录获得特定映射或优先级。无法解释的模型输出无法提供这种问责能力。

同样的教训也适用于使用 AI 生成代码的工程团队。代码审查应尽可能保留提示词、模型变更、测试结果和所有权决策。可检索的工程知识库可以帮助团队将生成的变更与架构和安全证据关联起来。

文档不会让不安全代码变得安全。它为审查人员提供了从发现结果追溯到引入或接受该决策的更清晰路径。随着软件创建速度加快，这种上下文变得更有价值。

企业也不应将“未排期”解读为“没有漏洞”。该标签描述的是 NIST 的扩充队列。它并不衡量漏洞在公司环境中的可利用性。

这种语义区别可能会在仪表盘中消失。供应商必须将 NVD 状态与安全风险分开展示。否则，用户可能会将缺少联邦扩充误解为低优先级修复决策。

自动化漏洞分流必须证明什么

基于 AI 的分流需要具备可衡量的可靠性，防御者才能将其视为关键安全基础设施。

第一项测试涉及产品识别。系统应能够可靠地将漏洞与正确的供应商、软件包、版本和部署环境关联起来。细微的命名错误可能导致广泛的资产清单错误。

第二项测试涉及证据处理。模型必须区分供应商声明、独立演示、公开利用代码和已确认攻击。每种来源支持的置信度级别不同。

第三项涉及不确定性。当证据相互矛盾或仍不完整时，负责任的系统应当选择不作判断。为每条记录生成自信答案是一种产品行为，而不是安全要求。

第四项涉及可复现性。当底层证据没有变化时，分析人员应获得相同的结构化结论。除非工作流约束输出，否则模型随机性会使审计轨迹变得复杂。

第五项涉及对抗性抵抗能力。漏洞报告是不可信输入，其中有些会包含恶意内容。扩充代理不应遵从嵌入式指令，也不应在缺乏控制措施的情况下检索不安全资源。

第六项涉及及时性。一个需要数周才能处理紧急记录的高准确率系统，其实际运营价值有限。NIST 既需要精确性，也需要有用的处理时效。

第七项涉及纠正。新证据经常会改变漏洞评估。自动化工作流必须更新先前结论，同时不能抹去这些修订背后的历史记录。

传统机器学习基准通常报告总体准确率。在这里，这个数字并不充分。涉及已被积极利用的远程代码执行漏洞的错误，应比涉及轻微本地条件的错误具有更高权重。

NIST 可以通过风险加权评估来解决这一问题。测试集应包括不完整公告、相互矛盾的版本数据、冷门产品、恶意文本以及新发现的弱点模式。仅使用干净的历史记录会让评估变得不切实际地容易。

与人工的比较同样必要。分析人员会犯错、会有分歧，并且在时间压力下工作。目标不应是与每项历史 NVD 决策实现完美一致。

更有力的基准应比较下游效用。AI 支持的工作流是否降低了纠正率、提升了受影响产品覆盖率，并缩短了紧急扩充时间？它是否为模糊案例保留了分析人员的注意力？

独立测试应检查模型漂移。供应商会更新商业模型，本地模型则会获得新的训练和调优。即使 NIST 周边代码保持不变，自动化工作流的行为也可能发生变化。

公共部门的使用还带来采购方面的考量。NIST 必须考虑数据处理、模型访问、服务连续性和可复现性。专有模型可能迅速改进，但会使长期验证变得复杂。

开放模型提供了可检查性和本地控制能力，但仍然需要评估。模型权重无法揭示某个具体结论为何会出现。透明的输入、规则和验证依然不可或缺。

攻击者会研究任何公开的优先级排序系统。他们可能会瞄准获得较慢关注的产品或弱点类别，也可能将披露材料设计得类似高优先级记录，从而消耗有限的审核能力。

这种对抗压力使人工监督变得至关重要，尤其是在升级决策方面。自动化应当提升呈现给分析师的问题质量，而不应只是用不可见的模型错误取代可见的积压队列。

评估商业 AI 分诊工具的安全负责人也应提出类似问题。每项发现由哪些数据支撑？系统能否展示受影响的代码路径？是否衡量可达性？又如何处理相互冲突的证据？

他们还应衡量修复吞吐量。一款工具若将发现数量翻倍，而修复数量仍然持平，增加的是工作负担，而非安全性。只有当优先级排序和工程能力同步扩展时，发现数量才有价值。

NIST 的案例提供了同一限制条件在国家层面的例证。更多漏洞信息并不会自动带来更好的防御。只有当系统将信息转化为经过验证且及时的行动时，信息才具备价值。

Google News 关注之后值得观察的三个信号

下一阶段将取决于补充信息的表现、自动化的透明度，以及下游决策的质量。

第一个信号是风险导向模型下的 NVD 吞吐量。关注 NIST 是否能够持续实现对已知遭利用漏洞的一营业日目标。同时也要观察未排期队列是否仍在扩大。

如果紧急记录获得更快、更一致的补充信息，新模式就会赢得可信度。如果优先级收窄后延迟依然存在，仅靠分诊并未解决能力问题。

第二个信号是关于自动化工作流的技术披露。NIST 表示，正在开发自动化系统和工作流改进措施，以实现长期可持续性。关键细节将涉及验证、溯源、弃权处理和人工审核。

面向 AI 支持的补充信息建立公开基准，将增强外界信心。这将使研究人员能够审视不同产品和弱点类型中的失败案例。清晰的字段级归因也能帮助下游用户判断数据质量。

披露不足将削弱 AI 支持扩展能力的论据。安全基础设施需要的不只是模型准确率声明。使用者需要了解自动化输出如何进入记录，以及如何进行纠正。

第三个信号是依赖 NVD 的平台和企业团队的行为。关注供应商是否整合 SSVC、供应商提供的严重性评级、受影响产品数据和 KEV 信号，同时避免将它们呈现为可以互换的信息。

成功的适应将带来具有清晰溯源的优先级排序。糟糕的适应则会导致相互矛盾的仪表盘、缺失的映射关系，以及围绕未排期记录的虚假安心感。

组织现在就应审视自身对 NVD 补充信息的依赖。团队可以盘点哪些扫描器使用 NVD 严重性评级、CPE 映射或 NIST 编写的分析内容，随后识别供应商公告和软件包数据在哪些环节提供了必要的备份。

开发者也应将漏洞发现与 AI 辅助的代码变更进行关联跟踪。目标并不是禁止生成式代码，而是确定审核、测试和修复能否跟上产出速度。

安全团队可以为发现和闭环分别建立衡量指标。相关指标包括已验证发现、可利用发现、修复时间中位数、重新打开的问题，以及误报审核成本。这些指标能揭示 AI 是否真正改善了防御能力。

通过 Google News 关注这一事件的读者，应当预期看到更少的泛泛论断和更多的运营证据。有价值的问题并不是 AI 是否会编写不安全的代码；每一种开发方法都可能产出不安全的代码。

更关键的问题是，验证能力能否随着自动化生产和发现能力的增长而扩大。NIST 的政策变化表明，旧有平衡在国家规模上已经失效。

AI 辅助分诊提供了一种可信的应对方式，尤其适用于重复性的补充信息工作。不过，它必须保留证据、不确定性和可追责的审核机制。否则，自动化只会让漏洞数据流转得更快，却不会让它更值得信赖。

NIST 如今面临着每一家采用编程代理的软件组织都共同面对的考验：必须使用自动化，却不能将输出数量误认为已完成的安全工作。

团队接下来应做什么？梳理 NVD 数据进入安全决策的环节，保留替代来源，并衡量修复情况而非告警数量。然后观察 NIST 的自动化是否在不掩盖重大错误的前提下，提升经验证的补充信息质量。

这才是 Google News 标题背后的真正故事。AI 扩大了软件创建和漏洞发现的速度。剩下的瓶颈是判断力，而任何模型都不应被允许掩盖这一点。