In 2016, the National Vulnerability Database logged 6,447 new CVEs for the entire year. In 2024, that count crossed 40,000 — a sixfold jump in less than a decade, and one driven overwhelmingly by growth in open source software. Over the same stretch, npm went from roughly 250,000 packages to more than 3 million, PyPI passed 600,000 projects, and a typical production application went from pulling in a few dozen dependencies to several hundred, most of them transitive and unreviewed. Along the way came a string of incidents that reshaped how the industry thinks about risk: left-pad (2016), event-stream (2018), the SolarWinds Sunburst campaign (2020), Log4Shell (2021), and the xz backdoor (2024). Ten years of open source vulnerability trends don't just describe more bugs — they describe a supply chain that grew faster than its own tooling, and is only now catching up.
How Much Has Open Source Vulnerability Volume Actually Grown?
Total published CVEs grew roughly sixfold between 2016 and 2024, from about 6,447 to over 40,000, according to NVD's own yearly tallies — and the growth wasn't linear. It held in the 14,000–17,000 range from 2017 through 2020, jumped to over 20,000 in 2021, and then accelerated hard after 2022, closing 2023 near 29,000 and 2024 above 40,000. That acceleration tracks almost exactly with dependency graph size: the average npm project now resolves 79 transitive dependencies for every one it declares directly, per multiple dependency-graph studies from the last few years, and GitHub's own Octoverse reporting has repeatedly shown that well over 90% of repositories depend on open source components. More packages and deeper graphs mean more surface area to scan, and more scanning — GitHub Advisory Database launched in November 2019, OSV.dev standardized machine-readable advisories in 2021 — means more of what was always there finally gets recorded as a CVE.
Is Open Source Actually Getting Less Secure, or Just More Scrutinized?
It's mostly more scrutinized, though the two forces are tangled together in the data. The raw CVE curve looks like a security crisis, but a large share of the increase is explained by supply-side changes: bug bounty programs multiplied through the 2018–2022 window, the OpenSSF (founded 2020) funneled funding into fuzzing and audits for critical projects, and CNA (CVE Numbering Authority) participation roughly tripled between 2016 and 2024, meaning far more organizations can now mint their own CVE IDs instead of routing everything through a handful of gatekeepers. At the same time, the underlying exposure genuinely did grow — deeper dependency trees mean a vulnerability in one obscure transitive package (think event-stream's single malicious dependency in November 2018, which reached the Copay Bitcoin wallet) can now propagate to thousands of downstream applications that never directly chose that code. Both things are true at once: the ecosystem is better at finding problems, and it has more problems to find.
Why Do the Same Vulnerability Classes Keep Reappearing?
Because the causes are structural, not incidental — the same handful of CWE categories (injection, unsafe deserialization, path traversal, prototype pollution) have topped annual severity reports for over a decade because they're baked into how popular languages and package ecosystems are designed to work. JavaScript's prototype-based object model produced high-profile prototype pollution CVEs in lodash in both 2018 and 2020, years apart, in the same conceptual flaw. Insecure deserialization has powered major incidents from 2015's Java "gadget chain" wave through repeated Log4j-adjacent CVEs in 2021–2022. Typosquatting and dependency confusion — first demonstrated at scale in a 2021 research disclosure that placed malicious packages ahead of internal ones by version number alone — has kept resurfacing every year since, including waves against PyPI and npm in 2023 and 2024. Language and package-manager design choices made a decade or two ago are still generating fresh CVEs today, which is a strong signal that the fix has to happen at the ecosystem-tooling layer, not one advisory at a time.
What Actually Changed After Log4Shell and the xz Backdoor?
Two incidents did more to rewire supply chain security policy than any single year of CVE volume — Log4Shell (CVE-2021-44228, disclosed December 9, 2021) and the xz backdoor (CVE-2024-3094, discovered March 29, 2024). Log4Shell showed how one ubiquitous, deeply nested logging library could put a critical-severity, trivially exploitable flaw into an enormous share of enterprise Java applications overnight; it directly accelerated the U.S. Executive Order 14028 push for software bills of materials and fed into Sonatype's finding, as late as December 2023, that roughly one in four Log4j downloads were still pulling a vulnerable version two full years after the fix shipped. The xz incident was different in kind: a patient, multi-year social-engineering campaign against a single burned-out maintainer resulted in a backdoor inserted directly into liblzma with nation-state-level sophistication, discovered essentially by luck (a Microsoft engineer investigating slow SSH logins). Together, the two events shifted the conversation from "scan for known CVEs" to "verify who touched this code and how it got here" — the reasoning behind SLSA provenance levels, Sigstore signing (both formalized in 2021), and the sudden 2024 industry-wide interest in maintainer trust and commit provenance.
Is the Ecosystem Getting Faster at Fixing Things, or Just Faster at Finding Them?
Both, and unevenly — attackers have compressed their side of the timeline faster than defenders have compressed theirs. Mandiant's annual time-to-exploit analyses have tracked median time from disclosure to active exploitation shrinking from roughly two months in the 2018 dataset to well under a week by 2023, meaning the window between "CVE published" and "CVE weaponized" has nearly disappeared for high-value targets. Meanwhile Sonatype's State of the Software Supply Chain reports documented confirmed malicious open source packages rising from a few hundred a year around 2019 to more than 500,000 logged in 2024 alone — attackers are increasingly not waiting for accidental vulnerabilities at all, they're publishing malicious packages directly. Defenders have made real gains — Dependabot-style automated pull requests, SBOM mandates, and OSV-format advisories all cut discovery-to-patch time for organizations that use them — but adoption is uneven enough that the aggregate remediation curve still lags the attacker curve.
What Does Ecosystem Maturity Actually Look Like at This Point?
Maturity isn't a falling CVE count — it's rising provenance, response speed, and dependency visibility, and by that measure open source has matured a lot since 2016 without ever looking "safer" on a raw chart. A decade ago, most organizations had no dependency inventory at all; today, SBOM generation is a contractual requirement in large swaths of the U.S. federal supply chain and the EU's Cyber Resilience Act (adopted 2024). A decade ago, package signing was rare and inconsistent; Sigstore's keyless signing, launched in 2021, now covers a meaningful share of new npm and PyPI publishes. A decade ago, "malicious package" and "vulnerable package" were treated as the same category; they're now tracked, scored, and responded to differently, because the intent behind them is different. The CVE count going up isn't the failure — it's closer to a symptom of an ecosystem finally instrumenting itself well enough to see its own problems.
How Safeguard Helps
Reading a decade of vulnerability trends is one thing; acting on them inside a real build pipeline is another. Safeguard is built around the same maturity markers this data points to: continuous, automated SBOM generation across every service and language in your stack, so you have the dependency inventory that most of the industry didn't have a decade ago; provenance and signature verification on the packages and artifacts flowing through your CI/CD, so a xz-style backdoor or a dependency-confusion attack gets caught before it reaches production rather than discovered by accident; and real-time monitoring against both CVE feeds and malicious-package intelligence, since — as the Sonatype data shows — a growing share of supply chain risk today isn't a disclosed vulnerability at all but a deliberately planted one. Safeguard also maps newly disclosed CVEs against your actual transitive dependency graph, not just your direct manifest, so you know within minutes whether the next Log4Shell touches your production systems instead of finding out from a Slack thread two days in. Ten years of open source vulnerability trends point to one conclusion: the organizations that treat dependency visibility, provenance, and response speed as infrastructure — not as an annual audit line item — are the ones that stay off the "still vulnerable two years later" statistic. Safeguard is built to keep you there.