Why there are at least 6,000 vulnerabilities without CVE-IDs

A new investigation suggests that up to 6,000 software vulnerabilities lack CVE-IDs.

In a rather long article in CSO, Steve Ragan explains that in 2015 alone, 6,356 vulnerabilities disclosed to the public didn’t receive a CVE-ID. Ragan bases his claim on the fact that another vulnerability database, VulnDB, shows 14,914 vulnerabilities disclosed in 2015 but within that set, only 8,558 vulnerabilities have CVE-IDs assigned to them. That leaves 6,356 vulnerabilities with no CVE-ID, and likely no representation in a majority of security products.

Common Vulnerabilities and Exposures (CVE) is a standard reporting convention for publicly known information security vulnerabilities. The CVE identifiers (CVE-ID, also called CVE names, CVE numbers, and CVEs) are used to enumerate different vulnerabilities. According to VulnDB, some of the missing CVE-IDs for disclosed vulnerabilities in 2015 are those for software from Adobe (17), Apple (24), Cisco (29), Microsoft (33), MySQL (46), HP (12), IBM (60), Oracle (67—there’s overlap, Regan notes, with MySQL since Oracle’s acquisition), and SAP (174).

By industry vertical, Ragan says there were 130 supervisory control and data acquisition (SCADA) vulnerabilities and 51 medical device vulnerabilities that went without a CVE-ID in 2015.

There’s another problem with the current naming schema. There are 22 CVE Numbering Authorities (CNA). These include Adobe, IBM, Cisco, Red Hat, Google, Apple, and Microsoft—which might account for the missing CVE-IDs.

Being a CNA means the organization controls a block of CVE-IDs that it can use for its own vulnerabilities. The trouble is the connection between MITRE and CNAs is poor. So, logically, MITRE could issue a CVE-ID, and one of the CNAs could use that same number for its own vulnerability. That has happened.

From Ragan’s article, the classic example is CVE-2014-8730, which is a variant of POODLE (or CVE-2014-3566). The problem is that CVE-2014-8730 only represents products from F5, an application technology company in Seattle, Washington. Notes on this CVE-ID assignment state that other “vulnerable implementations should receive their own CVE ID, since this is not a vulnerability within the design of TLS 1.x itself.” Subsequent to that designation, IBM, Cisco, and HP all issued their own advisories for their products related to this issue, and each of them referenced the F5 CVE-ID incorrectly. Regan says this particular case might be an issue, but such mistakes could lead to problems with metrics and vulnerability tracking. There are situations where an advisory might be given less weight in severity because the referenced CVE-ID refers to a vendor or product the organization didn’t use.

The entire article is worth a read. It’s a fascinating look into the bureaucracy around naming and numbering vulnerabilities. However, this confusion is leading others to create their own systems. For example, the Distributed Weakness Filing (DWF) system has been created by Red Hat employee and MITRE board member Kurt Seifried together with researchers Larry Cashdollar, Zachary Wikholm, and Josh Bressers.

Despite its flaws, CVE-IDs remain an important foundation for security researchers and products.

READ NEXT: Closing the CVE gap still a work in progress