In lots of instances, as soon as a high-risk safety vulnerability has been recognized in a product, a much bigger problem emerges: easy methods to determine the affected element or product by its assigned identify within the Nationwide Vulnerability Database (NVD). That is as a result of software program merchandise are recognized within the NVD with a frequent platform enumeration (CPE) identify, that are assigned by the Nationwide Institute of Requirements and Know-how (NIST), a part of the US Division of Commerce.
The NVD makes use of a CPE to determine {hardware} and software program parts based mostly on vendor, product, and model string. When software program customers need to decide, through the NVD, whether or not a element of a product they’re utilizing has any related vulnerabilities, they need to know the exact assigned CPE identify of the element. Nevertheless, it’s typically inconceivable to discover a CPE for a selected element, whether or not they’re open supply or proprietary.
Typically, this drawback makes it inconceivable to reliably automate lots of the processes required for software program safety, resembling producing a software program invoice of supplies (SBOM).
Why Discovering Vulnerabilities within the NVD is Exhausting
To grasp the scope of the issue, think about the next six circumstances that make it extraordinarily tough, if not inconceivable, to seek for element and product vulnerabilities within the NVD, on account of its reliance on CPEs as the only real identifier.
1. Vulnerabilities are recognized within the NVD with a typical vulnerabilities and exposures (CVE) quantity, e.g., “CVE-2022-12345,” and the Widespread Vulnerability Scoring System (CVSS) is used to assign a menace stage to every CVE. A CPE is often not created for a software program product till a CVE is assigned to it. Nevertheless, many software program suppliers have by no means reported a vulnerability (which might generate a CVE), so a CPE has by no means been created for the product within the NVD.
This isn’t essentially as a result of the merchandise have by no means had vulnerabilities, however as a result of the developer could not have reported any present vulnerabilities to the NVD.
Because of this, an NVD search will yield a “No matching information” response in each of the next eventualities:
(i) a vulnerability doesn’t exist in a given product
(ii) a vulnerability exists however has by no means been reported by the developer
2. Since there isn’t any error checking carried out when a brand new CPE identify is entered within the NVD, it’s doable to create a product CPE that doesn’t observe a constant naming conference. Because of this, when a consumer searches for the product utilizing the correctly specified CPE, they are going to obtain a “There are 0 matching information” error message. This is identical message they might obtain if the unique (off-specification) CPE identify have been used however there have been no CVEs reported in opposition to it.
When a consumer receives this message, it might imply there’s a legitimate CPE for the product they’re looking out on, however a CVE has by no means been reported for that product, but it surely might additionally imply the CPE they entered doesn’t match the CPE within the NVD, and that there are, in truth, CVEs connected to the (off-specification) CPE identify submitted to the NVD.
The “There are 0 matching information” error message might additionally end result if a consumer misspells the CPE identify within the search bar. On this occasion, the consumer would haven’t any method of realizing that the message was generated by a typo, and as an alternative might assume the product has no reported vulnerabilities.
3. Over time, a product or provider identify could change on account of a merger or acquisition, and the CPE identify for the product could change as nicely. On this case, if a consumer searches for the unique CPE, not the brand new CPE, they might not study new vulnerabilities. As earlier than, they might obtain the “There are 0 matching information” message.
4. This additionally applies for various variations of provider or product names, resembling “Microsoft” and “Microsoft Inc.,” or “Microsoft Phrase” and “Microsoft Workplace Phrase,” and many others. With out the precise appropriate provider or product identify, an NVD search will yield incorrect outcomes.
5. The identical product can have a number of CPE names within the NVD if they’re entered by completely different individuals who every use a distinct iteration. This will make it nearly inconceivable to find out which identify is appropriate. To make issues worse, if CVEs have been entered for every of the CPE variants, this can end result of their being no “appropriate” identify. One instance is OpenSSL (e.g., “OpenSSL” versus “OpenSSL Framework”). Since no single CPE identify incorporates all of the OpenSSL vulnerabilities, customers should search individually for every variation of the product identify.
6. In lots of instances, a vulnerability will solely have an effect on one module of a library. Nevertheless, since CPE names are assigned on the premise of merchandise, not the person modules they comprise, customers must learn the total CVE report to find out which module is susceptible. If they do not, this may end up in pointless patching or mitigations, like when a susceptible module will not be put in in a software program product getting used however different modules of the library are.
Happily, a cross-industry group known as the SBOM Discussion board that features members of OWASP, The Linux Basis, Oracle, and others are engaged on the issue and have developed a proposal to enhance the accuracy of the NVD with a deal with trendy, automated use instances.
The group’s suggestions, together with the adoption of a bundle URL (purl) for software program and GS1 Requirements for {hardware}, are designed to create a standardized method to reliably question the NVD and obtain correct data on vulnerabilities.
