Note from Tom:
I have moved from Blogspot to Substack as the main platform for my blog. Because of my long relationship with Energy Central, I will continue to publish my new posts that have to do with the electric power industry (including my posts on NERC CIP) on EC for free. However, if you want to see all of my other new posts (including posts about AI, the cloud, and developments with vulnerability management and vulnerability databases), you need to become a paid subscriber. I’m providing this post for free just to remind you what you’re missing 😊.
A charge of $30 per year (or $5 for one month) gets you a subscription to all my new posts on Substack, as well as 1200+ legacy posts that go back to 2013 (when I started my blog). Close to half of those posts deal with NERC CIP. Please start reading me on both Substack and Energy Central!
On April 15 (a day that often holds bad surprises in the US), a lot of people whose work includes some aspect of software vulnerability management were surprised to learn that the CVE identifiers they have usually taken for granted are in fact created and maintained by a fairly small group of people – called CNAs – that operate under the direction of an even smaller group of people that work for the MITRE Corporation. MITRE is a nonprofit FFRDC – Federally Funded R&D Center. MITRE’s contract is currently paid by the Cybersecurity and Infrastructure Security Agency (CISA), an agency within the US Department of Homeland Security (DHS). The contract has been ongoing in one form or another for a quarter century, when two MITRE researchers came up with the idea of the CVE identifier for vulnerabilities.
On April 15, the news spread rapidly that MITRE had put out a letter – to the Board of CVE.org, the nonprofit that runs the CVE Program - stating that CISA wasn’t going to renew their contract, which would expire the next day, April 16. Not only would the contract not be renewed, but the program would have to shut down – gulp! – on April 16. Nothing like advance notice, huh?
My guess is that the biggest surprise for many people wasn’t that the CVE Program would shut down, but that it even could be shut down. For people who had utilized CVE numbers (e.g., CVE-2025-12345) throughout their professional lives, shutting down the program probably seemed as much of a possibility as shutting down Newton’s First Law or Einstein’s Theory of Special Relativity. As far as they knew, CVE had always been around and would always be around. That was certainly what I thought a few years ago, if I thought about a “CVE Program” at all.
Yet, the CVE Program almost did shut down. Moreover, the fact that this didn’t in fact happen was cold comfort to a lot of these people, since they knew that MITRE has a one-year contract that expires next March.[i] It’s well known that CISA is now being slashed to the bone and a lot of the best people are leaving. Thus, it’s not a stretch to predict that, come next April, CISA will no longer be paying the MITRE contract that covers the CVE Program (as well as related programs).
Is that a bad thing? Not in my opinion. CISA didn’t get involved with day-to-day CVE Program decisions (other than being represented on the Board). They more or less let the MITRE Secretariat (the small group directing the day-to-day operations of the program), along with the CVE.org Board (a diverse group of government and private industry representatives, including representatives of CISA, the National Vulnerability Database and MITRE) run the CVE Program. That was a good thing, because it made the CVE Program quite stable (until it wasn’t on April 15). However, it was also a bad thing because, as with most government programs, the natural inclination of the people running the program is not to make any big changes– and if they do make them, to do so s_l_o_w_l_y and d_e_l_i_b_e_r_a_t_e_l_y.
What will happen to the CVE Program after next March? If there were much uncertainty about that, I would be worried. However, I’m pleased to report that it seems quite likely that the CVE Foundation, a privately run international non-profit organization that was officially launched on April 16 (although it was in the works a few months before that) and is led by members of the CVE Board, will take over the MITRE contract from CISA next March. They will not only maintain the stable leadership that CISA and the CVE.org Board have provided so far (of course, both of those organizations will continue to play an important role in guiding the CVE Program), but they will almost certainly move forward on important initiatives to enhance the CVE Program.
What are those initiatives? The CVE Foundation Board is working now to decide which projects they want to work on first (I’m sure many of those projects have been discussed at length by the CVE Board already), so it doesn’t surprise me that their website doesn’t provide any specifics now.
However, a week after we almost lost the CVE Program, I wrote a post that identified 11 improvements I would like to see in the Program. I still think it’s a good list. Below are the three most important improvements that are needed, although I’ll admit that none of them will be an easy reach:
1. A Global Vulnerability Database
Through most of its 26-year history, the CVE Program has worked closely with the National Vulnerability Database (NVD). One of the most important aspects of this relationship is the fact that the NVD has a special status with respect to the data in CVE Records. They are an Alternate Data Provider (MITRE and CISA are the two other ADPs); this means they are authorized (by the CVE Board, I presume) to add certain data to CVE records.
The NVD is responsible for adding three important pieces of information to those records: CVSS score, CPE identifier(s) for vulnerable product(s) and CWE (Common Weakness Enumeration) identifiers. CVSS and CPE are probably the two most important elements of the CVE Record, but, as I’ll discuss in a subsequent post, these are also the two items most likely to be missing in current records. In addition, CPE is deeply flawed as a software identifier, as the SBOM Forum (now the OWASP SBOM Forum) pointed out in a 2022 white paper, and as the CVE Quality Working Group described in a 2025 paper.
Many people don’t realize that the NVD is a separate program from the CVE Program. It is based in a separate department and has separate funding (the NVD is part of NIST, which is an agency within the Commerce Department, while the CVE Program is part of DHS, although CVE.org is a separate nonprofit organization); moreover, other vulnerability databases, including VulnDB, VulnCheck, Vulners, VulDB (yes, this isn’t the same as VulnDB), OSS Index and others, are also based on CVE. Therefore, the NVD is much more dependent on CVE than CVE is dependent on the NVD.
I will discuss the NVD’s future in a new post coming soon (I’ve discussed the NVD’s problems in many posts over the past 18 months, most recently this one). While I think the NVD should continue to operate, I think it’s imperative to move as quickly as possible toward establishing a truly Global Vulnerability Database, as described in this recent post.
I admit that the GVD will itself be a tall order, perhaps as expensive as the CVE Program itself. However, the CVE Program will always be an underachiever until it can be coupled with a robust global database that isn’t 100% dependent on CPE as a software identifier - which is the case with the NVD today. A vulnerability program can only be called successful if someone can search a vulnerability database for a particular software product and have a reasonable chance of learning about most of the vulnerabilities that affect that product/version. Currently, a user of the NVD doesn’t have such a reasonable chance, especially given the NVD’s problems that started on February 12, 2024.
Since the GVD will be a big undertaking in its own right, I’m not expecting it to be funded through an appropriation tucked away in some obscure corner of the CVE Foundation’s budget. It will most likely need to be funded by a separate international nonprofit, which – like the CVE Foundation and IANA (which assigns IP addresses and runs DNS) – is open to contributions from government agencies and private sector organizations worldwide, without being subject to control by any of them.
2. What should be the real goal of vulnerability management?
I have always felt that, while it’s interesting to analyze and comment on individual vulnerabilities, what a software user really needs to know is which of the (currently) 300,000 CVEs has been identified in each software product they use, whether they use 5 or 500,000 products. The only way a software user can achieve this is through a fully automated tool that does the following, for each software product/version in use in their environment:
A. Searches a vulnerability database for the product name and version. The database can be the NVD (or one of the databases that are based on the NVD but enhance it). It can also be one of the open source vulnerability databases, of which there are many (the two biggest are probably OSV and OSS Index); even better, it can be a combination of vulnerability databases, since no vulnerability database contains all vulnerabilities that apply to all software products (that’s what the Global Vulnerability Database aspires to do by being a federation of existing databases, although I’ll be the first to admit it will be many years before it comes close to achieving that goal).
B. If the product name and version number being searched for can’t be found in a major vulnerability database, the only alternative is for the tool to craft a machine-readable software identifiers that include the product name and version number, then search a major database using that identifier. If you’re searching the NVD or a database built on top of the NVD’s data, CPE is the only usable software identifier. However, if you’re searching one of the open source software databases, you would normally use the purl identifier, which is the primary identifier used to identify open source software packages (OSV is the number two identifier for open source software). If a user knows the package manager from which the software was downloaded, as well as the package name and version string in that package manager, the user or the tool should (barring an error) always be able to create the unique purl for that package – and the purl they create should always match the one used by the CVE Numbering Authority (CNA) that created the CVE record that contains the purl[ii].
C. However, purl primarily supports open source software products available in package managers; it doesn’t currently support most commercial software, nor does it support open source software that isn’t available in a package manager (or similar repository). These other two product types can only be identified today by using the CPE identifier supported by the NVD and other vulnerability databases based on the NVD (although there is now a proposal to expand purl to cover commercial software, using a new purl “type” called SCID).
D. As I mentioned earlier, CPE is not a reliable identifier. The user is likely to run into a lot of false negatives when trying to search based on a constructed CPE, since there is no definitive method for crafting a CPE identifier (for example, should the product name be “Microsoft Word”, “Word”, or “Office Word”? The CPE specification provides no guidance on making that decision, yet the vendor name is a required field in CPE. Purl doesn’t require a vendor name, so it avoids the many ambiguities regarding that concept).
Problems like those described in this post mean there can currently be no fully automated tool to perform the above steps. However, let’s assume there is such a tool and that the user has successfully searched one or more vulnerability databases; thus, they have learned about most of the vulnerabilities that are found in most of the software products they utilize. What will they do with this information? Ideally, they would be able to feed it into a fully automated process running in their organization’s network to perform tasks like patching.
If this process were possible, it could show, for each device in the environment like a server, which vulnerabilities are applicable to a software product installed on the device; the user could then just press a button to apply every patch for a vulnerable software product to the device on which the product is installed.[iii]
However, from what I’ve heard, a fully automated end user product like what I’ve just described is a fantasy that is unlikely to be realized anytime soon. There are many reasons why this is the case, but probably the most important is the “naming problem”: the fact that it’s currently very hard to assign a definite identifier to a particular software product/version, since most software products are found under different names in different contexts. There are many manifestations of this problem, including several that have already been mentioned in this post:
1. The fact that CPE is an inherently unreliable software identifier, as described on pages 4-6 of the white paper on software naming written by the OWASP SBOM Forum in 2022.
2. The fact that purl only works well in controlled namespaces. For example, the name of an open source package made available in a package manager is controlled by the operator of the package manager; if the software itself hasn’t changed, the name in the package manager should never change[iv]. However, along with commercial software, open source software that is not included in a package manager or similar repository cannot currently be identified using purl.
However, even though the naming problem is a big obstacle, that doesn’t by itself excuse not even trying to fully automate end user software vulnerability management.
3. How can intelligent devices be identified?
As mentioned earlier, commercial software can currently only be identified using CPE. By the same token, intelligent devices can currently only be identified with CPE. The problems with CPE that were discussed in this 2024 blog post all apply when CPE is used to identify intelligent devices, as well as when it identifies software products.
In addition, there are several serious problems with vulnerability management in intelligent devices, which are unique to such devices; these problems aren’t directly related to CPE. I described these in depth in Chapter 5 of my 2024 book, An Introduction to SBOM and VEX; they include:
A. Very few intelligent device makers[v] report vulnerabilities to the CVE Program at all; the result is that searches of the NVD for vulnerabilities in devices will usually yield a false negative. Most users will celebrate this result as meaning their device doesn’t have any known vulnerabilities, when in fact it may be loaded with them (for example, an estimated 40,000 in a single device, as I reported in this 2022 post).
B. Many intelligent device makers only patch vulnerabilities when they perform a full update of their device (i.e., they replace all the software at once, including all third-party products. Devices often run on a third party OS like Microsoft Windows™ 7 or VxWorks™. They also usually include lots of open source software). This by itself wouldn’t pose a problem if the device were updated more than every 1-2 years; that is often the case, even with medical devices. While most device makers will issue a separate patch for a very serious vulnerability like log4shell, doing this is quite expensive; they’re usually reluctant to do this quickly, if at all.
C. Not only do most device makers not report vulnerabilities to CVE.org, but they often don’t usually report them to their own customers until they have been patched – and as I just mentioned, a device vulnerability may not be patched for one to two years, if ever.
To summarize this post, CVE’s future is bright, as long as the CVE Foundation takes over from CVE as the funder for the program, and as long as they try to tackle the hard problems that the CVE Program has so far not even considered fixing.
If you would like to comment on what you have read here, I would love to hear from you. Please email me at [email protected] or comment on this blog’s Substack community chat.
[i] Don’t ask me why the previous contract expired in April, but the new one expires in March. That stuff is above my pay grade.
[ii] As of this writing, the only software identifier that can be included in a CVE record is CPE. However, purl, which I have been advocating for since 2022, is likely to be supported by the end of 2025.
[iii] There could be other outcomes of the automated user process. One could be providing a list of vulnerabilities identified in a software product/version used by the organization, for which the supplier has yet to issue a patch. The user organization could feed the entire list to the software supplier and ask when they plan to make each of those patches available – or explain why they have decided not to patch any vulnerability for which they have not issued a patch. Of course, there are many legitimate reasons why a software supplier might decide not to patch a vulnerability, such as the fact that it has a low CVSS score.
[iv] The proposal to expand purl to support commercial software products is based on having the software supplier create an authoritative “SCID tag” for each product and version that they support; this tag includes their choices for product name, version string and vendor name. If the proposal is accepted, these tags will be widely distributed and made freely available. Someone wishing to create an authoritative purl for a commercial product will always be able to do so if they have a copy of the supplier’s SCID tag for that product/version.
[v] Two notable exceptions – and I know there are others – are Cisco and Schneider Electric, who both have reported probably thousands of vulnerabilities (remember, until the CVE Program supports reporting vulnerabilities for version ranges, each vulnerability needs to be reported separately for each affected version of a single version. Thus, if a vulnerability affects 50 versions of Product A, each version should be listed in the CVE record – although a single record could list all 50 affected versions, as well as versions of other products that are affected by the came CVE).
On the other hand, in my book I pointed out that I could find only two of the top ten medical device makers that had reported more than a handful of vulnerabilities in any of their devices to the CVE Program – and both of those makers were a part of a huge manufacturer that makes many types of intelligent devices; this made it impossible for me to determine whether they reported any vulnerabilities for medical devices, and if so how many.