State of Open Source Supply Chain Risk 2026
Your dependencies are an actuarial problem.
The packages your app depends on have a 36% annual chance of losing their only contributor. The XZ Utils backdoor proved what that looks like in production. The K8s Ingress NGINX retirement proved the scale. This is what engineering managers should do in 2026.
Published July 13, 2026 · 7 min read
The TL;DR
- Your dependencies have a 36% annual chance of losing their only contributor.
- The median bus factor for the top 100 OSS packages is 1.
- The XZ Utils backdoor (March 2024) nearly became a global supply-chain compromise because of a bus-factor-1 project.
- The K8s Ingress NGINX retirement (Nov 2025) showed what a graceful EOL looks like — most projects don't get that.
- The fix: sponsor maintainers, contribute back, plan for adoption. Treat open source risk like vendor risk.
The 36% number
The 2026 Reptile.haus Open Source Sustainability Crisis analysis put a number on the risk that's been qualitatively obvious for years: packages with a bus factor of 1 have a 36% annual chance of losing their only contributor. Not because of market conditions or restructuring, but because humans break under sustained, unpaid labour.
The math from there is uncomfortable. The 2024 Harvard / Linux Foundation study of the top 500 most-depended-upon open source packages found a median bus factor of 1 for the top 100. A 2025 ICSE paper found that 15% of widely-used npm packages become abandoned within a six-year window. And the 2025 Maven ecosystem study (arXiv 2502.00615) found that approximately 1 in 4 libraries fail to survive beyond their creation year.
Multiply that across the 800+ transitive dependencies of a typical modern web app and you have a real exposure. Most engineering teams have no visibility into which of their dependencies are at bus factor 1. Most procurement processes don't track open source risk the way they track vendor risk. This is the gap that the 2026 supply-chain data is forcing us to confront.
Case 1: The XZ Utils backdoor (March 2024)
CVE-2024-3094
xz-utils is a near-universal dependency in Linux distributions — used for compression in OpenSSH, dpkg, rpm, pacman, and most other packaging tools. In March 2024, a single burnt-out maintainer was socially engineered over two years into accepting a co-maintainer who slipped a backdoor into a release. The malicious code would have given the attacker remote code execution on any affected system via SSH.
The backdoor was caught only because a Microsoft engineer, Andres Freund, noticed a 500ms latency anomaly in SSH login times while benchmarking. The fix was a multi-week scramble across Debian, Red Hat, Arch, and every other downstream distribution. Had Freund not been benchmarking that week, the backdoor would have shipped into production releases used by hundreds of millions of servers.
The root cause was bus factor 1. The original maintainer had been carrying the project alone for years, was visibly burned out, and was a target for exactly the kind of social engineering that the attack used. The fix — diversifying maintainership — would have prevented the attack. The fact that the open source community didn't have the infrastructure to do that is the systemic problem.
Case 2: Kubernetes Ingress NGINX retirement (November 2025)
The K8s SIG-Network retirement announcement
After 9 years of maintenance by a small volunteer team, the official Kubernetes Ingress NGINX controller entered retirement in November 2025. The maintainer team publicly cited burnout and the inability to keep up with Kubernetes API changes as the reasons. Hundreds of thousands of clusters depended on the project.
The retirement was a model of what a graceful EOL should look like. Replacement guidance (Gateway API as the successor) was published at the same time as the retirement notice. The migration window was generous. The maintainer team stayed on for 6 months to answer questions. The project is now in a clean end-of-life state, with the user community pointed at the right successor.
Most projects don't get this treatment. Most abandoned projects simply stop getting releases, with no announcement and no migration path. The K8s Ingress NGINX retirement is the model. See the responsible abandonment guide for the full playbook.
What engineering managers should do
1. Inventory your top 20 critical dependencies
Run npm ls --all or your language equivalent, and pick the
20 packages that would cause a real outage if they went unmaintained
tomorrow. For each, score them on:
- Bus factor (JetBrains' tool, or
git shortlog -sn --allon the source) - Last commit, last release, issue response time
- Explicit status signals (ADOPTME tag, npm deprecated, PyPI Inactive)
- Sponsoring status (funded via GitHub Sponsors, Open Collective, Tidelift, etc.)
- Institutional backing (company, foundation, or pure solo)
2. Sponsor the bus-factor-1 maintainers
Even $100/month per maintainer changes the calculus. GitHub Sponsors, Open Collective, and Polar all route to the maintainer directly. Tidelift is the institutional option if you want a single contract covering many projects. The Tidelift 2024 data shows that paid maintainers don't quit at the same rate as unpaid ones. The 36% annual loss rate is concentrated in the unpaid 60%.
3. Make contributing back a team policy
Set a policy that each of your top 20 dependencies gets at least one PR from your team each quarter. The PR can be small (a typo fix, a test case, a documentation improvement) — the goal is bus factor 2+ on the projects you depend on. A team that contributes back is also a team that understands the codebase well enough to take it over if needed.
4. Have a documented adoption plan
For each bus-factor-1 dependency, write a 1-page plan: "If this goes unmaintained in the next 12 months, here's what we do." The plan should cover: who on the team takes over triage, what's the timeline to fork if needed, who contacts the maintainer, and what the internal comms look like. See the adopter guide for the playbook.
5. Track open source risk in your quarterly review
Treat open source dependencies the same way you treat vendor risk: critical dependencies get a quarterly review, the bus factor and maintenance status are tracked as a metric, and changes in status trigger a planning conversation. Most engineering organizations don't do this. The 2026 supply-chain data is the reason to start.
Frequently asked questions
What is open source supply chain risk?
The risk that a critical dependency your product depends on becomes unmaintained, compromised, or deprecated. Per the 2026 Reptile.haus analysis, packages with a bus factor of 1 have a 36% annual chance of losing their only contributor.
What was the XZ Utils backdoor?
CVE-2024-3094, March 2024. A bus-factor-1 project's maintainer was socially engineered into accepting a co-maintainer who slipped a backdoor into xz-utils. Caught only because a Microsoft engineer noticed a 500ms latency anomaly.
What happened to Kubernetes Ingress NGINX?
Retired November 2025 after 9 years. The maintainer team cited burnout and inability to keep up with API changes. Replacement guidance (Gateway API) was published alongside. A model for what a graceful EOL looks like.
How do I assess supply chain risk in my dependencies?
For each critical dependency, check bus factor, maintenance cadence, explicit status signals, sponsoring status, and institutional backing. The BreakPoint feed and the Tidelift catalog are good places to start.
What should engineering managers do about open source risk?
Five moves: inventory your top 20, sponsor the bus-factor-1 maintainers, make contributing back a policy, have a documented adoption plan for each critical dep, and track open source risk in your quarterly review.
Sources: Reptile.haus, Open Source Sustainability Crisis: Why Your Dependencies Are a Business Risk (2026) — 36% annual loss rate for bus-factor-1 packages · Harvard / Linux Foundation 2024 study of the top 500 OSS packages (median bus factor 1) · CVE-2024-3094 advisory (XZ Utils backdoor, March 2024) · Kubernetes SIG-Network retirement announcement (Nov 2025) · ICSE 2025 npm abandonment study · arXiv 2502.00615 Maven ecosystem study (25% fail to survive creation year) · JetBrains Bus Factor Explorer (Mar 2026 database data) · Linux Foundation "Winding Down an Open Source Project" guide.
Last updated: 2026-07-16. Next update: January 2027. Have data to contribute? [email protected]