In lots of instances, as soon as a high-risk safety vulnerability has been recognized in a product, an even bigger problem emerges: find out how to determine the affected element or product by its assigned title 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) title, that are assigned by the Nationwide Institute of Requirements and Expertise (NIST), a part of the US Division of Commerce.
The NVD makes use of a CPE to determine {hardware} and software program parts primarily based on vendor, product, and model string. When software program customers wish to decide, by way of the NCD, whether or not a element of a product they’re utilizing has any related vulnerabilities, they need to know the exact assigned CPE title of the element. Nevertheless, it’s typically not possible to discover a CPE for a selected element, whether or not they’re open supply or proprietary.
Generally, this downside makes it not possible to reliably automate most 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 situations that make it extraordinarily tough, if not not possible, to seek for element and product vulnerabilities within the NVD, resulting from 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 risk degree 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 might not have reported any current vulnerabilities to the NVD.
Consequently, an NVD search will yield a “No matching information” response in each of the next situations:
(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 title is entered within the NVD, it’s potential to create a product CPE that doesn’t observe a constant naming conference. Consequently, 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 similar message they’d obtain if the unique (off-specification) CPE title have been used however there have been no CVEs reported towards it.
When a consumer receives this message, it may imply there’s a legitimate CPE for the product they’re looking on, however a CVE has by no means been reported for that product, nevertheless it may additionally imply the CPE they entered doesn’t match the CPE within the NVD, and that there are, actually, CVEs hooked up to the (off-specification) CPE title submitted to the NVD.
The “There are 0 matching information” error message may additionally outcome if a consumer misspells the CPE title within the search bar. On this occasion, the consumer would don’t have any means of figuring out that the message was generated by a typo, and as a substitute may assume the product has no reported vulnerabilities.
3. Over time, a product or provider title might change resulting from a merger or acquisition, and the CPE title for the product might change as nicely. On this case, if a consumer searches for the unique CPE, not the brand new CPE, they’d not find out about new vulnerabilities. As earlier than, they’d 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 title, 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 unique iteration. This could make it nearly not possible to find out which title is appropriate. To make issues worse, if CVEs have been entered for every of the CPE variants, this may outcome of their being no “appropriate” title. One instance is OpenSSL (e.g., “OpenSSL” versus “OpenSSL Framework”). Since no single CPE title incorporates all of the OpenSSL vulnerabilities, customers should search individually for every variation of the product title.
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 include, customers must learn the complete CVE report to find out which module is weak. If they do not, this can lead to pointless patching or mitigations, like when a weak module shouldn’t be put in in a software program product getting used however different modules of the library are.
Happily, a cross-industry group referred to 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 concentrate on fashionable, automated use instances.
The group’s suggestions, together with the adoption of a package deal URL (purl) for software program and GS1 Requirements for {hardware}, are designed to create a standardized option to reliably question the NVD and obtain correct info on vulnerabilities.
