CVE woes lead some to seek alternatives

A recent discussion of problems with the Common Vulnerabilities and Exposures (CVE) system for security vulnerabilities—coupled with some efforts to supplement or supplant it—has led some to wonder about its future. The problems stem from the difficulty—sometimes impossibility—of getting CVEs assigned for real vulnerabilities. That, in turn, has led some to stop even requesting CVE numbers for vulnerabilities that they find, which further reduces their usefulness.

The system of assigning CVE IDs has been around since 1999—run by the MITRE Corporation. It was set up to provide a way for researchers, users, and others to track specific vulnerabilities, but has been seen as declining in quality over the years. For example, there are many CVE entries that have been assigned but simply show "RESERVED" with no details, which makes those entries less than entirely helpful.

The IDs do provide a way to refer to specific vulnerabilities, but that only works if the CVEs get assigned properly. As Kurt Seifried, who is part of the Red Hat security response team, put it on the oss-security mailing list, there is reason to worry about that:

Beyond that, though, he has heard "about people that may have given up asking for CVEs and publicizing their work at all". He also pointed to a message from Hanno Böck showing his inability to get a CVE assigned for a flaw in the implementation of a cipher used in TLS 1.2. The request was denied because it was "outside the scope of CVE's published priorities". Seifried concluded his message by noting that this new CVE policy that was cited in the message to Böck has two levels of coverage for the priority of CVE assignments, which is something he called "tiered coverage". That policy may lead in undesirable directions, he said:

Others who posted in the thread largely agreed with Seifried's concerns. Others echoed Böck's experience and noted that they had given up even trying to get CVEs for the vulnerabilities that they find. The process to request a CVE ID is in place, but it isn't smoothly functioning these days. Adam Caudill summarized some of the problems:

Caudill (and others) called for a new system of some sort. A participant known as "Tim" posted some detailed thoughts on what a new system might look like. As it turns out, though, Alexander Peslyak (better known as "Solar Designer") had created a bare-bones system to assign OVE IDs (OVE presumably stands for "Openwall Vulnerability Entries"). This assignment mechanism does no verification and simply assigns an ID; it is meant to be a friction-free mechanism to get an ID without needing vetting of any kind.

While the benefit of being able to get IDs quickly and easily was of interest, several in the thread were looking for more. Features such as allowing entries to be updated with more information or be curated in some fashion were mentioned. Solar Designer said that he didn't want to add more features, but encouraged others to pursue that path. As part of that discussion, Tim noted a major problem that he has seen: link rot for advisories and other detailed information. As he put it:

That led "halfdog" to propose a blockchain-based database to contain the vulnerability information, with "proof of work" providing a means to allocate the IDs. In the proposal for a "Distributed Cryptoenhanced Vulnerability Enumeration" (DCVE), there are provisions for storing some information with each entry, though it would not seem to completely eliminate the problem that Tim described.

There was also a pointer in the thread to the Open Vulnerability ID (OVI) system, which is another ID-assigning mechanism.

It's not clear how much traction any of those systems mentioned would actually get, at least partly because they are entirely separate from the CVE ID namespace. Another project, which was announced by Seifried on the list, is the Distributed Weakness Filing (DWF) system. It directly incorporates CVE IDs into its database, so that DWF-2016-NNNN is the same as CVE-2016-NNNN. Other vulnerabilities that did not have CVEs could use numbers outside of the CVE numeric range (which is now arbitrarily long, but has never gone beyond four digits—yet). The DWF project, Seifried noted, is not part of his Red Hat duties; it is a side project that he and others are working on.

DWF provides a number of different ways to get an ID, starting with just trying to get a CVE number as usual, through requesting one from a DWF Number Authority (DNA), to changing the project's database file and making a pull request on GitHub—or by simply emailing the project. As he said in the announcement: "I want to reduce the time and effort needed to get identifiers, something best achieved by pushing assigning out to as close to the vulnerability discover/handling as possible".

So far, there has been little public reaction to the DWF announcement, but it certainly seems to be the furthest along in terms a new system. It complements the existing CVE system, while also setting up something that could replace it someday if the CVE system continues down its current path.

It seems clear that the CVE system is breaking down in various ways. The tiered coverage approach that MITRE has chosen does not look likely to help it back onto a path where it will be the definitive resource for vulnerability IDs. It's also unclear whether any of the proposed alternatives will truly take off, but the free-software community would seem to be a likely candidate to start heading toward some alternative. If independent security researchers make the same choice, we could be seeing the beginning of the end for CVEs—though it is hard to imagine that system fading away completely.