Last updated at Wed, 12 Apr 2023 22:26:51 GMT

On Tuesday, April 24, 2018 at 19:05:31 UTC, the MITRE Corporation published the one hundred thousandth CVE identifier. As near as we can tell, the lucky winner for this dubious distinction was this issue, CVE-2017-2906, reported to MITRE by Cisco Talos on April 20, 2018. The CVE description is quoted below for posterity.

An exploitable integer overflow exists in the animation playing functionality of the Blender open-source 3d creation suite version 2.78c. A specially created '.avi' file can cause an integer overflow resulting in a buffer overflow which can allow for code execution under the context of the application. An attacker can convince a user to use the file as an asset in order to trigger this vulnerability.

Due to this (rather arbitrary) milestone of 100,000 CVEs published, we figured that now is a good time to review the CVE program and take a look at how it’s evolved over time.

Are you more of a stats nerd? Then head over to Bob Rudis's most excellent By The Numbers Post, then come on back.

A Little History: What’s a CVE?

The MITRE Corporation was founded in the pre-internet era, way back in 1958, as “a private, not-for-profit company to provide engineering and technical guidance for the [United States] federal government, ” as quoted from MITRE’s Our History page. In terms of Internet Time, they’ve been around literally forever, so it’s unsurprising that by the time 1999 rolled around, they were the ones in the best position to launch the CVE Project, a curated list of vulnerabilities that affects all sorts of software. That initiative was born in the seminal white paper, “Towards a Common Enumeration of Vulnerabilities,” by David E. Mann and Steven M. Christey, readable here.

This “Common Vulnerability Enumeration” (aka, CVE) was intended to provide interoperability between the growing number of vulnerability databases that were being built by both public and private entities in the early days of vulnerability management in 1999. Back then, we were running into a problem in distinguishing between vulnerabilities when different people and products from different organizations were trying to figure out which vulnerabilities were present on a given system. By then, if you said, “Hey, do we have a way to detect that buffer overflow in Windows NT,” the answer you’d get would be an unhelpful, “Which one?”

In the first year of the CVE Project’s life, we saw 894 vulnerabilities published, according to CVEDetails. That page also has a handy bar chart of CVEs issued by year, and we can see that the rate of new CVEs published exploded in 2017. Did we, as a security industry, just get really good at finding new vulnerabilities, or did software quality just now take a nosedive? Turns out, neither of these suppositions are entirely true.

Distributing CNAs

For most of the project’s life, MITRE and the CERT Division were pretty much the only authorities around issuing CVEs on behalf of other vendors. It had become clear that these organizations were falling behind the rate of vulnerability discovery. Since 1999, there was a steady growth in the rate of vulnerability discovery, since (1) more software was being produced and deployed and (2) the number of researchers and their vulnerability discovery output was increasing. Today, newly discovered vulnerabilities in software routinely make the regular, non-tech-trade news. Yet, we can see from the above-mentioned chart that the rate of CVE assignments meandered around the flat-to-down curve.

This all changed in 2017. In December of 2016, Rapid7 was designated as one of the first new third-party CVE Numbering Authorities, or CNAs. We were invested with the authority to issue our own CVEs for vulnerabilities in other organization’s software upon discovery. Up until that point, there were many product CNAs, such as Microsoft, Apple, Oracle, and the like, but they were only concerned with issuing CVEs that affected their own products.

Today, there are are many such designated CNAs, and the effects on the CVE program have been dramatic. 2017 saw more than twice as many CVEs issued as 2016, and 2018 is on track to eclipse 2017. Moreover, the CVE Project has launched the Automation Working Group, which seeks to make the process of identifying and enumerating vulnerabilities in software easier for everyone involved. One of the products of this group is publishing a pilot GitHub repo chock full of vulnerability data in an easy-to-consume format, which captured the imagination of our [Master] Chief Data Scientist Bob Rudis -- for some tasty nuggets of data analysis on this, hop on over to his By the Numbers analysis of these first 100,000 vulns.

The Future of CVE

Enumerating vulnerabilities in a common format, on its face, is a public good that’s useful for security practitioners, security vendors, and security consumers (in other words, everyone). Of course, every project of this scope and mandate is going to run into some bumps in the road occasionally. On the whole, though, I believe it’s a project worth pursuing.

Clearly, the new federated model of issuing CVEs is having at least the positive effect of the CVE list more closely matching the reality of the vast space of software vulnerabilities. Plus, it’s nice bit of security socialism that this is being pursued under the auspices of a neutral, not-for-profit, publicly funded entity.

While there are many capable people helping out with this effort, we can always use some extra brains tackling the problems facing CVE and secure software development. If you’re a software producer or a security researcher that is interested in becoming a CNA, take a look at MITRE’s How to Become a CNA documentation.