On any given day, some of the most trusted software in the world has a maintainer who is not there. Not on vacation — gone. The repository has been archived, or the last commit was years ago, or the owner's account went silent. Yet the package continues to be downloaded, vendored, and deployed by production systems that depend on it for everything from parsing to encryption to build orchestration. These are zombie dependencies: code that functions, but whose owner has left, and whose ability to respond to a vulnerability is exactly zero.
The zombie dependency is not an exotic edge case. It is a structural feature of an ecosystem built on voluntary maintenance. The number of widely used packages that are effectively unmaintained is far larger than most security teams want to admit, and the gap is growing: the open source ecosystem expands faster than the pool of people willing to maintain its older, less glamorous corners.
The Different Ways a Dependency Dies
| State | What it looks like | The risk |
|---|---|---|
| Explicitly abandoned | Repo archived, README says "no longer maintained," owner recommends a successor | Known — but vulnerable versions keep being resolved because lockfiles pin them |
| Silently abandoned | No archive notice, but no commits, no responses, no releases for years | Worst — looks alive to automated scanners, has no maintainer in practice |
| Orphaned and reassigned | Ownership transferred, or an abandoned name republished by a new party | Trust inherits the name; the new owner may not have earned it |
| Barely alive | One maintainer, sporadic commits, no bus factor, no successor | One event away from becoming a zombie; critical releases depend on one person |
The dangerous category is not the explicitly abandoned — at least that one tells the truth. It is the silently abandoned package that still resolves, still builds, and still shows up in dependency reports as "no known vulnerabilities," precisely because nobody has looked at it in years.
Why Zombies Are a Security Problem
A zombie dependency is a vulnerability with a special property: it is unfixable. When a flaw is discovered in maintained software, the world waits for a patched release. When a flaw is discovered in a zombie, there is no release coming. The options are:
- Fork it. Take the source, patch it yourself, maintain it forever. Feasible for small projects, and organizationally expensive for the thousands of small packages that only one vendor ever used.
- Replace it. The right long-term answer, and the most expensive short-term one. Replacement means rewiring production systems, retesting integrations, and retiring the accumulated institutional knowledge around the old package.
- Accept the risk. The default, almost always. The vulnerability is documented, the exposure is assessed, and the team moves on — because the alternative is a migration project nobody is funded to do.
Acceptance is a legitimate decision. The problem is that it is rarely a decision. It is a default — and defaults are how the most dangerous risks survive every review cycle.
The Thought Experiment: The Library That Can't Be Patched
Thought experiment — the maintenance cold case
An audit of a financial services platform identifies a critical vulnerability in a date-parsing library that the platform has used for a decade. The library is small, correct, and deeply embedded in the codebase — every financial calculation in the platform runs its output through it.
The audit reveals three facts. First, the vulnerability is real and exploitable. Second, the library's last release was eight years ago, and its maintainer has not responded to any communication in five. Third, no fork exists, and the package's public registry page still shows a healthy download count, so every automated scanner classifies it as "in use" but not "abandoned."
The security team has three paths: fork and maintain a critical piece of financial infrastructure, plan a replacement migration measured in quarters, or document the risk and accept it. All three are expensive. The most expensive is the one nobody planned for — because the risk was invisible until the day it became someone's problem.
Why the Ecosystem Keeps Producing Zombies
The zombie dependency is an economic problem dressed as a technical one. The open source ecosystem's maintenance is voluntary, and the demand for new features massively outpaces the supply of maintenance effort. The packages that become zombies are rarely the famous ones. They are the small, correct, finished utilities — the code that stopped needing changes precisely because it worked. A stable package needs no new releases, which means no activity, which means it looks abandoned to the metrics that govern attention.
The incentives are misaligned in a specific way: the cost of maintaining the critical-but-unglamorous package falls entirely on whoever happens to depend on it, while the value of the package's continued existence is spread across every downstream consumer. When the maintainer leaves, the cost concentrates suddenly, and the downstream consumers discover they have been receiving a public good on a zero-subsidy basis.
Measuring the Dead: How to Spot a Zombie
Zombie risk is measurable, and the measurements are the same ones a wary investor would run on a company. The maintenance scoreboard for a dependency includes: the date of the last release, the time to first response on open issues, the number of open issues versus closed, the number of maintainers with write access, the presence of a succession plan in the README, and whether the package has a declared owner at all. A dependency with a release from eight years ago, a hundred open issues, and a single maintainer who has not posted in two years is a zombie regardless of how many downloads it still gets.
The measurement matters because zombie status is invisible to the tools teams already run. Vulnerability scanners look for known flaws, not for absent maintainers. License scanners look for legal compliance, not for bus factor. Nothing in the standard toolchain flags "this package cannot be patched, ever, by anyone upstream." That question — can this dependency actually be fixed if it breaks? — is the one that turns a supply chain inventory from a compliance exercise into a survival plan.
The data exists to answer it. Open source registries and repository platforms expose the activity, the maintainer count, and the issue backlog for every package. The discipline is adding those fields to the dependency report next to the version number, and treating "unmaintained" with the same weight as "vulnerable" — because a vulnerable package with a maintainer has a future, and a vulnerable package without one does not.
The Responsibility That Comes With Reuse
There is one more uncomfortable implication, and it lands on every consumer of open source: when you adopt a dependency, you accept an obligation to its future. A library does not stop mattering when its maintainer leaves; it stops having anyone to fix it. Organizations that depend on unmaintained software and do nothing are, in effect, choosing to let a critical component rot — not because they are malicious, but because the maintenance cost has no budget line and the risk has no visible due date. Treating the decision to depend on a zombie as a conscious, recorded, reviewed decision — rather than an inherited default — is the smallest act of supply chain hygiene, and the one most organizations never take.
Feeding the Dead: Practical Responses
The responses are unglamorous, which is why they are also rare:
- Inventory with a maintenance lens. Every dependency audit should flag not just "vulnerable" but "who maintains this, and would we notice if they left?" A maintenance score is as important as a vulnerability score.
- Track zombie risk explicitly. Record, for each critical dependency, whether a patched version could actually arrive. Build the "no release is coming" assumption into your risk model instead of discovering it in an incident.
- Vendor the critical ones. The code you truly cannot live without should be vendored and reviewed, so a zombie's flaws are your flaws that you can patch in your own fork.
- Fund the maintainers who remain. The cheapest way to avoid a zombie is to pay the person who is about to leave. Sponsorship, security reviews, and funded maintenance are the practical form of this.
- Plan migrations before they are forced. The platforms that survive zombie disclosures are the ones that already had replacement candidates evaluated, because migration-in-crisis is the most expensive migration of all.
Key Takeaways
- A zombie dependency is code whose maintainer has gone — and whose vulnerabilities are, by definition, unfixable by the upstream.
- The silently abandoned package is the dangerous case: it looks alive to scanners and has no maintainer in practice.
- Accepting the risk is a decision; defaulting to acceptance because replacement is expensive is how risk survives reviews.
- Vendoring, maintenance scoring, and funded sponsorships are practical responses to an economic, not technical, problem.
- The stability that makes a library trustworthy is the same stability that turns it into a zombie.
There is a particular tragedy to the zombie dependency: it was usually abandoned because it was good. It stopped needing changes because it was finished. And it is precisely that reliability that let everyone depend on it without noticing who was carrying it. The ecosystem's most trusted code is often its least maintained, and the security industry has not yet built the vocabulary — or the funding — to say that out loud. The frontier here is not technical. It is the recognition that software security includes the social fact of who is willing to keep the lights on, and the willingness to pay for the lights that are already on.