In March 2024, a Microsoft engineer named Andres Freund noticed a 500-millisecond delay in SSH login times on a Debian testing box and pulled on the thread until it unraveled a multi-year plot to backdoor xz-utils, a compression library buried in the dependency tree of nearly every Linux distribution. The attacker had spent two years building trust as a co-maintainer of a project whose sole other maintainer was burned out and unresponsive. That single fact — one tired volunteer, no backup, no oversight — is the real story. Unmaintained open source software is not a rare edge case; it is the default state of a huge share of the packages your build pulls in every day, and it is one of the least visible risks in the modern software supply chain. This post breaks down how big the problem actually is, why it happens, and what a security team can realistically do about it.
How Common Is Unmaintained Open Source Software, Really?
It is common enough to be the norm rather than the exception: multiple large-scale audits put the share of open source projects with no recent commits or a single overworked maintainer at well over half of the ecosystem. The 2024 Open Source Security and Risk Analysis (OSSRA) report from Synopsys found that 91% of commercial codebases contained open source components that were either out of date or had seen no development activity in the prior two years, and 48% contained components with no development activity at all in that window. Tidelift's maintainer surveys have repeatedly found that a majority of maintainers spend fewer than 10 hours a week on their projects, often unpaid, and roughly one in four popular npm packages is maintained by a single person. The xz-utils backdoor is the example everyone remembers, but the pattern is structural: a small number of people carry an enormous amount of the world's software infrastructure on their spare time, and that number is shrinking relative to the number of projects being created.
Why Do Critical Projects End Up With Only One Maintainer?
Because open source maintenance is unpaid, unglamorous work that scales badly, and the incentive structure rewards new projects over long-term stewardship. A package that solves a common problem well gets adopted widely, but adoption does not come with funding, staffing, or even much recognition — it comes with more bug reports, more security disclosures, and more pressure, usually directed at whoever's name is on the commit history. The maintainer of left-pad, an 11-line utility, unpublished it from npm in 2016 over an unrelated naming dispute and broke builds across the internet, including Facebook's React Native, because thousands of projects depended on it without anyone checking who was behind it. event-stream, a Node.js package downloaded roughly two million times a week, was handed off by its exhausted original maintainer to a stranger who volunteered to help in 2018 — and that stranger later added a malicious dependency that targeted a Bitcoin wallet application. Burnout, unpaid labor, and informal handoffs to unvetted volunteers are not bugs in the open source model; they are how it normally operates once a project succeeds.
What Actually Goes Wrong When a Dependency Stops Being Maintained?
Three things go wrong, usually in this order: known vulnerabilities stop getting patched, the project becomes a target for hostile takeover, and organizations lose the ability to get a fix even when they're willing to pay for one. The Heartbleed vulnerability in OpenSSL, disclosed in April 2014, exposed private keys and session data across a huge share of the encrypted internet, and the subsequent postmortem revealed that OpenSSL — software underpinning trillions of dollars of e-commerce — was maintained by a tiny team, with only one paid full-time developer, running on a budget of about $2,000 a year in donations before the incident forced the industry to fund the Core Infrastructure Initiative. Log4Shell, disclosed in December 2021 in the ubiquitous Apache Log4j library, was patched quickly by a competent team, but it still took organizations months to inventory every place the library was buried in transitive dependencies, because most teams had no idea they depended on it at all. Unmaintained projects fail at the first step — the patch just doesn't come — which is why CISA and other agencies now explicitly flag end-of-life and unmaintained components as a supply chain risk category distinct from ordinary CVEs.
Can Attackers Deliberately Target Maintainer Burnout?
Yes, and the xz-utils incident is the clearest documented case of it happening on purpose. The persona "Jia Tan" began contributing patches to the xz compression library in 2021, was gradually given commit access and eventually co-maintainer status by 2023 as the original maintainer, Lasse Collin, acknowledged publicly that he was struggling with burnout and mental health issues and welcomed the help. Over roughly two years, "Jia Tan" built a credible commit history before introducing an obfuscated backdoor into the build scripts in versions 5.6.0 and 5.6.1, released in February 2024, that would have given attackers remote code execution over SSH on infected systems running affected distributions. It was caught before it reached stable production releases of major distros, but only because one engineer happened to notice an unrelated performance regression. Security researchers now widely treat this as a template: identify strategically important but under-resourced projects, offer to help, wait, and take over. Any project with a maintainer count of one, or a maintainer who has said in public that they're overwhelmed, is a plausible future target.
How Do You Even Know If Your Dependencies Are Unmaintained?
You find out by checking commit recency, maintainer count, and issue-response times across your entire dependency tree, not just your direct imports — and most teams cannot do this manually because a typical modern application pulls in hundreds to thousands of transitive dependencies. A project can look active on its README while its actual maintenance signals — last commit date, open critical issues with no response in over a year, bus-factor of one — tell a very different story, and those signals are scattered across GitHub, package registries like npm and PyPI, and mailing lists rather than surfaced anywhere a security team naturally looks. The OpenSSF's Scorecard project was built specifically because this information wasn't being tracked systematically, and it now scores projects on criteria including maintenance activity, but adoption of that scoring inside enterprise dependency review is still inconsistent. Without automated, continuous checking, "is this still maintained" is a question teams only ask retroactively, after an incident like xz-utils makes headlines and everyone scrambles to check if they're exposed.
How Safeguard Helps
Safeguard treats maintainer health and project activity as first-class supply chain signals, not an afterthought bolted onto a CVE feed. When Safeguard scans your software bill of materials, it doesn't just tell you a package has a vulnerability — it tells you whether the project behind it has a single maintainer, whether commits have stalled, whether ownership has recently changed hands, and whether the release cadence has quietly gone silent, so you can flag risk before an attacker exploits the same weakness that's visible to anyone paying attention. Safeguard's dependency graph analysis maps transitive dependencies so an unmaintained package three layers deep in your build doesn't stay invisible until it becomes a headline. And when a package does show warning signs — a xz-style maintainer handoff, a sudden burst of activity from a previously dormant contributor, an abandoned repo that's still pulling in weekly downloads — Safeguard surfaces it in context, with the evidence, so your team can make an informed call about pinning, forking, replacing, or funding the dependency before it becomes an incident. Supply chain security isn't only about patching known vulnerabilities faster; it's about knowing which parts of your stack are being watched by no one, and Safeguard is built to make sure you're not the last to find out.