Why vulnerability identifiers matter more than ever
Open source developers are spending roughly three times more time on security than they did a few years ago, according to Tidelift’s 2024 survey. That shift reflects a broader industry movement toward treating developers as the first line of defense. For the teams that curate vulnerability data and feed it into the tools developers rely on, that increased attention is both encouraging and demanding.
The GitHub Security Lab team manages the GitHub Advisory Database, which powers Dependabot, code scanning, and npm audit. But the team also does something less visible: it actively creates CVE records on behalf of open source maintainers. Since 2019, GitHub has operated two CVE Numbering Authorities (CNAs)—entities authorized to assign and publish CVE IDs—and the volume of records produced through those channels has grown from 29 CVEs in 2019 (starting with CVE-2019-16760) to more than 1,700 last year.
The data deluge is a sign of progress
The CVE Program published 321 records in 1999. Last year, that number surpassed 28,900—a 460% increase over the past decade—and the trajectory shows no signs of leveling off.
That volume creates a real tension. On one hand, downstream consumers of vulnerability data face information overload, wading through more records than ever to find the ones that apply to their stacks. On the other, this growth represents a fundamental improvement in vulnerability transparency. You cannot remediate a vulnerability you never knew existed, and the industry is getting better at surfacing those facts.
New vulnerability classes ripple through the supply chain
A single novel disclosure often triggers a wave of related findings. Spectre and Meltdown spawned an abundance of speculative execution research. Regular expression denial-of-service (ReDoS) attacks, documented for years, have seen a marked increase in CVE publications since 2021. Cloud-related vulnerabilities are also appearing more frequently—not because cloud computing is new, but because the industry has historically shied away from disclosing issues that users couldn’t remediate on their own. Updated CVE rules and public commitments from major vendors like Microsoft are pushing toward greater transparency in that space. The 2021 OWASP Top 10 similarly reflects growth in categories such as broken access control, insecure design, and vulnerable or outdated components.
Each new vulnerability class demands new mitigation strategies, and the surge of disclosures creates a time-sensitive burden for development teams who must validate, deduplicate, and remediate unfamiliar issues. The problem compounds because those issues rarely stay in your own code. Open source dependencies form the foundation of your supply chain, and transitive dependencies multiply the risk surface considerably. GitHub’s 2020 Octoverse report found that the median JavaScript project directly uses just 10 open source dependencies—but inherits 683 transitive dependencies through them.
Maintainers are taking control of their security data
Since joining the CVE Program as a CNA in 2019, the GitHub open source CNA has become the fifth-largest CVE publisher of all time. That milestone reflects a structural change in how vulnerability data flows through the ecosystem.
For much of the CVE Program’s history, MITRE held the primary role in creating and publishing CVE records. CNAs existed but were limited to assigning IDs until the program expanded their duties in 2016 to include curating and publishing full record details. The program now counts more than 400 CNA partners across 40 countries, and over 80% of CVE data originates directly from those CNAs rather than from MITRE.
That decentralization delivers a practical benefit: CNAs must have a specific scope of coverage, which typically includes software they own or are heavily invested in securing. Subject matter experts control the messaging and detail of vulnerability disclosures for their communities, improving data quality and reducing false positives. For open source maintainers, that means repository security advisories and private vulnerability reporting are direct channels to ensure their communities hear about issues first—and with the right context.
Automation is the only way to keep up
The flood of vulnerability data is a double-edged sword. On one hand, it provides unprecedented visibility into the security posture of the software we depend on. On the other, sifting through that volume manually is no longer feasible. The solution isn't to reduce the data—it's to automate its curation, consumption, and prioritization.
Tracking direct dependencies at scale is already burdensome. Accounting for transitive dependencies makes the problem exponentially worse. Machine-readable software bill of materials (SBOM) formats like SPDX and CycloneDX provide a structured inventory of a project's dependencies, including versions, package identifiers, licenses, and copyright information. SBOMs mitigate supply chain risk by:
- Offering transparency into the dependencies used by a repository.
- Enabling early identification of vulnerabilities.
- Revealing security, license compliance, or quality issues in the codebase.
- Supporting compliance with data protection standards through automation.
On the reporting side, CVE Services has reduced friction for CNAs by providing a self-service web interface for reserving CVE IDs and publishing CVE Records. This data is foundational: it accounts for over 92% of the data feeding into the GitHub Advisory Database. Faster, more efficient publication of CVE information benefits every downstream consumer.
From vulnerability data to automated remediation
GitHub ingests data from vulnerability providers via their APIs, exports its own data in the machine-readable Open Source Vulnerability (OSV) format, and notifies users automatically through Dependabot alerts. The increasing automation of vulnerability reporting has shifted the burden downstream: developers now need automated help finding and fixing vulnerabilities in both proprietary and dependency code.
Automated software composition analysis (SCA) tools like Dependabot identify and mitigate dependency vulnerabilities by updating packages to the latest version or filing pull requests for security updates. Coverage varies by tool: the GitHub Advisory Database and osv-scanner focus on open source software, while grype targets container scanning and file systems. Organizations should verify their SCA solution supports the software types in their production environment. Prioritization features, such as Dependabot's preset and custom auto-triage rules, help manage alert fatigue by determining which issues need immediate attention.
SCA and static application security testing (SAST) complement each other. While SCA addresses open source dependencies, SAST targets proprietary code. GitHub's SAST tools, including code scanning and CodeQL, help identify vulnerabilities in your own code. Copilot Autofix simplifies remediation by providing natural language explanations and suggesting code changes.
As vulnerability management shifts left, open source developers need the tools and education to participate in security. The growing volume of vulnerability data improves awareness but demands automation to manage effectively, particularly given the broad impact supply chain vulnerabilities can have.
