In March 2024, a Microsoft engineer named Andres Freund noticed something odd: SSH logins on a Debian testing box were taking 500 milliseconds longer than they should. That five-hundred-millisecond anomaly led him to a backdoor buried inside xz-utils, a compression library almost every Linux distribution depends on — maintained, for years, by a single volunteer named Lasse Collin. The attacker had spent two years building trust with Collin under the name "Jia Tan," eventually taking over co-maintainership of a project that sits quietly in the dependency tree of thousands of enterprise systems. No company paid for xz-utils. Almost every company used it. That gap — between who builds critical software and who depends on it — is not an edge case. It is the default condition of the modern software supply chain, and it deserves a risk map.
How much of the average enterprise codebase is actually built by volunteers?
Most of it. Synopsys's 2024 Open Source Security and Risk Analysis (OSSRA) report found open source components in 96% of the commercial codebases it scanned, with an average of 526 open source components per application. The Linux Foundation's Census II study, which mapped the most critical open source packages underpinning modern infrastructure, found that a significant share of these foundational libraries are maintained by fewer than two active contributors — often exactly one. Tidelift's 2023 maintainer survey put a number on the people behind that code: roughly 60% of open source maintainers are unpaid volunteers, and the median maintainer spends under four hours a week on a project that may sit inside the CI/CD pipelines of Fortune 500 companies. Enterprises are not occasionally touching volunteer code. They are built on it, layer after layer, down to packages almost no one inside the company has ever heard of.
What happens when a single maintainer burns out or walks away?
The dependency breaks, sometimes for the entire internet. In March 2016, developer Azer Koçulu unpublished 11 lines of code called left-pad from npm in a dispute over a naming trademark. Because left-pad was a transitive dependency of Babel, React tooling, and thousands of other packages, its removal broke builds across the JavaScript ecosystem within hours — a single unpaid maintainer's personal decision cascading into a global outage. The pattern repeated in January 2022, when Marak Squires, maintainer of colors.js and faker.js — two packages downloaded a combined tens of millions of times a week — deliberately sabotaged his own libraries by pushing an infinite loop and a "LIBERTY LIBERTY LIBERTY" print statement into production code, citing years of uncompensated corporate use. Fortune 500 pipelines broke that morning because of one developer's protest. Maintainer fatigue is not hypothetical; it is a documented, recurring failure mode with a name in the research literature and a growing list of incidents behind it.
Can an unpaid maintainer's account become an actual attack vector?
Yes, and the xz-utils backdoor is the clearest proof to date. CVE-2024-3094, disclosed on March 29, 2024, involved a multi-year social engineering campaign in which "Jia Tan" pressured the sole maintainer through sockpuppet accounts complaining about slow response times, then volunteered to help, earned commit access, and eventually inserted an obfuscated backdoor into the build scripts that would have given attackers remote code execution on affected SSH connections. It was caught by chance, days before it would have landed in stable releases of major Linux distributions. The event-stream incident in November 2018 followed a similar script: an anonymous contributor offered to take over maintenance of a popular but dormant npm package, gained trust, and then added a dependency, flatmap-stream, containing code that targeted a specific cryptocurrency wallet application. Volunteer maintainers are, by definition, easier to socially engineer than a corporate security team — they are often isolated, overworked, and flattered by anyone offering to help carry the load.
Why don't the companies relying on this code just pay for it?
Mostly because the dependency is invisible until it breaks. The Linux Foundation and Harvard's Laboratory for Innovation Science estimated in a 2024 study that firms would need to spend roughly $8.8 billion more annually to reproduce the open source software they already consume from scratch — a figure that dwarfs what is actually donated back through foundations, bug bounties, or maintainer sponsorships. Tidelift's surveys have repeatedly found that fewer than half of maintainers have ever received any funding for their work, corporate or otherwise, despite supporting software embedded in products worth billions in aggregate revenue. Part of the problem is structural: a company's engineering team pulls in a package with npm install or pip install in seconds, with no procurement process, no vendor risk review, and no line item ever created. The dependency enters production the same day it enters awareness, if it enters awareness at all — most organizations cannot produce a complete list of what they depend on without tooling, let alone identify who maintains it or whether that person is still active.
How exposed is your organization if a maintainer disappears tomorrow?
More exposed than your dependency file suggests, because the risk compounds transitively. A direct dependency you evaluated and approved might itself depend on a dozen packages you never reviewed, each maintained by different people with different risk profiles — and studies of npm and PyPI ecosystems have repeatedly shown that a typical application's transitive dependency count runs 5 to 10 times higher than its direct one. The 2021 Log4Shell vulnerability (CVE-2021-44228) illustrated the scale problem: Log4j was a dependency so deeply nested in enterprise Java stacks that many security teams spent weeks just discovering everywhere it existed before they could even begin patching, despite the project having a comparatively well-resourced maintainer team by open source standards. If a well-known, well-staffed project can hide that effectively, a single-maintainer utility library nine layers deep is functionally invisible without automated software composition analysis and a current SBOM. Risk here isn't measured by how critical a package looks — it's measured by how many other packages quietly depend on it.
How Safeguard Helps
Safeguard is built for exactly this blind spot: the gap between what your organization runs and what your organization actually knows it depends on. Safeguard continuously generates and maintains accurate SBOMs across your codebases, surfacing not just direct dependencies but the full transitive tree, so a package like xz-utils or event-stream shows up on your radar before an incident forces it there. Beyond inventory, Safeguard scores dependencies on maintainer risk signals — commit frequency, bus-factor, ownership transfer events, and known sockpuppet or takeover patterns similar to the ones used against xz-utils — flagging packages where a single person leaving would create real exposure. When a CVE or supply chain compromise is disclosed, Safeguard maps it instantly against your live dependency graph, telling you within minutes whether you're affected and where, instead of the weeks-long discovery process that defined the Log4Shell response for so many teams. And because policy enforcement matters as much as visibility, Safeguard lets teams gate builds on maintainer-risk and provenance signals directly in CI/CD, so a low-trust or recently transferred package can be reviewed before it ships rather than after it's exploited. Corporate dependence on volunteer-maintained code isn't going away — the economics of open source guarantee it. What changes with Safeguard is whether that dependence stays invisible or becomes a managed, monitored part of your security posture.