Open-source software is the foundation of the digital economy. The Linux Foundation estimates that open-source components make up 70-90% of modern software applications. Every Fortune 500 company, every government agency, and every startup depends on code written and maintained by the open-source community.
But who maintains this code? And are they equipped to do it securely?
The answers, based on 2025 data, are sobering. The open-source ecosystem continues to produce extraordinary value while operating under structural conditions that make security failures inevitable. Understanding these conditions is the first step toward fixing them.
The Maintainer Problem
The XZ Utils backdoor (CVE-2024-3094), discovered in March 2024, put a spotlight on a problem the open-source community has known about for years: critical infrastructure maintained by individuals, often unpaid, with no organizational backing.
XZ Utils is a compression library used by virtually every Linux distribution. Its sole maintainer, under personal stress and burnout, was socially engineered by an attacker who spent two years building trust before inserting a sophisticated backdoor into the SSH authentication chain.
XZ Utils was not an anomaly. Census data paints a consistent picture:
Concentration of responsibility. A 2024 Harvard/Linux Foundation study found that the top 500 most-depended-upon open-source packages had a median of 2 active maintainers. For the top 100, the median dropped to 1.
Burnout is endemic. The 2024 Tidelift maintainer survey found that 60% of open-source maintainers have experienced or felt close to burnout. Forty-six percent are unpaid. Among those who are paid, the compensation rarely reflects the responsibility they carry.
Funding does not reach critical projects. While high-profile projects (Linux kernel, Kubernetes, Node.js) have corporate backing and funding, the "long tail" of critical dependencies -- libraries like XZ Utils, libcurl, OpenSSL (before Heartbleed), and thousands of others -- operates on volunteer time and occasional donations.
Security expertise is rare. Most open-source maintainers are not security experts. They are developers who built a useful tool and found themselves responsible for a piece of global infrastructure. Expecting them to independently implement secure development practices, conduct security audits, and respond to vulnerability reports is unrealistic.
Dependency Depth and Risk
The depth of modern dependency trees amplifies maintainer risk. A 2025 analysis of the npm ecosystem found:
- The average npm package has 7 direct dependencies.
- The average transitive dependency tree contains 68 packages.
- The maximum observed dependency depth was 23 levels.
- Approximately 15% of packages in typical dependency trees have no active maintainer (no commits in the past 12 months).
Each unmaintained package is a potential vulnerability that will never be patched. When a CVE is filed against an unmaintained package, the consumers of that package must either find an alternative, fork and patch it themselves, or accept the risk.
The Quality Gap
Not all open-source projects are created equal when it comes to security practices. The OpenSSF Scorecard project, which evaluates open-source projects against security best practices, found in 2025:
- Only 11% of the top 1,000 most-downloaded npm packages scored above 7.0 (out of 10) on the Scorecard.
- Only 23% had branch protection enabled on their main branch.
- Only 34% had code review requirements for merges.
- Only 19% ran SAST tools in their CI pipelines.
- Only 8% signed their releases.
These numbers represent the most popular packages. The long tail of less popular but still widely-used packages scored significantly worse.
What Is Being Done
Several initiatives are working to improve the structural conditions of open-source security:
OpenSSF (Open Source Security Foundation) continues to fund security audits, develop security tooling (Sigstore, SLSA, Scorecard), and provide training for maintainers. The Alpha-Omega project specifically targets critical projects and the "long tail" of under-resourced dependencies.
Sovereign Tech Fund (Germany) and similar government-backed initiatives in other countries are providing direct funding to critical open-source projects. This represents a shift in thinking: governments recognizing that open-source infrastructure is public infrastructure that deserves public investment.
Corporate sponsorship through programs like GitHub Sponsors, Tidelift, and direct hiring of open-source maintainers is increasing, though still far below the level needed.
Regulatory pressure from the EU CRA and similar regulations is pushing software producers to take responsibility for the open-source components they use, which may drive more resources upstream to the projects they depend on.
What Organizations Should Do
Know your dependencies. Generate SBOMs for all your software and understand the full transitive dependency tree. Identify the critical dependencies that your applications rely on.
Assess maintainer health. For your most critical dependencies, evaluate the health of the maintaining project. Single-maintainer projects, projects with no recent commits, and projects with no security practices should be flagged for additional scrutiny.
Contribute upstream. If your organization depends on an open-source project, contribute to it. This can be code contributions, security reviews, funding, or simply reporting issues. Your organization's security depends on the health of these projects.
Have a plan for unmaintained dependencies. For dependencies where the maintainer has abandoned the project, have a plan: fork and maintain internally, find an alternative, or accept and document the risk.
Fund the ecosystem. Direct funding to the open-source projects your organization depends on is not charity -- it is risk management. The cost of sponsoring a maintainer is trivial compared to the cost of a supply chain breach.
How Safeguard.sh Helps
Safeguard.sh provides the visibility needed to understand your organization's relationship with the open-source ecosystem. By analyzing your SBOMs, Safeguard identifies not just known vulnerabilities but structural risks: unmaintained dependencies, single-maintainer projects, components with poor security practices, and packages with suspicious activity patterns.
Safeguard's Griffin AI evaluates the health and risk profile of your open-source dependencies, giving you the intelligence needed to make informed decisions about which dependencies to keep, which to replace, and which to invest in supporting. This proactive approach to open-source risk management is more effective and less expensive than waiting for the next XZ Utils-scale incident.