The CVE List stands as one of the oldest and most widely-referenced databases of security intelligence operating on the internet today. It appeared on the world wide web in 1999, which places it in history between the Internet Movie Database that transitioned to the web in 1993 and Wikipedia, which started operating in 2001. And like these other historical databases, the reach and impact of the CVE List has expanded and changed over the last 22 years.
Today, it’s become quite strange for IT professionals to refer to a common software vulnerability without mention of its unique CVE ID. After all, most complex and widely used software tends to ship with more than one vulnerability over its lifetime. For example, take the much-discussed Log4j vulnerability, a quick glance at Apache Log4j Security Vulnerabilities shows that there are at least six CVE IDs associated with various versions of Log4j.
These distinct CVE IDs are crucial for people who are in the business of detecting and remediating these vulnerabilities in their own environments. After all, it doesn't do much good to know that the security team has fixed the Log4j vulnerability when in actuality there’s an entirely different bug from the one that attackers are actually exploiting and everyone's talking about on any one specific day.
This agreement on a common, freely available, funded, and cross-product/cross-vendor indexing system for describing a vulnerability makes it possible for people using different security and auditing tools from different vendors and providers to know for sure they're talking about the same thing. Precision matters in security.
The CVE fairy does not exist
I once heard Chris Levendis, program manager of the CVE Program, say something to the effect of: “There is no CVE fairy,” and that numbers don’t magically spring from the ether when new vulnerabilities are discovered and reported. They are described, documented, and assigned identifiers by human agents, just like the articles and statistics on IMDB and Wikipedia.
Internet-wide cataloging projects seem to work best when loads of people from all over the world collaborate in a common framework and make that data freely and easily accessible. Rather than ending up with a bottleneck at the MITRE Corporation, the CVE Program has seen an explosion of new CVE Numbering Authorities, or CNAs. Today, there are more than 200 participating organizations, ranging from huge technology companies with hundreds of products to individual security researchers and research organizations, and everything in between.
Today, if a researcher, software developer, or hacker discovers a new vulnerability in common software, chances are pretty good there's a CNA for that. Therefore, for people who want to help, the first stop for reporting a freshly-minted vulnerability is the CVE List of Partners at cve.org. There, it’s possible for someone to search the hundreds of CNA contacts, pick the one that's right, and fire off a friendly notification that they’ve found a bug and would like to assign it a CVE ID.
To get a CVE ID assigned in a timely manner, it’s helpful to provide at least the common name of the software component, the version number where the problem was noticed, the type of vulnerability being described, and a human-readable, prose description of the vulnerability. There are other minimum requirements for a proper CVE ID (which are listed in record requirement rules), but the specific new CNA talking to should be able to fill those in.
CVE IDs aren't the whole story
CVE IDs are not an exhaustive list, nor atomic — they do not stand on their own. Think of them as pointers to other public resources. Take a look at Log4j vulnerability, CVE-2021-44832. While it’s a short description at just 80 words, there are a dozen or so references to much more exhaustive analyses. The descriptions of CVE IDs don't contain discovery, reporting, exploitation, or fix credits, and they don't give step-by-step instructions on how to fix them or exploit them.
In other words, the identifier gives us just enough information to know what we're talking about, but the guts of the vulnerability and who's been involved in it are documented and discussed across several other websites and mailing lists.
CVE ID’s are a perfect example of the computer engineering axiom of, "do one thing, and do it well." There are continued efforts to extend and expand what CVE IDs "ought" to do, but generally speaking, the CVE Program is very conservative when it comes to extending and expanding the requirements of CVE ID.
That’s not to say that CVE IDs don't have loads of metadata, often enriched by other organizations. One example is a 0-to-10 risk severity score, CVSSv3, shepherded by the National Vulnerability Database. Other bits of data include discovery credits, patch advice, and the like, but those elements remain optional elements in the current CVE data schema and up to the CNAs to provide.
CVE as a community
Finally, the CVE Program has evolved into an extended community. No longer solely located at the MITRE Corporation, the collection of CNAs have made a lot of progress in establishing a group of people who are passionate about research and engineering, vulnerability disclosure, and security education. I am involved in the CNA Coordination Working Group, which handles a lot of the inter-CNA communication and opinion-making as we work with the CVE Program.
For those who care about these issues, take a look at either spearheading an effort in becoming a new CNA or get involved in an existing CNA. Motivated security people looking to get more involved should visit the Partner page at CVE.org. It's an exciting, expansive time in the history of the CVE Program, so join us to help shape its future.
Tod Beardsley, director of research, Rapid7
