In many cases, once a high-risk security vulnerability has been identified in a product, a bigger challenge emerges: how to identify the affected component or product by its assigned name in the National Vulnerability Database (NVD). That's because software products are identified in the NVD with a common platform enumeration (CPE) name, which are assigned by the National Institute of Standards and Technology (NIST), part of the US Department of Commerce.

The NVD uses a CPE to identify hardware and software components based on vendor, product, and version string. When software users want to determine, via the NVD, whether a component of a product they are using has any associated vulnerabilities, they must know the precise assigned CPE name of the component. However, it is often impossible to find a CPE for a particular component, whether they are open source or proprietary.

In most cases, this problem makes it impossible to reliably automate many of the processes required for software security, such as producing a software bill of materials (SBOM).

Why Finding Vulnerabilities in the NVD is Hard

To understand the scope of the problem, consider the following six conditions that make it extremely difficult, if not impossible, to search for component and product vulnerabilities in the NVD, due to its reliance on CPEs as the sole identifier.

1. Vulnerabilities are identified in the NVD with a common vulnerabilities and exposures (CVE) number, e.g., "CVE-2022-12345," and the Common Vulnerability Scoring System (CVSS) is used to assign a threat level to each CVE. A CPE is typically not created for a software product until a CVE is assigned to it. However, many software suppliers have never reported a vulnerability (which would generate a CVE), so a CPE has never been created for the product in the NVD. 

This is not necessarily because the products have never had vulnerabilities, but because the developer may not have reported any existing vulnerabilities to the NVD.

As a result, an NVD search will yield a "No matching records" response in both of the following scenarios: 

(i) a vulnerability does not exist in a given product

(ii) a vulnerability exists but has never been reported by the developer

2. Since there is no error checking performed when a new CPE name is entered in the NVD, it is possible to create a product CPE that does not follow a consistent naming convention. As a result, when a user searches for the product using the properly specified CPE, they will receive a "There are 0 matching records" error message. This is the same message they would receive if the original (off-specification) CPE name were used but there were no CVEs reported against it.

When a user receives this message, it could mean there is a valid CPE for the product they're searching on, but a CVE has never been reported for that product, but it could also mean the CPE they entered does not match the CPE in the NVD, and that there are, in fact, CVEs attached to the (off-specification) CPE name submitted to the NVD.

The "There are 0 matching records" error message could also result if a user misspells the CPE name in the search bar. In this instance, the user would have no way of knowing that the message was generated by a typo, and instead could assume the product has no reported vulnerabilities.

3. Over time, a product or supplier name may change due to a merger or acquisition, and the CPE name for the product may change as well. In this case, if a user searches for the original CPE, not the new CPE, they would not learn about new vulnerabilities. As before, they would receive the "There are 0 matching records" message.

4. This also applies for different variations of supplier or product names, such as "Microsoft" and "Microsoft Inc.," or "Microsoft Word" and "Microsoft Office Word," etc. Without the exact correct supplier or product name, an NVD search will yield incorrect results.

5. The same product can have multiple CPE names in the NVD if they are entered by different people who each use a different iteration. This can make it virtually impossible to determine which name is correct. To make matters worse, if CVEs have been entered for each of the CPE variants, this will result in their being no "correct" name. One example is OpenSSL (e.g., "OpenSSL" versus "OpenSSL Framework"). Since no single CPE name contains all the OpenSSL vulnerabilities, users must search separately for each variation of the product name.

6. In many cases, a vulnerability will only affect one module of a library. However, since CPE names are assigned on the basis of products, not the individual modules they contain, users need to read the full CVE report to determine which module is vulnerable. If they don't, this can result in unnecessary patching or mitigations, like when a vulnerable module is not installed in a software product being used but other modules of the library are.

Fortunately, a cross-industry group called the SBOM Forum that includes members of OWASP, The Linux Foundation, Oracle, and others are working on the problem and have developed a proposal to improve the accuracy of the NVD with a focus on modern, automated use cases.

The group's recommendations, including the adoption of a package URL (purl) for software and GS1 Standards for hardware, are designed to create a standardized way to reliably query the NVD and receive accurate information on vulnerabilities.