GitHub Advisory Database hits record CVE volume in 2024

Key Takeaways

• CVE disclosures exceeded 40,000 in 2024, straining vulnerability tracking infrastructure
• Over 500 CVE Numbering Authorities now issue identifiers, up from a handful a decade ago
• GitHub's curation team works to filter signal from noise as automated discovery tools flood the system

The GitHub Advisory Database processed a record number of vulnerability disclosures in 2024, with CVE publications exceeding 40,000 for the first time. Madison Ficorilli, staff security manager at GitHub who leads the advisory database curation team, detailed how her team handles this surge while maintaining data quality for the millions of repositories that depend on accurate vulnerability information.

Why is vulnerability volume breaking records?

Three forces are converging. First, automated vulnerability discovery tools now scan codebases at scale, flagging issues that would have gone unnoticed five years ago. Second, the number of CVE Numbering Authorities, the organizations authorized to assign CVE identifiers, has grown past 500. A decade ago, only a handful existed. Third, regulatory and compliance pressure has pushed more companies to disclose vulnerabilities formally rather than patch them quietly.

The result: 2023 saw 28,902 CVEs published, and 2024 blew past that with roughly 15-20% year-over-year growth. This isn't a temporary spike. It's the new baseline.

What does the curation team actually do?

Raw CVE data is often incomplete, inconsistent, or wrong. Ficorilli's team reviews incoming advisories, verifies affected package versions, maps vulnerabilities to specific ecosystems like npm or PyPI, and enriches records with actionable remediation guidance. This curation is what makes Dependabot alerts useful rather than noisy.

Without this layer, developers would face two bad options: ignore alerts because too many are false positives, or waste hours investigating every notification. Neither works at scale.

Ficorilli co-chairs the OpenSSF working group on vulnerability reporting and response, and she sits on the CVE Program Board. This gives her visibility into systemic problems across the industry, not just GitHub's corner of it.

The infrastructure strain is real

Earlier in 2024, concerns surfaced about MITRE's funding for the CVE Program itself. The program, which has assigned vulnerability identifiers since 1999, operates on government contracts that require periodic renewal. Any disruption would cascade through every vulnerability database, scanner, and security tool that relies on CVE as the common identifier.

GitHub's Advisory Database is downstream from CVE, but it's also a primary source for many developers. When CVE data quality degrades, GitHub's curation team absorbs extra work. When CVE volume spikes, they absorb that too.

How should engineering teams respond?

More vulnerabilities doesn't mean your code got worse overnight. It means the industry got better at finding and disclosing issues. The practical response is triage discipline: not every CVE requires immediate action.

• Filter by exploitability. A vulnerability in a dev dependency that never runs in production is lower priority than one in your web framework.
• Track EPSS scores. The Exploit Prediction Scoring System estimates the likelihood a vulnerability will be exploited in the wild.
• Automate where possible. Dependabot, Snyk, and similar tools can open PRs for straightforward updates. Reserve manual review for complex upgrades.

The teams that struggle most are those treating all vulnerabilities as equally urgent. That path leads to alert fatigue and, eventually, ignoring real threats.

What's next for vulnerability disclosure?

Ficorilli's work at the OpenSSF suggests the industry is moving toward better coordination between CNAs, faster enrichment of vulnerability data, and clearer standards for what constitutes a disclosure-worthy issue. None of this solves the volume problem, but it might make the flood more navigable.

The underlying tension remains: security researchers and automated tools are finding vulnerabilities faster than most organizations can fix them. Whether that gap narrows depends on tooling improvements, hiring in security roles, and whether leadership treats vulnerability management as infrastructure work rather than a checkbox.

Frequently Asked Questions

What is the GitHub Advisory Database?

A free, open database of security vulnerabilities that integrates with Dependabot to alert developers when their dependencies have known security issues. GitHub curates the data to ensure accuracy and actionability.

How many CVEs were published in 2024?

Over 40,000, making it a record-breaking year for vulnerability disclosures. This continues a trend of 15-20% year-over-year growth.

Why are CVE numbers increasing so rapidly?

Automated discovery tools, more CVE Numbering Authorities (now 500+), and regulatory pressure for formal disclosure have all contributed to the surge.

How should teams prioritize vulnerability remediation?

Focus on exploitability, use EPSS scores to assess real-world risk, automate simple updates, and reserve manual review for complex or critical issues.

Source: The GitHub Blog / Madison Ficorilli