Is CVE.org on the chopping block?

I’ve been writing a lot about problems with the National Vulnerability Database (NVD) lately. It didn’t occur to me that there might be similar (although not directly related) problems at CVE.org, which used to be called MITRE. However, I’ve learned that may be the case – and the implications of that would be far more significant than the implications of the NVD’s problems. Since a lot of people don’t understand that these are two different agencies, I’ll provide a Cliff Notes™ summary of them.

CVE.org: Before 1999, software vulnerabilities were identified and classified differently in different communities, e.g., developers working with a particular language. This made it hard to have general discussions about vulnerabilities, since two people could never be sure they were discussing the same vulnerability.

To address this issue, two researchers from the consulting company MITRE proposed a unified vulnerability classification scheme called CVE, which stands for “common vulnerabilities and exposures”. That led to the introduction of the first “CVE list” in 1999. CVE took off quickly, and soon vulnerability disclosures all over the world included CVE numbers.

CVE.org’s most important function is recruiting and managing the CVE Numbering Authorities (CNAs), of which there are 447 today (they include software developers like Microsoft, Oracle, Red Hat, Schneider Electric and HPE, as well as organizations like GitHub and ENISA). These are organizations that are authorized to assign new CVE numbers to vulnerabilities, then create a CVE Record for each vulnerability. The CVE Records are made available in the CVE.org database; they are also forwarded to the NVD and other vulnerability databases that are based on CVE.

CVE.org was formerly known just as MITRE, and many people continue to use that name today. This is not inaccurate, since I believe that 100% of the staff members of CVE.org are MITRE employees. However, those staff members now report to a nonprofit board composed of public and private sector representatives.

The NVD: The NVD also started operating in 1999, although not under that name – it was originally titled “ICAT”. In 2008, NVD initiated the CPE (Common Platform Enumeration) software identifier and started adding “CPE names” to CVE Records from MITRE. I’ve written many times about the shortcomings of CPE, starting with this OWASP SBOM Forum paper in 2022.

The most serious shortcoming recently is that, starting last February, the NVD drastically slowed the process by which they add CPE names to new CVE Records, with the result that in 2024 fewer than half of new CVE Records included a CPE name. Now, the NVD seems to have almost stopped adding them altogether. Since an automated search – e.g., using the search bar - for vulnerabilities that apply to a particular software product will not discover any CVE that does not include a CPE name, this means searches will miss far more than half of the CVEs that might have been identified for that product since February 2024.

To get back to the subject of this blog post, while I have written about the NVD’s problems extensively since they began more than a year ago, I have never even considered the possibility that we should be concerned about CVE.org. That is, until this week, when Steve Springett, leader of the OWASP Dependency Track and CycloneDX projects, emailed me this link to a Reddit chat entitled “What is happening at MITRE?”

The chat can be summarized by saying that many people, both CNAs and bug researchers, have noticed that the time it takes MITRE (CVE.org) to respond to new vulnerability reports has increased substantially in recent months. The people in the chat identified various possible reasons why these slowdowns are occurring, but nobody pointed to some definitive event that might have caused them.

I’m not going to speculate on the reason for the slowdowns, either. However, I want to point out that if CPE.org goes into an extended slowdown like the one at the NVD, the consequences for the software security community, and especially for the vulnerability management community, will be much more serious.

In the NVD’s case, there are ways to get around the fact that a CVE Record doesn’t include a CPE name. One way is to start to implement an alternative software identifier in CVE Records. CPE will probably always be an option for CVE Records, but purl should be another option. In fact, I am proposing a project to accomplish exactly that: make it possible for purls to be included in CVE records and utilized for lookups in CVE-based vulnerability databases.

But what will happen if CVE.org stops performing its most essential function: facilitating the production of vulnerability reports (CVE Records) by CNAs? There is literally no other way that those vulnerabilities will be made public, at least in a standardized manner (i.e., using the CVE Record Format). Of course, software developers will continue to report vulnerabilities to the users of their products, but since those reports aren’t standardized, we’ll be back in the same position as in 1999: there will be many different vulnerability reporting formats, but no common one. Truly automated software vulnerability management will once again be impossible.

What can we do to prevent this from happening? Since nobody in the chat could point to a definite cause of the problem, there’s no way to identify a fix for it. However, I want to point to a general cause, which might show us what the long-term fix is.

The general cause can be summarized by saying, “This is what can happen when government agencies, subject to political control, are responsible for carrying out vital technical functions.” Governments change regularly. Since each government is sovereign and guards its privileges jealously, there’s simply no way to guarantee that any practice or rule that a government agency puts in place today will survive tomorrow, let alone when the next administration takes over and imposes its own practices and rules.

Of course, both the NVD and CVE.org, for all their problems, would never be in anything close to their current form were it not for their both being government agencies; we should be grateful for that. However, maybe the time has come to think bigger than what’s in place today. I would like to propose that:

1.      A new supernational “software vulnerability authority” be created. It will be funded by assessments on governments that want to participate, as well as donations by private sector organizations with a stake in software security (of course, it’s hard to think of any organization today that doesn’t have a stake in software security). The vulnerability authority will include representatives from private and public sector organizations worldwide; it will not have special ties to any one government[i].

2.      The software vulnerability authority will create and operate a new database intended to replace both the NVD and CVE.org databases (this is referred to as “the replacement database” below). This new database will include vulnerabilities identified with CVE numbers and software products identified with CPE names and/or purl identifiers[ii].[iii] The database will include all data that currently exists in the NVD and CVE.org, as week as new CVE Records that are created after the cutover to the new database.

3.      The vulnerability authority will set up an organization like CVE.org that manages organizations that report vulnerabilities (identified in products that the organization developed, products that others developed, or both). These will probably be like the CNAs today, although there would need to be changes to that program. Most importantly, the reporters need to be paid, since today it is hard to incentivize CNAs – all of whom have day jobs - to implement improvements that require a substantial investment of time.

4.      Existing vulnerability databases (such as OSV, OSS Index, GitHub Security Advisories, Python Packaging Advisory Database, VulnCheck, VulnDB, VulDB, etc.[iv]) will be encouraged to continue their current work. These databases will continue to be accessible individually, but there will also be a central “intelligent front end”, through which a user can access datapoints in these databases. The intelligent front end will also allow access to data in the replacement database.

5.      The front end (which I call the “Global Vulnerability Database” or GVD) will manage all interaction between a user and the individual databases that make up the GVD.

6.      The user will be able to enter queries that use one or more vulnerability identifiers (CVE, OSV, GHSA, etc.) and one or more software identifiers (CPE, purl, PyPI Package, etc.). The front end will parse the user’s query into queries to one or more individual vulnerability databases and return all response(s) to the user.

7.      If a user enters a query that contains multiple software identifiers, vulnerability identifiers, or both, the GVD will not attempt to “harmonize” the response by translating one type of identifier into another. For example, if the user requests all vulnerabilities that affect a software product and identifies that product using a CPE name, the GVD will not display any CVE Record that contains just a purl. This is because, in many if not most cases, it is impossible truly to “translate” one identifier into another. If the user knows both the CPE name and the purl for a product, they will learn about all CVEs that affect that product only if they include both identifiers in their query.

Of course, the Global Vulnerability Database is just one alternative for replacing the NVD with a much more robust and universal vulnerability database. When I first started talking about the GVD more than a year ago, it seemed there would be plenty of time to discuss all the nuances, before considering actual deployment.

However, the problems with the NVD, and now possibly with CVE.org, are sending a clear signal that it’s time to start talking about what’s going to replace them. It’s clear that we shouldn’t replace them with another US government-run effort. Been there, done that, got the T-shirt. The replacement needs to be truly global and truly universal.

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.

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] A model for this authority might be IANA, the Internet Assigned Numbers Authority. That organization manages the DNS program worldwide, as well as assignment of IP addresses.

[ii] If one or more other software identifiers become popular in the future, they could be accommodated as well.

[iii] Besides software and firmware, the NVD also displays vulnerabilities found in intelligent devices. That program needs to be substantially rethought, but it needs to be continued in some form - probably in a separate database for devices. The OWASP SBOM Forum’s 2022 white paper described (on pages 12 to 14) a different naming system for devices, based on the existing GTIN and GMN identifiers used in international trade. CPE is not a good identifier for the device itself (meaning the complete set of software and firmware products installed in the device, which in my opinion should be how device vulnerabilities are reported), although individual software products installed in the device can be identified with CPEs.

[iv] The NVD and CVE.org will be discontinued, since all their current data will be included in the replacement database.