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

Introduction

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 screen¹. 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) process² 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.

The Basics

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 used³. 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.

Glossary

• 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 CVE⁴. 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 later⁵, 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)⁶. ICAT was a NIST project headed by Peter Mell⁷. Early versions of the ICAT were cheeky, leaning into the “CAT” in ICAT (Figure 1).