Note from Tom: I’ve moved the main platform for my blog from Blogspot (where it’s been since I started the blog in 2013) to Substack. I’m currently posting all new posts on Energy Central, but after August 11, I will only put up posts that are focused on the electric power industry, including my posts on NERC CIP. After that date, if you would like to read all of my posts (including the ones that focus on vulnerability management and vulnerability databases), please sign up for a paid annual subscription ($30). If you can't afford that, please drop me an email at the address below.
My previous post discussed a new white paper called “Ensuring the Longevity of the CVE Program” by the Center for Cybersecurity Policy and Law. To say that I wasn’t overwhelmed by the insights provided by the authors is an understatement. However, the biggest problem with the paper is the fact that it left out the biggest threat to the future of the CVE Program. That threat lies with a different US government agency that has recently been having big problems, although of a quite different kind. First, I’ll provide some background information on the problems, and why they affect the CVE Program.
The CVE Program is run by the non-profit MITRE Corporation, which is contracted by the Department of Homeland Security. It is paid for - at least through next March - by the Cybersecurity and Infrastructure Information Agency (CISA), which is also part of DHS.
The other US government agency is NIST, the National Institute of Standards and Technology. NIST is part of the US Department of Commerce.
One of NIST’s many projects is the National Vulnerability Database (NVD), which started in 2005. A vulnerability database links software products with vulnerabilities that have been identified in those products. The NVD is currently by far the most widely used vulnerability database in the world; many private (VulnDB, VulDB, VulnCheck, Vulners, etc.) and public (Japan Vulnerability Notes, EU Vulnerability Database, etc.) vulnerability databases draw heavily from the NVD.
The NVD identifies vulnerabilities using CVE numbers (e.g., CVE-2025-12345); each vulnerability is described in a “CVE record”. Many people (including me, a few years ago) assume that, because the NVD uses CVE numbers to identify vulnerabilities, it must be the source of CVE records. In fact, CVE records originate with the CVE Program in DHS. They are created by CVE Numbering Authorities (CNAs), of which there are currently more than 450. The largest CNAs are software developers, including Microsoft, Oracle, Red Hat, HPE, and Schneider Electric.
When a CNA creates a new CVE record, they submit it to the CVE.org vulnerability database, which is run by the CVE Program (this is sometimes referred to as the “CVE list”, although it’s much more than a simple list). The NVD (and other vulnerability databases that are based on CVE) downloads new CVE records shortly after they appear in CVE.org.
When a CNA creates a new CVE record, they have the option of including various information in the record. Some fields are officially optional and others are mandatory, but, to be honest, there are only a few fields that are really mandatory, in the sense that the record will definitely be rejected if they’re not present (this includes the CVE number and the product name). The CVE Program maintains the CVE Record Format (formerly, the “CVE JSON Record Format”), which is now on version 5.1.1. The full spec for 5.1.1 is here, but this older version is more readable and reasonably up to date.
For our present purposes, the most important fields in the CVE record are:
1. The CVE number that the CNA has assigned to this vulnerability, as well as a description of the vulnerability.
2. The name(s) of the product(s) affected by the vulnerability. While the CNA must list at least one affected product, they can also list many of them, including separate versions of the same product. Of course, every product listed needs to be affected by the vulnerability described in the record.
3. The vendor(s) of the product(s) affected by the vulnerability.
4. The version or versions[i] affected by the vulnerability.
5. The CPE name for each affected product.
The last item needs explanation. CPE stands for Common Platform Enumeration, although the name doesn’t carry much meaning today. What’s important is that CPE is a complicated machine-readable naming scheme for software and hardware products; the CPE name includes fields 2-4 above. If a CVE record doesn’t include a CPE name, it isn’t easily searchable in the NVD, since there is no way to know for certain that the product described in the text of a CVE record is the same product that is the basis for a similar CPE name.
For example, suppose items 2-4 above appear as “Product A”, “XYZ”, and “Version 2.74” respectively in the text of a CVE record. Furthermore, suppose that a user of Product A v2.74 wants to learn about vulnerabilities identified in that product. They find the CPE name for a similar product that includes the same values of fields 2 and 4, but it includes “XYZ, Inc.” instead of “XYZ” for the vendor name.
Are these in fact the same product? That depends on the application. If the vulnerable product were a throwaway product used in the insurance industry, the match might be considered perfect. On the other hand, if the vulnerable product was an electronic relay that could, if compromised, open a circuit breaker and black out a large section of Manhattan, this might not be considered a match at all.
In other words, due to the arbitrary nature of the fields included in CPE names, such as “vendor” and “product name” (both of which can vary substantially, even when the same product is being described), there will always be uncertainty in creating a CPE name. This means that two people could follow the CPE specification exactly, yet create different valid CPE names for a single software product. The NVD has reserved the right for their staff members to create CPE names for vulnerable products described in the text of new CVE records and add them to the records (a process called “enrichment”); however, there is simply no way to know for certain what values the staff member used for the fields in a CPE name they created.
This arbitrariness, along with other serious problems[ii], makes it close to impossible to fully automate the process of looking up software vulnerabilities in the NVD. In other words, someone searching the NVD for vulnerabilities that affect a particular product must guess the values for the fields used by the NVD staff member when they created the CPE name for that product. There is no way to be 100% certain that a product in the real world corresponds to a product described in a CVE record, unless they have identical CPE names.
But that isn’t the worst problem with CPE. The biggest is that, since February 2024, the NVD has drastically neglected their responsibility to create CPE names and add them to new CVE records. This has resulted in more than 50% of CVE records created since that date not including a CPE name(s) for the affected product(s) listed in the record.[iii]
The problem with this is straightforward: a CVE record that doesn’t include a CVE name for the vulnerable product isn’t visible to an automated search, since CPE is currently the only machine-readable software identifier supported by the CVE program and the NVD.[iv] Without a CPE name, the user will have to search through the text in over 300,000 CVE records, although even then there is no such thing as a certain identification (remember “XYZ” vs. “XYZ, Inc.”?).
This is compounded by the fact that the NVD will provide the same message, “There are 0 matching records” when a product truly has no reported vulnerabilities, as when the product has a lot of reported vulnerabilities, but they don’t have CPE names included in them. Of course, human nature dictates that most people seeing that message will assume the former interpretation is correct, when it might well be the latter.
You may wonder why I’m pointing out the above as a serious problem for the CVE Program, when this is mostly the NVD’s fault (and they’re in a different department of the federal government). The problem is that, given the over 300,000 CVE records today - and the fact that new records are being added at an increasing rate (last year, 40,000 were added, vs. 28,800 in 2023) – it is impossible to perform truly automated vulnerability management. I define that as a single process that goes through an organization’s software inventory, looks up all those products in the NVD or another vulnerability database, and identifies all open vulnerabilities for those products (the next action would be remediation, or at least bugging the supplier to patch the vulnerabilities. This can’t be fully automated).
A vulnerability record without a machine-readable software identifier isn’t complete; it’s like giving somebody a car without a steering wheel. Until the CVE Program can ensure that every CVE record has a reliable identifier for any affected product described in the text of the record, they will receive an “Incomplete” record from me.
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] While it would certainly be better to specify a version range in a CVE record than just enumerate affected versions, in fact version ranges are a very difficult problem, as I discussed in this post. It is fairly easy to specify a version range in a CVE record, but, unless the end user has a way of utilizing that range as part of an automated vulnerability management process in their environment, it’s useless to include it in the record in the first place.
[ii] Some of CPE’s problems are described in detail on pages 4-6 of this 2022 white paper on the software identification problem. It was written by the OWAS SBOM Forum, a group that I lead.
[iii] The NVD has somewhat improved their record for enrichment, but it seems a lot of their recent effort isn’t being well directed.
[iv] That will change when the CVE Program starts supporting the purl identifier, although the NVD might not support purl right away (other vulnerability databases probably will support it).