二十年来，NVD（国家漏洞数据库）一直是漏洞管理的事实标准。漏洞扫描器、SIEM（安全信息和事件管理）系统、补丁管理工具以及合规性框架，都基于这样一个前提：当一个CVE条目出现在NVD中时，NIST（美国国家标准与技术研究院）的分析师会及时补充严重性评分、产品版本映射以及上下文元数据，从而使原始的CVE ID真正发挥作用。
2026年4月15日，这一假设正式不再成立。
美国国家标准与技术研究院（NIST）宣布，国家漏洞数据库（NVD）将转向基于风险的增强模型。 大多数新进入数据库的 CVE 将不再默认获得 NIST 添加的 CVSS 评分、CPE 产品映射以及独立分析。对于那些依赖 NVD 增强数据的漏洞处理工作流的组织而言，这造成了真实且日益严重的覆盖范围问题。对于将该数据嵌入其工具的安全产品开发者和供应商来说，这引发了一个更为尖锐的问题：你们的数据源现在究竟在向你们传达什么信息？
NVD已无法及时跟进报告的漏洞
根据美国国家标准与技术研究院（NIST）的公告，2020年至2025年间，CVE漏洞报告数量增长了263%，而2026年第一季度的报告数量已比上年同期高出近三分之一。
2025年，美国国家标准与技术研究院（NIST）对近42,000个CVE进行了补充完善，这一数字比以往任何一年都增长了45%。但这种生产力的提升仍不足以跟上不断增长的提交量，因此建立了一套正式的分流系统。
自 2026 年 4 月 15 日起，NIST 将仅对出现在 CISA 的 KVE（已知被利用漏洞）目录中、联邦政府使用的软件，或根据第 14028 号行政命令被指定为关键的软件中的漏洞进行信息补充。其余所有漏洞将列于 NVD 中，但不包含 NIST 补充的信息，且不会立即进行处理。
因此，近30万个在2026年3月1日之前发布的积压CVE已被整体移入“未安排”类别。
对于今后不符合 NIST 优先级标准的 CVE，其严重性评分将直接采用 CVE 编号机构（通常是受影响软件的供应商）自行报告的数值，而非基于 NIST 的独立分析结果。此外，当 CVE 编号机构已提供严重性评分时，NIST 将不再重新计算该评分。
每款主流漏洞扫描器、每条SIEM关联规则、每项第三方风险评分，以及从PCI DSS到FedRAMP的所有合规框架，都依赖于NVD数据增强管道。
随着此次更新，该流程现已正式收紧，导致一些潜在的危险 CVE 未能被归类为危险，或未能及时发现。
还有一个值得关注的加速因素：数据丰富度的降低正与人工智能辅助威胁发现技术的快速普及形成交汇。
先进的人工智能模型和编码工具正在显著降低识别应用程序中可被利用的漏洞和复杂攻击路径的门槛，从而导致CVE披露数量激增。2026年2月，事件响应与安全团队论坛（FIRST）预测，2026年将新增创纪录的50,000个CVE报告。当前的数据增强基础设施尚不具备在保持以往质量水平的前提下处理如此庞大数量的能力。
为何仅基于NVD构建的产品存在问题
一个 原始的 CVE 记录通常包含 ID、描述和参考文献。 推动自动化漏洞管理的元数据历来 来自 NVD 的分析师。这些数据涉及经过独立验证的 CVSS 严重性 评分、CPE 产品映射以及 CWE 弱点分类。
但是 正是“丰富信息”使 CVE 能够被有效利用。如果没有它， 依赖于它的处理流程就会以可预见的方式出现退化。
基于CVSS的优先级排序效果减弱
当扫描器或补丁工具预期会收到 NVD 提供的严重性评分，却未找到相关评分时，该漏洞可能会被标记为“严重性未知”，从而不被纳入基于 SLA 的补丁策略，或被降级处理。
美国国家标准与技术研究院（NIST）在2026年4月的更新中确认：
- 不符合新优先级标准的 CVE 不会自动获得独立评分
- 如果某个漏洞评估机构（CNA）已经提供了CVSS评分，NIST将不再自行生成评分（即使该CNA是受影响软件的供应商）
CPE 映射不完善或缺失会导致 CVE 检测效果不佳
NVD 的官方文档将产品识别描述为数据增强的关键环节，因为它使用户能够通过编程方式检查已知漏洞是否影响其环境中的产品。
如果 CPE 映射缺失、不完整或延迟，那些主要依赖 CPE 匹配的工具可能无法识别匹配项，或者延迟识别匹配项。
安全产品供应商受影响最为严重，因为他们的产品通常依赖于CPE匹配和CVE信息补充。补丁管理、终端防护、网络访问控制以及资产管理工具都依赖于准确的漏洞情报，以确定哪些系统受到影响、问题严重程度如何，以及接下来应采取何种措施。
对于正在开发新安全产品的团队而言，仅以NVD作为起点，就意味着在可能已存在关键缺口的基石上进行构建：零日漏洞覆盖范围有限，针对日益增多的CVE缺乏数据增强，且更新周期可能难以跟上人工智能在漏洞发现和利用方面的速度。
对于已经具备补丁管理或修复能力的团队而言，风险虽有所不同，但同样重要。修复引擎的有效性完全取决于其接收到的漏洞情报质量。如果这些情报存在不完整、延迟或过度依赖 NVD 衍生增强信息的情况，下游工作流可能会遗漏受影响的产品、降低未知严重性漏洞的优先级，或者在风险暴露加剧前未能采取行动。
如果这些产品继承了NVD的缺陷，那么这些缺陷可能会被所有下游客户所继承。
这正是 OESIS 框架漏洞评估旨在解决的问题：帮助安全产品团队在不完全依赖 NVD 数据增强的情况下，加强漏洞情报能力。
OPSWAT 对此OPSWAT 何种不同的方法
OPSWAT 专门为需要在其工具中嵌入可靠且可操作的漏洞数据的安全产品开发人员，OPSWAT OESIS Framework 漏洞评估模块。
围绕“Gap”而设计
该模块整合了多个数据源，而非仅依赖单一数据源。
它利用多种商业和开源漏洞信息源，确保对数百家供应商和应用程序进行及时、准确的覆盖。
OESIS 漏洞目录目前收录了超过 65,000 个独特的 CVE 条目和 150,000 多个漏洞实例，并且会持续更新——每天更新多次——而非等待 NVD 的处理周期。
一种超越 CVSS 的专有严重性评分体系，能提供更丰富的背景信息。
OPSWAT漏洞数据包含OPSWAT 评分”，这是一种专有评级体系，它在 CVSS 基础评分的基础上，融入了更多因素，包括 CVE 的流行度、受影响风险以及 CVE 的生命周期。
在CVSS评分中由CNA自行申报的比例日益增高的背景下，这一独立的分析层有助于安全产品为用户提供更具说服力的优先级排序依据。
OESIS 漏洞情报支持两种集成路径，且无需复杂的准备过程：
- 产品目录数据源：在服务器端将 OESIS 漏洞数据与您的现有软件资产清单进行比对——无需端点代理。具备软件资产清单功能的现有产品可利用 OESIS 数据，对受管资产进行漏洞检测。
- Endpoint （Software 工具包）： 将 OESIS 框架直接嵌入您的产品中，实现实时、基于设备的vulnerability detection。非常适合在终端上运行的安全产品
内部漏洞研究
OPSWAT 内部威胁研究团队“Unit 515”持续开展针对关键基础设施和企业软件的 进攻性安全研究、对抗性模拟、高级测试以及负责任 披露工作。该团队已 发现并报告了50多个零日漏洞，其中包括 在广泛部署的软件中发现的关键漏洞，例如Delta PLC等 ICS/OT平台以及原生AI平台。
这对 安全产品开发者的实际影响是，即使NVD的数据增强范围有所缩小，他们的工具仍能保持 更广泛的漏洞覆盖范围——且无需 让客户接受可见性降低或采用手动变通方案。
检测与修复：完整闭环
检测用于识别存在漏洞的环节，修复则用于解决这些问题。二者结合，有助于尽可能地消除风险隐患。OESIS 漏洞评估负责漏洞检测和优先级排序。对于希望在同一框架下同时具备这两项功能的团队，可选用OESISPatch Management：
- 检测： 存在漏洞的应用程序、版本匹配、OPSWAT ，并标记为KEV
- 优先级排序： OPSWAT 基于实际的攻击迹象，帮助确定应优先修复的问题
- 解决方案： 您的现有管道可以处理 OESIS 输出——或者 OESISPatch Management 补丁Patch Management 、强制版本或阻止访问
- 验证： OESIS 会在恢复访问权限前重新扫描后缀，以确认端点是否安全
仅进行检测而不采取修复措施，只是生成了一份报告；若在检测后采取修复措施，则风险便得以解决。OESIS 旨在为您的产品提供这两方面的能力，帮助更快地闭环检测与修复流程，从而更好地应对AI级别的威胁。
AI-Speed 漏洞需要 AI-Speed 发现
安全产品绝不能将漏洞情报视为一个更新缓慢的后端依赖项。随着CVE数量的增长以及情报丰富度的不稳定性增加，产品团队需要一种方法，确保检测、优先级排序和修复工作流与实际风险暴露情况保持同步。
这正是 OESIS 框架漏洞评估发挥作用之处。它为产品开发者提供了一种切实可行的方法，无需从头重建终端或修复架构，即可增强漏洞覆盖范围。对于正在推出新产品的团队，它有助于更早地建立可靠的覆盖范围；对于正在改进现有产品的团队，它提供了一种更顺畅的方式来比较覆盖范围、验证改进效果，并决定更深入的集成应如何实现。
