In last week’s meeting of the CVE Program’s Consumer Working Group[i] (CWG) – a group dedicated to identifying problems experienced by CVE users (talk about having your work cut out for you!) – a German CVE user mentioned that his organization has recently noticed that a search for a product name in the National Vulnerability Database (NVD) frequently does not identify any vulnerabilities for that product. This seems odd, since the NVD added about 50,000 new CVEs last year; that number will certainly increase this year.
I provided a brief response in the meeting’s chat, but here’s my full response:
The majority of known software vulnerabilities are reported in CVE records, which are stored in CVE.org; they are created by CVE Numbering Authorities (CNAs). The National Vulnerability Database (NVD) downloads new CVE records from CVE.org. Until February 2024, the great majority of new CVE records included a CPE[ii] name to identify vulnerable product(s) described in the text of the report; CPE is the only machine-readable software identifier supported by the NVD.
However, since that date, only around half of new CVE records have included CPE names. This creates a serious problem, since a product search in the NVD will normally not locate a CVE record that does not include a CPE, even though the product is mentioned as vulnerable in the text of the record.
As a result, a software user searching for vulnerabilities in a product they use may be misled into believing their product contains fewer vulnerabilities than it in fact contains – or even that it contains no vulnerabilities at all. To make things worse, the NVD makes no mention of this problem, so the user will have a false sense of security.
While the NVD (which until now has had the primary responsibility for creating CPE names for new CVE records) has made various efforts to fill in the missing CPE names since the problem appeared, those efforts haven’t succeeded. In fact, earlier this month NIST (the NVD’s parent organization) announced they will focus their “enrichment”[iii] efforts on just a few types of new CVEs , including CVEs in CISA’s KEV catalog; they will no longer take responsibility for other CVEs. This will make the problem worse, since it is likely the NVD will add CPEs to fewer than half of new CVE records going forward.
NIST suggested that CNAs (CVE Numbering Authorities, the 400+ organizations that are authorized to create new CVE records) should take responsibility for enriching CVE records. However, the CNAs are very reluctant to do this, because it is quite difficult to create a usable CPE name.
Why is this so difficult? CPE names include three mandatory fields – product name, product version string, and vendor name – which are inherently ambiguous. The person that creates the CPE name must choose from many possible values for each of the fields, yet there is no way for them to identify the “correct” value among them.
For example, almost all software products (and especially commercial products) have many different names throughout their lifetime. Google AI lists the following names for Microsoft Office™ over the past ten years: "Office 2016," "Office 2019," "Office 2021," "Office 2024,” “Office 365”, “Microsoft 365”, “Microsoft 365 Business Basic”, “Microsoft 365 Business Standard”, and “Microsoft 365 Apps for Business/Enterprise”.
This list doesn’t include names in foreign languages, custom versions for large corporations or government agencies, etc. It is likely there are at least a thousand names for Microsoft Office today, as well as many thousands of discontinued names in the past. Unless the person who creates a CPE name for a product described as “Microsoft Office” makes sure to research the exact name of the product they’re discussing, the CPE they create will probably not be recognized in a command line search, even if the search used the exact name of the product.
Thus, someone searching for vulnerabilities applicable to a product must guess the values for all three of the fields (plus a fourth field, “version”) that were used to create the original CPE name (the guess must include any punctuation. For example, “Microsoft, Inc” doesn’t match “Microsoft, Inc.”). If they don’t guess correctly for even one of the fields, the search won’t identify that the product searched for is vulnerable to the CVE, even though it is. On the other hand, if the user plays it safe and just enters “Microsoft Office”, they will be shown 277 different products; they will need to sort through them to find the one they are looking for. Usually, that isn’t easy.
This leads to another problem: if CVE-2026-12345 is reported for “Product A” this week, but next week the name changes to “Product B”, the CPE will also change. This means a search for vulnerabilities in Product B will not yield CVE-2026-12345, even if B remains vulnerable to that CVE. This also happens with product versions, since if a vulnerability carries over from one version of a product to another, this will usually not be reflected in the CPE name in the CVE record. As a result, a search with the new version number will not find the CVE, since it was reported using the CPE for the previous version.
Because of these problems and others, the person who creates the CPE name needs to make sure they choose the correct values for the fields in the CPE name. Since CVE Numbering Authorities all have day jobs, they are reluctant to take the time required to include CPE names in CVE records they author. Since NIST is now limiting the number of new CVE records they will “enrich” with new CPE names, this means the problem of missing CPE names is likely to get worse, not better.
Fortunately, the CVE Record Format now supports the PURL identifier, which is far more reliable than CPE; in fact, there is seldom ambiguity about what product is referred to in a PURL, meaning the user searching for vulnerabilities in a product should almost always be able to find any CVE record that contains the PURL for that product.
However, PURL is currently limited to naming open source software distributed through package managers. Because of this, commercial software products, open source software not found in package managers (e.g., C/C++ programs), and intelligent devices need to be named with CPE for the time being. Whenever these problems are addressed and PURLs become the preferred software identifier for all CVE records, CVE will be a truly universal vulnerability identifier.
Tom Alrich’s Blog, too is a reader-supported publication. You can view new posts for two months after they come out by becoming a free subscriber. You can also access all my 1300 existing posts dating back to 2013, as well as support my work, by becoming a paid subscriber for $30 for one year (and if you feel so inclined, you can donate more than that!). Please subscribe.
If you would like to comment on what you have read here, I would love to hear from you. Please comment below or email me at [email protected].
[i] This is a very good group, since it’s focused on end users of software, rather than developers. You can request to join the group here.
[ii] CPE stands for common platform enumeration. If you know what that means, you know more than I do.
[iii] Enrichment is the NVD’s term for adding CPE names, CVSS scores and CWEs to CVE records. Even though the CNAs create the CVE record itself, the NVD “enriches” them.