很多情况下，一旦产品中发现高风险安全漏洞，更大的挑战横亘眼前：怎样依据美国国家漏洞数据库（NVD）中指定的名称找出受影响的组件或产品。之所以存在这个问题，是因为NVD使用通用平台枚举（CPE）名称标识软件产品，该名称由美国商务部下属的国家标准与技术研究所（NIST）指定。

NVD根据供应商、产品及其版本字符串用CPE标识硬件和软件组件。软件用户若想通过NVD确定自己在用的某产品组件是否存在相关漏洞，就必须知道该组件的准确CPE名称。然而，无论是开源还是专有组件，通常都不太可能找到其CPE名称。

大多数情况下，软件安全所需的诸多流程就是因为这一问题而无法可靠地自动化，比如软件物料清单（SBOM）生成。

难以在NVD中找到漏洞的原因

为了解问题全貌，可以考虑下面六种情况，下列情况都可令依赖CPE作为唯一标识符在NVD中检索组件和产品漏洞极端困难。

1、漏洞在NVD中以通用漏洞与暴露（CVE）编号（如“CVE-2022-12345”）标识，并采用通用漏洞评分系统（CVSS）为每个CVE指定威胁级别。通常不会在分配到CVE编号之前就为软件产品创建CPE。然而，很多软件供应商从未上报漏洞（可能产生CVE），于是其产品在NVD中便一直没有CPE了。

这未必是因为产品从未出现漏洞，而是因为开发商可能没向NVD报告过任何现有漏洞。

因此，下面两种情况下，在NVD中检索就会得到“无匹配记录”的结果了：

（1） 给定产品中不存在漏洞

（2） 存在漏洞，但开发商从未报告过

2、由于NVD收录新CPE名称时不执行任何错误检查，所以有可能出现不符合一贯命名规范的产品CPE名称。于是，如果用户用正确指定的CPE检索产品，就会收到“0条匹配记录”的错误提示信息。如果使用了原始（非规范）CPE名称，但不存在该产品相关的CVE报告，用户也会收到如上提示信息。

这种提示信息可能意味着用户检索的产品CPE名称有效，但该产品未报告过CVE；也可能意味着用户输入的CPE不匹配NVD中的CPE，但实际上存在与提交到NVD的（非规范）CPE相关联的CVE。

用户在检索栏中拼错了CPE名称也会出现显示“0条匹配记录”错误提示信息的情况。这种情况下，用户根本不会知道是手误导致的，而会认为产品就是不存在报告的漏洞。

3、随着时间流逝，产品或供应商名称会因并购而改变，而产品的CPE名称也会变。这种情况下，如果用户用最初的CPE而没用新的CPE名称检索，也不会知道新出现漏洞的情况。与前面的情况相同，用户会收到显示为“0条匹配记录”的信息。

4、供应商或产品名称存在不同变体的情况也会导致检索出错，比如“Microsoft”和“Microsoft Inc.”，或者“Microsoft Word”和“Microsoft Office Word”等等。没有精准的供应商或产品名称，NVD检索就会产生错误的结果。

5、同一产品在NVD中可能会拥有多个CPE名称，如果产品由不同人员录入，而每个人都用了不同迭代的话。这可能导致几乎无法确定哪个名称是正确的。更糟糕的是，如果为每个CPE变体都录入了CVE，就会导致产品没有“正确”的名称。其中一个例子就是OpenSSL（如“OpenSSL”和“OpenSSL Framework”）。由于没有哪个CPE名称包含所有OpenSSL漏洞，用户必须单独检索每个产品名称变体。

6、很多情况下，漏洞只影响某个软件库里的一个模块。然而，由于CPE名称是指定给整个产品而非各个模块的，用户需完整阅读CVE报告才能确定到底是哪个模块易受攻击。如果没看全，可能会导致非必要的修复或缓解，比如在用产品中并未安装有漏洞的模块，而是安装了库里其他模块的时候。

幸好，名为SBOM论坛的跨行业小组（包括OWASP、Linux基金会、Oracle和其他组织的成员）正在研究这个问题，并制定了旨在提升NVD准确性的一项提案，该提案的重点放在现代自动化用例上。

该小组的建议，例如软件采用包URL（purl）和硬件采用GS1标准，旨在创建一种标准化的方式供可靠查询NVD和接收关于漏洞的准确信息。

来源：数世咨询