Open source sustainability is usually framed as a funding and fairness problem — but it is more usefully framed as an attack surface problem. An exhausted solo maintainer, an abandoned package with millions of weekly downloads, an eager stranger offering to help: these are the preconditions of modern supply chain attacks, not just community health concerns. The xz Utils backdoor (CVE-2024-3094) was built on precisely this pattern, and your dependency tree is full of the same preconditions right now. This post makes the security case for treating sustainability signals as risk signals.
Why is open source sustainability a security problem?
Because attackers target the maintenance gap, not the code. A well-maintained project with multiple active maintainers, review requirements, and release signing is expensive to compromise. A project maintained by one burned-out volunteer is cheap to compromise in at least three ways: social-engineer your way into commit access, wait for the project to be abandoned and offer to "adopt" it, or simply compromise the maintainer's account, which no second person is watching.
The structural math is unforgiving. A large fraction of the packages underpinning commercial software are maintained by one or two people, unpaid, in their spare time. Meanwhile those same packages sit inside the build pipelines of banks, hospitals, and governments. The value at risk grew exponentially; the maintenance capacity did not. That asymmetry is the attack surface.
What did the xz Utils backdoor teach us about maintainer risk?
In March 2024, a backdoor was discovered in xz Utils versions 5.6.0 and 5.6.1, tracked as CVE-2024-3094 with a CVSS score of 10.0. The mechanics were sophisticated — obfuscated payload stages hidden in test files, targeting sshd via the liblzma dependency chain on some Linux distributions — but the entry vector was social. Over roughly two years, a persona known as "Jia Tan" built trust with the project's overextended solo maintainer, aided by sockpuppet accounts pressuring the maintainer to accept help. The attacker became a co-maintainer, then shipped the backdoor through legitimate release channels.
Nothing about that playbook is specific to xz. It works against any critical, under-maintained project, and it is only detectable ahead of time through sustainability signals: a single maintainer, declining activity, sudden new committers gaining privileges, pressure campaigns in the issue tracker. The lesson is not "audit more code" — the backdoor survived code-level scrutiny for weeks. The lesson is that project health is a security control.
Which sustainability signals predict supply chain risk?
When evaluating a dependency, these signals matter as much as its CVE history:
- Bus factor. How many people can cut a release? One is a red flag for anything load-bearing.
- Maintenance activity. Commit recency, issue response time, release cadence. Abandonment usually shows up here a year before it becomes official.
- Governance and provenance. Are releases signed? Is there two-person review? Did the artifact on the registry actually come from the repository? The event-stream incident in 2018 — where a malicious "new maintainer" shipped code targeting cryptocurrency wallets to a package with millions of downloads — exploited the absence of exactly these controls.
- Maintainer concentration changes. A long-dormant project suddenly transferred to an unknown account is one of the highest-signal events in the ecosystem.
- Funding and affiliation. A maintainer paid to work on the project, or a foundation behind it, meaningfully lowers takeover risk.
Scorecards from the OpenSSF formalize several of these checks, and modern software composition analysis increasingly surfaces maintenance and abandonment signals alongside vulnerability data, which is where they belong — in the same queue your engineers already triage.
What should organizations do about unsustainable dependencies?
Four moves, in rough order of leverage:
- Inventory and rank. Generate SBOMs, then identify which dependencies are both critical to your product and weakly maintained. The dangerous quadrant is high-centrality, low-sustainability.
- Reduce exposure where cheap. Prefer well-governed alternatives when adopting new dependencies; a maintenance-health check at intake costs minutes and prevents years of exposure.
- Fund or staff what you cannot replace. If a solo-maintainer project is load-bearing for your revenue, sponsoring the maintainer or contributing engineer time is not charity — it is cheaper than the incident, and cheaper than the fork you will otherwise eventually maintain alone. This is the honest economic core of open source sustainability.
- Prepare for abandonment. Have a policy for what happens when a dependency dies: pin and monitor, migrate, or fork. Deciding in advance beats deciding during an incident.
For teams building this into policy, our writeup on component deprecation and dependency lifecycle practices pairs well with this piece.
Is funding maintainers actually a security control?
Yes, and it is worth saying plainly. The xz attack worked because one unpaid person carried critical infrastructure alone and a patient attacker offered relief. Paying maintainers, adding co-maintainers through trusted foundations, and funding security work like release signing all raise the cost of the takeover playbook directly. Programs from the OpenSSF, GitHub Sponsors, and commercial initiatives that route money to maintainers are, in security terms, hardening measures for the layer of your stack you do not control. Budget accordingly: a few thousand dollars a year sponsoring the projects in your critical path is among the cheapest risk reduction available in security.
FAQ
What does open source sustainability mean?
Open source sustainability refers to whether the projects you depend on have the ongoing human and financial resources to stay maintained — active maintainers, succession, funding, and governance. From a security standpoint, it measures how resistant a project is to abandonment and takeover.
How do I find unmaintained dependencies in my stack?
Start from an SBOM of what you actually ship, then check maintenance signals for each component: last release date, commit activity, open issue response, maintainer count. SCA platforms and OpenSSF Scorecard automate much of this; prioritize components that are both deeply embedded and weakly maintained.
Was the xz Utils backdoor caught by scanners?
No. It was found by a Microsoft engineer, Andres Freund, investigating a half-second SSH slowdown and unusual CPU usage. That is precisely why sustainability signals matter: the code-level detection failed, while the social preconditions — solo maintainer, pressure campaign, new privileged committer — were visible for two years.
Should we fork abandoned dependencies?
Sometimes, but treat forking as the last resort — you inherit the full maintenance burden that sank the original. First evaluate migrating to a maintained alternative or funding revival of the original project. Fork when the component is critical, alternatives are worse, and you can genuinely staff it.