The Foundation Is Cracking
Open source software underpins virtually everything. The Linux kernel runs on most servers. OpenSSL secures most encrypted connections. npm hosts over 1.8 million packages. PyPI has over 350,000. Modern applications are roughly 70-90% open source components by code volume.
This is the foundation of the digital economy. And in 2021, the cracks are becoming impossible to ignore.
The year has already brought a steady drumbeat of incidents: SolarWinds (which exploited trust in software updates), Codecov (a developer tool turned exfiltration vector), Kaseya (software management weaponized for ransomware distribution), and the ua-parser-js compromise (a single maintainer's account leading to millions of malware installations). The incidents share a common thread — the implicit trust placed in software infrastructure that nobody examines closely.
The Numbers
Vulnerability Growth
The number of disclosed vulnerabilities continues to accelerate. In 2020, over 18,000 CVEs were published. 2021 is on pace to exceed 20,000. Open source vulnerabilities specifically have grown roughly 20% year over year since 2017.
This growth isn't just about more software existing. It's about more scrutiny. Government mandates, increased security research investment, and automated vulnerability discovery tools are finding issues faster than the ecosystem can fix them.
Malicious Packages
npm removed over 1,300 malicious packages in the first half of 2021 alone. PyPI and RubyGems saw similar surges. These aren't sophisticated supply chain attacks — most are typosquatting attempts, cryptominers, and credential stealers. But the volume is overwhelming.
The barrier to publishing a package on any major registry is essentially zero. There's no identity verification, no code review, no security scanning at publish time (though registries are adding some basic checks). Anyone can publish anything under any name.
Dependency Depth
The average npm project has 683 dependencies (including transitive). The average Java project pulls in 150+ library versions. Python projects with frameworks like Django or Flask easily reach 100+ dependencies.
Each dependency is a potential vector for vulnerability or compromise. The attack surface isn't the code you write — it's the code you import.
The Maintainer Problem
The open source security crisis is fundamentally a people problem. Critical infrastructure is maintained by individuals, often unpaid, often burned out.
Consider:
- core-js — Used by 75% of the top 1,000 websites. Maintained primarily by one developer who was incarcerated and unable to work on the project.
- OpenSSL — Before Heartbleed in 2014, the project that secured most of the internet's encrypted traffic had one full-time developer.
- left-pad — An 11-line npm package whose removal from the registry in 2016 broke thousands of builds, demonstrating the fragility of the dependency ecosystem.
Maintainers face overwhelming issue queues, demanding users, and security responsibilities they never signed up for. When a CVE is published against their library, they're expected to drop everything and produce a patch. When they don't respond fast enough, they face public criticism.
The result is predictable: burnout, abandonment, and — critically — security gaps. Abandoned packages with known vulnerabilities continue to be downloaded millions of times. Maintainers who leave don't always hand off credentials securely. Account takeovers of abandoned projects are a growing vector for supply chain attacks.
Funding Versus Usage
The economics of open source security are deeply broken. Packages that are downloaded billions of times generate zero direct revenue for their maintainers. Companies that build billion-dollar products on open source foundations rarely contribute to the maintenance of those foundations.
Some progress is being made. GitHub Sponsors, Open Collective, and Tidelift provide funding mechanisms. The Linux Foundation's Open Source Security Foundation (OpenSSF) was established to coordinate security investment. Google committed $100 million to open source security through its Secure Open Source (SOS) program.
But the gap between usage and support remains enormous. Most critical packages receive no dedicated security investment. Vulnerability remediation depends on volunteer time.
The Ecosystem Responses
Registry-Level Security
npm introduced mandatory 2FA for top-500 packages in 2021, with plans to expand. PyPI is implementing similar requirements. These measures address account takeover risks but don't solve the fundamental trust model.
Automated Security Scanning
GitHub's Dependabot, Snyk, and similar tools automatically scan for known vulnerabilities and create pull requests for updates. These tools have improved response times for known CVEs significantly. But they only work for known vulnerabilities — they can't detect novel malicious code.
Government Action
Executive Order 14028 and NIST's Secure Software Development Framework are the most significant government interventions in open source security. By mandating SBOMs and secure development practices, they create economic incentives for organizations to invest in supply chain security.
The SLSA Framework
Google's Supply-chain Levels for Software Artifacts (SLSA) framework, announced in June 2021, provides a graduated model for supply chain integrity. From basic build provenance to fully reproducible, hermetic builds, SLSA gives organizations a concrete path toward supply chain security.
What Needs to Change
- Fund critical infrastructure — Organizations that depend on open source must invest in its maintenance. Not as charity, but as infrastructure investment.
- Reduce dependency depth — The 683-dependency average is a liability. Teams need to evaluate whether every dependency is necessary.
- Verify, don't trust — Lockfiles, checksum verification, signature validation, and behavioral analysis should be standard practice.
- Support maintainers — Beyond funding, this means security tooling, CI infrastructure, and incident response support for maintainers.
- Regulate where necessary — SBOMs and secure development practices should be expected, not optional.
How Safeguard.sh Helps
Safeguard.sh addresses the open source security crisis by providing comprehensive visibility into your dependency tree, including abandoned packages, known-vulnerable components, and libraries with concerning maintenance patterns. The platform doesn't just scan for CVEs — it evaluates the health and risk profile of every component in your supply chain.
The platform monitors over a dozen data sources including NVD, OSV, GitHub Advisory Database, and registry-specific advisories. When a vulnerability is disclosed in any of your dependencies — direct or transitive — Safeguard.sh alerts you immediately with actionable remediation guidance, including whether a fixed version exists and what breaking changes to expect.
For organizations looking to reduce their open source risk exposure, Safeguard.sh provides dependency analytics that identify bloated dependency trees, duplicate libraries, unmaintained packages, and components approaching end of life. This intelligence helps engineering teams make informed decisions about which dependencies to keep, replace, or eliminate entirely.