Executive Summary & Key Takeaways
As security professionals, we often live and die by the release cycle of the latest vulnerabilities. In this report, sponsored by F5 Labs, we take a step back and examine the universe of vulnerabilities (defined by the CVE) and how it’s changed in the last 20 years. As you will see, we find some surprising things along the way.
- The CVE landscape has changed substantially in the last two decades, with an increasing number and widening variety of vulnerabilities
- Some of those changes are due to the evolution of technology while some are “genetically modified”, i.e., how data is collected has changed rather than the data itself
- The number of CVEs published is accelerating, and we expect 500 new CVEs to be published in a typical week in 2025.
- New vulnerability territory is being uncovered every day
- Growing number of vendors: vendors publishing their first CVE are increasing at a rate of 18% per year
- Growing diversity of flaws: the number of unique software flaws (CWEs) present in any month’s worth of new CVEs has increased from about 20 to more than 130
- Both new and old territory is being reformed
- The OWASP top 10 has shifted dramatically over time
- The diversity of weakness in software has increased
- The language used in CVE descriptions is changing with less of a focus on Actors and Outcomes, and more focus on Weakness and Requirements
- The severity of CVEs (as measured by the CVSSv3 score) is not increasing
- CVSSv3 has a higher average severity than v2
- BUT the average severity of each hasn’t increased in the last decade
- CNAs and NVD often disagree on the severity of vulnerabilities
- Exploit code and exploitation in the wild has changed
- Older vulnerabilities were likely (sometimes as high as 1/3rd!) to have exploit code in ExploitDB
- Newer vulnerabilities are more likely to have exploit code appear in GitHub, though at a much lower rate (~5%)
- The size of the CISA Known Exploited Vulnerability List continues to grow, both in total size and the percentage of all CVEs
We’ve all been there. After a hard day defending networks against foes—real and imaginary alike—we try to take a break from the big screen and scroll a bit through social media on the little screen1. Then, we see it: that infosec influencer account with the weird eye avatar is posting about a new vulnerability. This one is gonna be big apparently; it affects widely used software and may even be remote executable. There might be proof of concept code available, or maybe it’s already being exploited. Details remain murky for the next few hours of refreshing all of our possible feeds until the CVE drops. Evaluate, cancel weekend plans, soothe C-Suite worries, put out the fire, and start again.
The pendulum swings between the monotony of defending our networks from threats aimed at the backlog of known vulnerabilities and the panic of addressing the next big name brand vulnerability. The monotony and the panic both tend to leave us with a myopic view of individual vulnerabilities, while the overall vulnerability landscape is just a background blur. In this report, sponsored by F5 Labs and completed by the Cyentia Institute, we want to take a step back and try to bring that landscape into focus, and ask a few questions about where we’ve been and where we are going.
In particular, we are going to focus on individual vulnerabilities as they are often at the nexus of our security thinking. Moreover, because of the heroic efforts of those in our community, vulnerabilities are relatively well cataloged via the Common Vulnerabilities and Exposures (CVE) process2 with numerous sources of data about them publicly available. We’ll use this open data to take a retrospective as well as prescient view of the landscape, providing deep, quantified answers to sticky questions such as:
- How fast is the number of vulnerabilities growing?
- What are the most common types of vulnerabilities?
- Are vulnerabilities more severe now than they were before?
- How many vulnerabilities actually have exploit code published?
- How has the language we use to talk about vulnerabilities changed?
We’ll give some answers to the above questions, but along the way, we’ll have to step lightly. The world is a complex place and the way data is collected has changed over time and depending on who exactly is doing the collecting. So we’ll point out the results we think are real bona fide trends, as well as those that are just artifacts of the data collection process. To that end, we’ll try to make some observations about absolutely weird things in the vulnerability landscape.
Before we dive in and try to start to survey the wide, weird world of vulnerabilities, it’s worthwhile to pause for a moment to define exactly what we mean by “vulnerability”. For our purposes, a “vulnerability” means a flaw that has a CVE ID assigned to it. We acknowledge that this is not the full universe of vulnerabilities, but it’s the easiest set to analyze and the one most often used3. Given that we are focusing on the CVE, let’s start with some definitions and examine the history of the CVE as well as a brief overview of some of the data fields from which CVEs are constructed.
- Common Vulnerability and Exposures (CVE) A framework developed at the MITRE corporation for organizing information around computer vulnerabilities.
- Common Weakness Enumeration (CWE) A framework developed at the MITRE corporation for hierarchically organizing the types of software flaws that lead to vulnerabilities. CWE information is included in a CVE.
- OWASP Top 10 A subset of CWEs, published by the Open Web Application Security Project (OWASP), and deemed by it to be the most critical security vulnerabilities.
- Common Platform Enumeration (CPE) A framework developed, again, at MITRE corporation, that enumerates all possible software versions that are affected by a vulnerability, including the type, vendor, product, and version of software affected.
- CVE Number Authority (CNA) An entity that is bestowed with the power to publish new CVEs.
- Common Vulnerability Scoring System (CVSS) A method for assessing a vulnerability's severity.
- Known Exploited Vulnerabilities (KEV) A list of CVEs published by the United States Department of Homeland Security indicating vulnerabilities that are actually being used in the wild.
A Brief History of the CVE
We are not historians here at Cyentia, and so we don’t claim this to be a definitive history of the CVE4. But we do want to highlight some of the important waypoints visited to get to where we are today. One major theme is that the socio-technical process of creating a framework that fits everyone’s use case is a complex one, and it often takes a long time before the stakeholders arrive at something everyone can agree with, or at least not disagree with.
The idea for a framework for gathering information about vulnerabilities was first presented at the 2nd Workshop on Research with Security Vulnerability Databases in January of 1999 by Dave Mann and Steve Christey. Because the question of how to share information about vulnerabilities requires broad community buy-in, a working group was formed to create a more formal framework. Approximately nine months later5, the first CVE list was birthed into the world in September of 1999 with a mere 321 vulnerabilities. My, how things have grown (over 190k have been published since then!); we are now at nearly 200k.
In the early days, there was a lot of necessary wrangling to get buy-in from various different parts of the community (MITRE, vendors, industry practitioners, and governments). The result of this wrangling was that while the MITRE CVE list grew, another database using the CVE framework with a slightly different mission came into existence: the Internet Category of Attacks Toolkit (ICAT)6. ICAT was a NIST project headed by Peter Mell7. Early versions of the ICAT were cheeky, leaning into the “CAT” in ICAT (Figure 1).
In order to strike a delicate balance to keep all the stakeholders happy, the MITRE CVE list stayed just that, a list with the CVE-ID, a short description, and links to references. Meanwhile, the ICAT was able to expand and provide more information and functionality, including search. Today, they are funded by the same source, the US Department of Homeland Security, but are maintained as two separate and distinct programs.
The next few years were fraught with danger for ICAT (while MITRE’s CVE list kept chugging along). Funding from NIST ran out in 2001, but the then-director of SANS, Alan Paller, funded students to analyze the actual vulnerabilities. In 2004, DHS decided to fund ICAT, and the development of the renamed National Vulnerability Database (NVD) was started. The NVD launched in May 2005, and things have grown in size and complexity since then. Without delving into too much detail, here are some milestones taken directly from NVD:
- CVSSv2 is adopted in 2007
- Common Product Enumeration (CPE) is revised to a more recognizable form in 2008, though the full dictionary won’t be incorporated into NVD until 2011
- NVD-specific Common Weakness Enumeration (CWE) views are first introduced in 2007, with revisions in 2016 and 2019
- In 2016, CVE Number Authorities (CNAs) were introduced, allowing software companies and other organizations to define their own CVEs and lighten the load on MITRE and NIST
How the Size of the CVE Landscape Has Grown
One of the first mathematical concepts everyone learns is counting, and even as data scientists we find that counting can be one of the most informative activities we can engage in. As we mentioned in the previous section, the initial MITRE CVE list had a mere 321 vulnerabilities. It’s worth asking what the current state is and how fast that number is growing.
We’d like to add a programming note here: we are going to primarily use the NVD for our data rather than other sources of CVEs. Why? Well, primarily because the NVD is well organized, consistent, publicly and easily available, and does not greatly differ from other sources. While you might be inclined to quibble (I can hear it now…“I know CVE-2014-OMGWTFBBQ was published by MITRE 32.6 hours before it was on NVD and, therefore, all your conclusions must be wrong!”), try not to miss the forest for the trees. Wherever we can, we’ll identify where the data might be biased towards NVD’s particular worldview.
Vulnerabilities Published Per Week
As of December 31, 2022, there were 190,971 vulnerabilities published in NVD. In recent weeks, this has meant hundreds of new vulnerabilities every week. When does a CVE actually become a CVE? Here, and throughout this report, we will refer to a CVE’s publication date, that is, the date that NVD (and usually MITRE) officially recognized the CVE and placed it in the database. We note we only examine published CVEs and do not consider “Reserved” (or “Rejected” or any of the other members of the zoo of MITRE tags) CVEs, i.e., those CVE numbers that a CNA has set aside for potential future use. Only honest-to-goodness published CVEs for us.
So how has the number of CVEs published per week1 grown? Take a gander at Figure 2.