JerryGamblin.com.

The Common Vulnerabilities and Exposures (CVE) program, launched in late October 1999, has not only marked its presence but has become a pivotal force in shaping how we perceive and manage cybersecurity threats.

A Journey Through Time

The CVE program emerged as a beacon, standardizing how vulnerabilities are identified, shared, and mitigated. From its inception with just 321 entries, it has ballooned to over 240,000 records, showcasing a remarkable evolution from simple bug tracking to a sophisticated vulnerability management system.

The Impact of CVE

Over these 25 years, CVE has revolutionized cybersecurity:

• Global Collaboration: CVE’s framework has fostered an international community where vulnerabilities are reported and collaboratively addressed. This spirit of sharing knowledge has directly contributed to enhanced global cyber resilience.
• Standardization: Before CVE, describing a vulnerability could vary wildly, leading to confusion and missed patches. Now, a CVE identifier provides a universal language, ensuring that everyone is on the same page when a vulnerability is mentioned.
• Proactive Defense: By cataloging vulnerabilities, CVE allows for proactive patching and mitigation strategies, turning reactive cybersecurity into a more predictive and preventive practice.

Celebrating Milestones

This anniversary isn’t just about numbers; it’s about milestones:

• Growth: From a nascent project to a mammoth database, CVE’s growth mirrors the expansion of the internet itself.
• Community: Over 400 CVE Numbering Authorities (CNAs) across 40 countries now contribute, showcasing a vibrant, global effort in cybersecurity.
• Innovation: The program has not just adapted but led with innovations like the integration with other standards bodies, enhancing its reach and effectiveness.

Looking Ahead

As we celebrate, we also look to the future. Cybersecurity is an ever-evolving battlefield, with new technologies like AI, IoT, and quantum computing on the horizon. CVE’s role will only grow, adapting to these changes and ensuring that as the digital landscape expands, so will our ability to secure it.

Conclusion

The 25th anniversary of the CVE program is more than a celebration; it reflects how far we’ve come in fortifying our digital lives. Here’s to the CVE program for identifying vulnerabilities and empowering us all to build, innovate, and connect with greater confidence in our digital future. Here’s to another 25 years of vigilance, innovation, and collaboration in cybersecurity.

The Last 100+ Days

The NVD posted the notice below on its webpage in mid-February. Since then, nearly 13,000 CVEs have not been enriched with CWE, CVSS, and CPE data. 

The vulnerability management community was told that it would be addressed at Vulncon this year. At the conference, we were told the enrichment would restart “in the next couple of days” and that a “consortium was being founded” to help guide the NVD. I left hopeful about the NVD’s future and tried hard to present a positive outlook. I spent time defending NVD as the source of the truth at work and in the community, waiting for the enrichment to continue, and closely tracking the backlog as it grew.

I patiently waited for an announcement about the consortium and for the enrichment of CVEs to start again. Neither happened (The NVD did analyze 167 CVEs in April, but 120 CVEs per day were published). On April 25th, the NVD posted an update saying it was still committed to enriching CVEs.

At RSAC in May, CISA announced they would start a program called Vulnrichment and enrich all CVEs that a CNA did not. They have started publishing CVE data they produced in a GitHub Repository and will start publishing it directly to CVE records as an Authorized Data Publisher (ADP). A week ago, I sat through a CVE Automation Working Group meeting where they walked through the plan, and I was once again hopeful that this would help elevate the backlog of CVEs needing enrichment and make their ADP the new source of truth for enrichment data. I started sharing this information and consulting people they would need to update their products to use the new CVE 5.1 Schema to ingest this data.

Yesterday, the NVD posted an announcement on its website stating that it had awarded a contract for additional processing support. The additional support would allow them to return to the processing rates they maintained before February 2024 within the next few months. They will work with CISA to eliminate the backlog by September 30th.

So, Who Is Going To Enrich CVEs? 

In the last 100 days, I have spent a lot of professional equity telling people:

• We Will Know After Vulncon.
• NVD Announced They Will Start Enriching CVEs In A Few Days.
• I Don’t know What Is Going On With NVD.
• CISA Announced They Are Doing Vulnrichment.
• NVD Announced They Will Start Enriching CVEs In A Few Months.

At this point, I don’t know who will enrich CVE data in the future, how they will do it, or whether the data will be correct or useful. This is a terrible place to be.

Every year, I get asked, “How many CVEs do you think will be published this year?“

I am always willing to take a guess, but last year, I read Time Series Forecasting in Python. As I started to read more about the Kalman Filter, I figured it would work great for predicting CVE growth, so I built a simple model to test it out.

2024 Prediction

My 2024 CVE model using the Kalman Filter is predicting 32,600 published CVEs.

Here is the monthly breakdown:

2023 Review

The model for 2023 underestimated the number of CVEs by 1,670, which I felt was really good for the first attempt.

What is the Kalman Filter?

The Kalman Filter algorithm uses a series of measurements observed over time to produce estimates that tend to be more accurate than those based on a single measurement alone. In essence, it helps predict the future state of a system based on its current state and past trends.

What Python Library Did You Use?

I have been using Darts by Unit8 as it is fully featured and easy to implement.

Code

All the code for this blog post is in this Github Repository, and I plan on automating and updating it as I get more time.

2023 marked another year of record growth in CVE data, and I thought it fitting to kick off the new year by delving into these statistics and showcasing some of the more interesting data points.

CVEs By The Numbers

We ended 2023 with 28,902 published CVEs, up over 15% from the 25,081 CVEs published in 2022.

On average, there were 79.18 CVEs published per day.
October was the month with the most CVEs published, with 2,690 or 9.3% of all CVEs for the year.
Tuesdays were the top publishing days, with 6,438 CVEs or 22.3% of all CVEs published.
January 26th had the most CVEs published in a single day, with 348.

CVEs By Month

CVEs By Day Of The Week

Top 10 CVE Publishing Days

CVE Growth

Like every year since 2017, we saw a record-breaking number of CVEs published, with 28,902. a 15.23% increase over 2022. It also means that 13.18% of all CVEs published were published in the last year.

CVSS

The Common Vulnerability Scoring System (CVSS) provides a way to capture the principal characteristics of a vulnerability and produce a numerical score from 0.0 to 10.0, reflecting its severity. The average CVSS score this year was 7.12.

This year, 36 CVEs scored a “perfect” 10.0.

CVE-2023-21928 had the lowest published CVSS score of 1.8.

CPE

Common Platform Enumeration (CPE) is a structured naming scheme for information technology systems, software, and packages to help identify vulnerable software identified in a CVE.

This year, 3,119 unique CPEs were identified in CVEs. The most common was  cpe:2.3:o:google:android:12.0:*:*:*:*:*:*:* that was applied to 547 CVEs.

CVE-2023-44183, a Juniper Networks Junos OS vulnerability, is the CVE with the most CPEs with 240 unique, vulnerable configurations.

CNA

CVE Numbering Authorities (CNAs) are software vendors, open source projects, coordination centers, bug bounty service providers, hosted services, and research groups authorized by the CVE Program to assign CVE IDs to vulnerabilities and publish CVE Records within their specific scopes of coverage.

Today, there are 346 CNAs. This year, 250 of those CNAs published at least one CVE.

The Top 5 CNAs last year were:
Patchstack
VulDB
Github
Microsoft
WPScan

Four of the top five CNAs this year, excluding Microsoft, were purpose-built to report CVEs for open-source projects (VulDB & Github) or WordPress Plugins (Patchstack & WPScan). Those four CNAs published 6,778, or 24.12% of all CVES this year.

CWE

CWE is a community-developed list of software and hardware weakness types. It is a common language, a measuring stick for security tools, and a baseline for weakness identification, mitigation, and prevention efforts.

There are 1,332 CWEs, and 237 were assigned to CVEs this year. CWE-79 was the most assigned CWE and was assigned 4,474 times or 15.48% of all CVEs. NVD didn’t assign a CWE 4,113 times or 14.23% of all CVEs.

Notes

2,112 Rejected CVEs have been removed from the dataset because some CNAs publish and reject any unused reserved CVE IDs, causing an artificially inflated record count. On September 14th alone, 662 were published and then immediately rejected.

This GitHub repository has jupyter notebooks containing all the data and visualizations used in this blog.

CVE.ICU is an open-source project I run that tracks most of the above data points in real-time throughout the year if you are interested in keeping up with the data.

Hacker Summer Camp, as it is colloquially known, is three security conferences that are all next week in Las Vegas. The three conferences that makeup Security Summer Camp are:

• BSides Las Vegas
• Blackhat USA
• DEF CON

While preparing for these conferences, I dug through their schedules and picked out the talks I was most interested in catching.

BSides Las Vegas

BSides Las Vegas is back with a fantastic schedule and is always one of the best community events of the year. I am giving a talk on Wednesday at BSides titled Vulnerability Intelligence for All: Say Goodbye to Data Gatekeeping, which I am super excited about.

Here are a few other fantastic talks I will try to catch:

• Cyber risk: How does cyber events become so costly?
• Enemy at the Gate, and Beyond: Detecting and Stopping Account Takeover
• For Intel and Profit: Exploring the Russian Hacktivist Community
• Honey, is that you? Building test-driven, identity-centric honeypots together.
• Machine Learning for Insider Threats: At the Intersection of Security and Privacy
• Security Data Science Teams: A Guide to Prestige Classes
• The Dark Playground of CI/CD: Attack Delivery by GitHub Actions
• Towards Effective & Scalable Vulnerability Management

BlackhatUSA

Blackhat USA is the “commercial conference” of the three but has a lot of good talks this year. The talks I am looking forward to this year are:

• What Does an LLM-Powered Threat Intelligence Program Look Like?
• Compromising LLMs: The Advent of AI Malware
• Entrepreneur Journeys: What it Takes to Start a Startup

DEF CON

DEF CON is probably the world’s most well-known hacker conference, and this year’s schedule looks impressive.  Here is what I am going to attempt to see this year:

Growing the Community of AI Hackers with the Generative Red Team
Badge of Shame: Breaking into Secure Facilities with OSDP
ndays are also 0days: Can hackers launch 0day RCE attack on popular software only with chromium ndays?
Vacuum robot security and privacy – prevent your robot from sucking your data

Along with these talks, they have these interest-specific villages where I will spend a lot of time. Here are the villages where I know I will be spending time.

• Car Hacking Village
• Blue Team Village
• App Sec Village
• Crypto & Privacy Village

Wrapping Up

While the talks above are the ones that I am looking forward to, my friends have built HackerTracker, which has a complete list of all the talks for the weekend and is worth checking out.

I am also really hoping someone hacks the new Sphere next week.

With the first half of 2023 over, I figured I would take some time and review the data and highlight some of the most interesting data points so far this year. This GitHub repo contains the code for all the data and graphs this blog uses.

By The Numbers

So far this year, there have been 14,129 published CVEs. On average, there were 78.06 CVEs published per day. So far, March is the month with the most CVEs published, with 2,519 or 17.8% of all CVEs for the year. 

January 26th had the most CVEs published in a single day, with 348 or 2.46% of all CVEs.

CVEs By Month

CVSS

The Common Vulnerability Scoring System (CVSS) provides a way to capture the principal characteristics of a vulnerability and produce a numerical score from 0.0 to 10.0, reflecting its severity. The average CVSS score this year was 7.13.

So far this year, 18 CVEs scored a “perfect” 10.0.

CVE-2023-21928, a vulnerability in Oracle Solaris, had the lowest score of 1.8.

CPE

Common Platform Enumeration (CPE) is a structured naming scheme for information technology systems, software, and packages to help identify vulnerable software identified in a CVE.

So far this year, there have been 1,610 unique CPEs identified in CVEs. The most common was cpe:2.3:o:google:android:12.0:*:*:*:*:*:*:* that was applied to 309 CVEs

CVE-2023-20027, a vulnerability in Cisco IOS XE, is the CVE with the most CPEs with 190 unique, vulnerable configurations.

CNA

CVE Numbering Authorities (CNAs) are software vendors, open source projects, coordination centers, bug bounty service providers, hosted services, and research groups authorized by the CVE Program to assign CVE IDs to vulnerabilities and publish CVE Records within their specific scopes of coverage.

Today there are 303 CNAs. So far this year, 198 unique assigners have published a minimum of 1 CVE. To make this confusing, 147 CNAs have not posted a CVE this year, and 124 CNAs not listed as an assigner published at least one CVE.

Top CNAs

The Top 5 CNAs so far this year:

VulDB
Github
PatchStack
WPScan
Microsoft

Four of the top five CNAs this year, excluding Microsoft, were purpose-built to report CVEs for various projects.

CWE

CWE is a community-developed list of software and hardware weakness types. It is a common language, a measuring stick for security tools, and a baseline for weakness identification, mitigation, and prevention efforts.

There are 1332 CWEs, and so far this year, 221 have been assigned to CVEs. CWE-79 was the most assigned CWE and was assigned 2415 times or to 17.09% of all CVEs. NVD didn’t assign a CWE 1819 times or to 12.87% of all CVEs.

Notes

• All data and graphs for this blog post were created using the jupyter notebooks in the GitHub Repo.
• Rejected CVEs have been removed from the dataset because some CNAs publish and reject any unused reserved CVE IDs causing an artificially inflated record count.
• CVE.ICU is a jupyterbook site that I run that has real-time CVE information throughout the year.

Reference Rot (also called linked rot) is when hyperlinks, over time, cease to point to their originally targeted file, web page, or server due to that resource being relocated to a new address or permanently unavailable.

Tod Beardsley from the CVE board gave a talk at the 2023 CVE Global Summit called ‘Link Rot: The Problem and Archiving for Posterity‘ on the problem of reference rot, sadly I was not able to attend, but I was interested in how bad the problem was, so this past week I wrote some code to find out.

Reference Counts

First, I collected the CVE data from the NVD data feeds and parsed all the references.

Here are the high-level numbers:
CVEs: 199,019
Reference Links: 797,474
Average References Per CVE: 4

CVE-2014-0224, an OpenSSL vulnerability, has the most reference links with 303(!?) unique references.

Finding Reference Rot

I knew I could not hand-check the nearly 800,000, so the logical first step was to see how many of the 13,991 unique domains responded to DNS requests using PyNnlookup and Google’s Public DNS [8.8.8.8].

It took over thirty minutes to run the 13,991 DNS lookups, and when done 1,520 of the listed hosts did not respond.

How Bad Is Reference Rot?

Those 1,520 domains account for 109,411 broken links, or 13.71% of all links.

Over 35,000 broken links are in CVE years 2005, 2006, and 2007.

One domain, SecurityFocus.com, is responsible for 82,854 or over 75% of all broken links. The top 5 domains account for over 90% of all broken links.

What Can Be Done?

¯\_(ツ)_/¯

You may be able to point the dead links to the Wayback Machine at archive.org or a similar site, but this will need to be figured out before we lose tons of valuable vulnerability research.

Data

All Reference Domains
All Broken Domains
Broken Domains By CVE Year
All Broken Links With CVE Information
Jupyter Code

Notes

Looking at DNS records is probably the simplest form of checking links and is not 100% foolproof. To get a 100% complete picture of the broken links, you would need to pull the web pages and do some form of data verification that was beyond this project’s scope.

Here is a picture to make my unfurl link look better:

2022 was a record-breaking growth year for CVE data, and I figured it would be a great way to start the new year by going through the data and highlighting some of the most interesting data points. All the data and graphs used in this blog are available in this GitHub repo.

CVEs By The Numbers

We ended 2022 with 25,093 published CVEs. On average, there were 68.75 CVEs published per day. December was the month with the most CVEs published, with 2,426 or 9.7% of all CVEs for the year. 5,414 CVEs, or 21.6% of all CVEs, were published on Tuesdays. June 2nd had the most CVEs published in a single day, with 320.

CVEs By Month

CVEs By Day Of Week

Top 10 2022 Publishing Days

CVE Growth

Like every year since 2017, we saw a record-breaking number of CVEs published, with 25,093, a 24.51% increase over 2021. It also means that 13.06% of all CVEs published were published in the previous year.

CVE Identifiers

A somewhat confusing part of CVE IDs can be the year identifier. It is often assumed that the year represents when a CVE is published, but it represents when it was assigned or when the vulnerability was made public.

I say all that to point out that the “oldest” CVEs published this year belong to BlackICE PC Protection, 20 years after they were made public:

CVE-2003-5001
CVE-2003-5002
CVE-2003-5003

CVSS

The Common Vulnerability Scoring System (CVSS) provides a way to capture the principal characteristics of a vulnerability and produce a numerical score from 0.0 to 10.0, reflecting its severity. The average CVSS score this year was 7.19.

This year 48 CVEs scored a “perfect” 10.0.

CVE-2022-27049, a vulnerability in RaidDrive, had the lowest score of 2.0.

CPE

Common Platform Enumeration (CPE) is a structured naming scheme for information technology systems, software, and packages to help identify vulnerable software identified in a CVE.

This year there were 2,815 unique CPEs identified in CVEs. The most common was cpe:2.3:o:google:android:11.0:*:*:*:*:*:*:* that was applied to 299 CVEs

CVE-2022-22160, a vulnerability in Juniper Networks Junos OS, is the CVE with the most CPEs with 364 unique, vulnerable configurations.

CNA

CVE Numbering Authorities (CNAs) are software vendors, open source projects, coordination centers, bug bounty service providers, hosted services, and research groups authorized by the CVE Program to assign CVE IDs to vulnerabilities and publish CVE Records within their specific scopes of coverage.

Today there are 261 CNAs. In 2022, 200 unique assigners published a minimum of 1 CVE. To make this confusing, 109 CNAs did not publish a CVE this year, and 83 CNAs not listed as an assigner published at least one CVE.

Top CNAs

The Top 5 CNAs last year were:

Github
WPScan
Microsoft
VulDB
Huntr.dev

Four of the top five CNAs this year, excluding Microsoft, were purpose-built to report CVEs for various projects.

CWE

CWE is a community-developed list of software and hardware weakness types. It is a common language, a measuring stick for security tools, and a baseline for weakness identification, mitigation, and prevention efforts.

There are 1332 CWEs, and this year, 236 were assigned to CVEs. CWE-79 was the most assigned CWE and was assigned 3230 times or to 12.88% of all CVEs. NVD didn’t assign a CWE 2835 times or to 11.30% of all CVEs.

Notes

• All data and graphs for this blog post were created using the jupyter notebooks in the GitHub Repo.
• Rejected CVEs have been removed from the dataset because some CNAs publish and reject any unused reserved CVE IDs causing an artificially inflated record count.
• CVE.ICU is a jupyterbook site that I run that has real-time CVE information throughout the year.

The National Vulnerability Database plays a vital role in the CVE publication process that many people may overlook or not know they are responsible for. After MITRE publishes a CVE, the NVD enriches it with data points that make it actionable by security companies and professionals.

Some of these data points include:
CWE
CVSS 3.1 Base Score
CPE

I was recently asked how long, on average, it takes NVD to complete its initial analysis. I looked around for a bit and couldn’t find the information, so I built this jupyter notebook to find out using the NVD Change History API and the very helpful {Initial Analysis} filter the API provides.

After running the notebook for all CVEs published between January 1st, 2022, and November 15th, 2022, the average analysis time takes 5 days 22:14:22 (the Standard Deviation is 3 days 15:42:25). I will leave it to the math geeks to decide which number is more valuable, but either number is excellent considering the growth of CVEs.

The quickest analyzed CVE this year is CVE-2022-43488 at 27 minutes, and the slowest is CVE-2021-35036 at over 213 days.

Since everyone loves a good visualization, here is a quick graph (and code) of the analysis timing.

Note: The notebook is not the fastest, and with the API rate limiting, it took just over 7 hours to run the 22,619 requests. If you are interested in looking at the data, it is all here in a CSV.

For a recent project, I needed all the NVD CVE and EPSS data in Elasticsearch and couldn’t find an easy way to do it, so I built CVElk. CVElk quickly builds a local Elastic Stack using docker compose with the help of a simple shell and python script.

Philipp Krenn from Elastic also contributed an updated dashboard to the project to help with the data visualization.

Want to Help?

The project’s code is hosted on GitHub, and I am always happy to try to implement any improvements and would love to see this become useful to a wide group of people.