User story: Missing CPE names #20
Description
In the form of: "As a role performing task, I struggle with problem because reason."
As a consultant with customers that utilize CVE data, I struggle with the fact that around half of current CVE records don’t have CPE names, because this makes the CVEs invisible to product searches.
Until February 2024, the great majority of new CVE records included a CPE (common platform enumeration) name. While CPE certainly isn’t perfect, it was until very recently the only machine-readable software identifier supported by the National Vulnerability Database (NVD). Moreover, it remains the only NVD-supported identifier for commercial software, as well as intelligent devices.
Since February 2024, only around half of new CVE records have included CPE names. This creates a serious problem, since a product search in the NVD will 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 will be misled to believe their product contains fewer vulnerabilities than it in fact contains or no vulnerabilities at all; moreover, the NVD does not notify them of this problem.
While the NVD (which until now has had the primary responsibility for creating CPE names for new records) has made various efforts to fill in missing CPE names since then, NIST (the NVD’s parent organization) announced in January 2026 that they will focus their “enrichment” efforts on a few types of CVEs (including CVEs in CISA’s KEV catalog); they will no longer take responsibility for other CVEs. This is likely to make the problem worse, since the percentage of new CVE records that contain a CPE number is likely to drop below 50 - and continue to fall as time goes on.
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 (enrichment is the NVD’s term for adding CPE names, CVSS scores and CWEs to CVE records). However, the CNAs are very reluctant to do this, because it is difficult to create a usable CPE name.
The problem is that 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 can choose from many possible values for each of the fields; there is no way for them to identify a “correct” value among them. This makes it impossible for someone searching for vulnerabilities applicable to a product to create a CPE name that is certain to be the same as the one the creator used.
For example, over the past ten years, the product known generically as "Microsoft Office" has been available under the following names: "Office 2016", "Office Online", "Office 2019", "Office 2021", "Office 2024", "Office for iPad", "Office Mobile", “Office 365”, "Office 365 ProPlus", “Microsoft 365”, “Microsoft 365 Business Basic”, “Microsoft 365 Business Standard”, and “Microsoft 365 Apps for Enterprise”, "Microsoft 365 Apps for Business", and "Office on the Web".
The above 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 from the past (Office first appeared in 1990). Unless the person who creates a CPE name for a product described as Microsoft Office makes sure to research the exact product name, version string and vendor name (including exact punctuation) when creating a CPE name for a vulnerable product described in the text of a CVE record, the CPE they create will not be recognized when a user of that product/version searches for it in the NVD.
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 in the CVE record. As a result, a search using the new version number will not find the CVE, which was reported with the CPE for the previous version.
These problems are compounded by the fact that, when a user's search for a particular product/version in the NVD fails to return a CVE record for any reason, the user always sees the same message: "“There are 0 matching records”. Thus, even though there might be twenty CVE records whose text lists a particular product/version as vulnerable, if the product name, version string and vendor name included in the CPE names in those records don't exactly match the values for the same three fields that were entered by a user searching the NVD for the same product/version, the user will receive the same message. Being human, they are likely to assume this negative result means the product/version is vulnerability-free, when in fact the opposite may be true.
Fortunately, the CVE Record Format now supports the PURL identifier, which is far more reliable than CPE. However, PURL is currently limited to naming open source software distributed through package managers. Commercial software products and open source projects not found in package managers (e.g., C/C++ programs) need to be named with CPE for the time being - although, as discussed earlier, the fact that . Whenever these problems are addressed and PURLs become the preferred software identifier for CVE records, CVE will be a truly universal vulnerability identifier.