Just some of the many problems with CPE names

Two years ago, the OWASP SBOM Forum (then just called the SBOM Forum) published a paper that described some of the many problems with naming found in the National Vulnerability Database (NVD), and suggested solutions to them. The problems were all centered around “CPE names” (CPE stands for Common Platform Enumeration). These are machine-readable identifiers for software. The NVD has always relied on CPE; other vulnerability databases that are based on data from the NVD all utilize CPE (note: Almost all vulnerability databases that aren’t based on the NVD utilize the purl identifier instead).

We included in our paper a two-page description of six of the most important problems with CPE names (but unfortunately, they’re not the only problems!). Since that description remains quite valid and I find myself referring to it constantly in my posts, I am reproducing it below. I recommend you read this as good background for discussions of the NVD’s problems. Unfortunately, those discussions are unlikely to end anytime soon.

1. Vulnerabilities are identified in the NVD with a CVE number, e.g. “CVE-2022-12345”. A CPE is typically not created for a software product until a CVE is determined to be applicable to the product. However, many software suppliers have never identified a CVE that applies to their products, so they have never created a CPE for them. This is almost certainly not because the products have never had vulnerabilities, but because the suppliers, for whatever reason, have not submitted any vulnerability reports for those products for inclusion in the National Vulnerability Database.

 

The worst part of this problem is that the result of an NVD search will be the same in both cases - the case where a vulnerability has never been identified in a product and the case where the supplier has never felt inclined to report a vulnerability, even if they may have identified some. The search will yield “There are 0 matching records” in both cases. Someone conducting a search won’t know which case applies and may believe the product has no vulnerabilities, when in fact the supplier has simply never reported one.

 

2. There is no error checking when a new CPE name is entered in the NVD. Therefore, if the NIST/NVD staff member who entered the CPE name that was originally created for a software product did not completely follow the specification, a user who later searches for the same product and enters a properly-specified CPE will receive an error message. Unfortunately, it is the same error message that they would receive if the original CPE name were properly specified but there are no CVEs reported against it: “There are 0 matching records”.

In other words, when a user receives this message, they might interpret this to mean there is a valid CPE for the product they’re seeking, but a vulnerability (CVE) has never been identified for that product - i.e. it has a clean bill of health. However, in reality it would mean the CPE name was created improperly. In fact, there might be a large number of CVEs attached to the off-spec CPE but without knowing that name, the user will not be able to learn about those CVEs.

Another explanation for the “There are 0 matching records” error message is that the user had misspelled the CPE name in the search bar. Again, the user would have no way of knowing whether this was the reason for the message, or whether the message means the product has no reported vulnerabilities.

 

It is to avoid problems like this that many organizations that heavily use the NVD today employ advanced search techniques based on AI or fuzzy logic[i]. While that can greatly reduce the number of unsuccessful searches, having to resort to this makes it impossible to conduct truly automated searches. Considering that an average-sized software developer might easily need to conduct tens of thousands of NVD searches per day, and a service provider doing this on behalf of hundreds of customers would need to conduct some large multiple of that number of searches, the magnitude of this problem should be apparent.

 

3. When a product or supplier name has changed since a proprietary product was originally developed (usually because of a merger or acquisition), the CPE name for the product may change as well, to reflect the identity of the new supplier. Thus, a user of the original product may not be able to learn about new vulnerabilities identified in it, unless they know the name of the current supplier as well as the current name for the product. Instead, this user will also receive the “There are 0 matching records” message.

 

4. The same holds true for supplier or product names that can be written in different ways, such as “Microsoft(™)”, “Microsoft(™) Inc.”, “Microsoft(™) Inc”, “Microsoft Corporation”, etc. There is simply no fool-proof way to distinguish the correct supplier or product name among a large number of query responses.

 

5. Sometimes, a single product will have many CPE names in the NVD because they have been entered by different people, each making a different mistake. For this reason, it will be hard to decide which name is correct. Even worse, there may be no “correct” name, since each of the names may have CVEs entered for it. This is the case with OpenSSL (e.g. “OpenSSL” vs “OpenSSL_Framework”) in the NVD now. Because there is no CPE name that contains all the OpenSSL vulnerabilities, the user needs to find vulnerabilities associated with each variation of the product's name. But how could they ever be sure they had identified all the CPEs that have ever been entered for OpenSSL?

 

6. Often, a vulnerability will appear in only one module of a library. However, because CPE names are not assigned based on an individual module, the user may not know which module is vulnerable, unless they read the full CVE report. Thus, if the vulnerable module is not installed in a software product they use, but other modules of the library are installed (meaning the library itself is listed as a component in an SBOM), the user may unnecessarily patch the vulnerability or perform other unnecessary mitigations.

Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC. If you would like to comment on what you have read here, I would love to hear from you. Please email me at tom@tomalrich.com. 

I lead the OWASP SBOM Forum and its Vulnerability Database Working Group. These two groups work to understand and address issues like what’s discussed in this post; please email me to learn more about what we do or to join us. You can also support our work through easy directed donations to OWASP, a 501(c)(3) nonprofit, which are passed through to the SBOM Forum. Please email me to discuss that.

My book "Introduction to SBOM and VEX" is available in paperback and Kindle versions! For background on the book and the link to order it, see this post.

---

[i] Or, in the case of at least one third-party service provider, a “small army” of CPE-resolvers.