On March 29, 2024, Microsoft engineer Andres Freund noticed a 500-millisecond slowdown in SSH logins on a Debian testing box and pulled a thread that unraveled one of the most sophisticated supply chain attacks ever found: a backdoor planted inside xz-utils, a compression library used by nearly every Linux distribution on Earth. The entry point wasn't a zero-day in cryptography or a stolen credential. It was Lasse Collin, the library's sole maintainer, who had spent years alone, unpaid, and by his own admission struggling with "long-term mental health issues" when a persona named "Jia Tan" showed up offering to help with the backlog. That offer of free labor, extended over two years of patient social engineering, is how a nation-state-caliber actor got a backdoor into commit history most of the internet depends on. This is not a one-off story. It is the default operating condition of open source, and it is a supply chain risk that "unpaid open source maintainer labor" describes with uncomfortable precision.
Why did a single volunteer maintainer become the entry point for a nation-state backdoor?
Because xz-utils, like the vast majority of foundational open source infrastructure, had exactly one person keeping the lights on, and that person had no institutional backup. Lasse Collin had maintained xz-utils largely by himself since 2009. When "Jia Tan" first appeared on the mailing list in 2021, complaining that patches were being ignored and that the project needed more hands, it was a believable complaint — because it was true. Collin publicly acknowledged his limited bandwidth and mental health struggles in a 2022 mailing list post, and by 2023 he had granted Jia Tan commit access and eventually maintainer status. Cryptographic backdoor code, hidden inside binary test files and a corrupted build script, shipped in xz versions 5.6.0 and 5.6.1 in February 2024, targeting sshd via a liblzma dependency chain. The attack was caught before it hit stable distributions, but only by accident — a curious engineer noticing a login was 500ms slower than expected. There was no security team standing behind xz-utils. There was one exhausted volunteer, and that made him the entire attack surface.
How many critical open source projects actually run on unpaid labor?
Most of them — the 2020 Census II study from Harvard's Laboratory for Innovation Science and the Linux Foundation found that a huge share of the most-depended-upon open source packages are maintained by one or two individuals with no corporate sponsorship. Tidelift's 2021 maintainer survey put numbers on the problem directly: 60% of respondents said they receive no compensation at all for their maintenance work, and the median maintainer spends around four hours a week on a project that, in many cases, sits underneath the code of Fortune 500 companies. GitHub's own Open Source Survey found that only about 3% of contributors to the packages they studied were being paid for that specific work. Even curl — a library embedded in an estimated 20+ billion instances of software worldwide, from cars to spacecraft — was maintained essentially solo by Daniel Stenberg for over two decades before he was able to work on it full-time through corporate sponsorship in the 2020s. The pattern repeats at every layer of the stack: massive reach, minimal staffing, zero redundancy.
What actually happens when an unpaid maintainer burns out or walks away?
The package doesn't disappear — it usually gets handed to whoever offers to take it, and that handoff is where attackers strike. In 2018, Dominic Tarr, the original author of the widely-used npm package event-stream, was approached by a stranger offering to take over maintenance because Tarr no longer had time for a project he wasn't paid to run. The new maintainer added a malicious dependency, flatmap-stream, that specifically targeted the Copay Bitcoin wallet to siphon private keys, and it sat undetected in the dependency tree for months, downloaded an estimated 8 million times. In January 2022, the same underlying frustration produced a different failure mode: Marak Squires, maintainer of the wildly popular colors.js and faker.js npm packages, deliberately sabotaged his own code after years of unpaid work underneath products built by well-funded companies, pushing an infinite loop that printed garbled text and broke thousands of downstream applications, including Amazon's AWS Amplify. Neither incident required a nation-state. Both required nothing more than an unpaid maintainer reaching a breaking point.
Why hasn't the software industry simply paid for the infrastructure it depends on?
Because open source licensing makes the code free to consume, and free-riding is economically rational for any individual company until the collective failure shows up as a CVE. The 2021 Log4Shell vulnerability (CVE-2021-44228) is the clearest illustration: Log4j, a logging library embedded in an enormous share of enterprise Java software, was maintained by a small volunteer team inside the Apache Software Foundation's Logging Services group. When the vulnerability broke in December 2021, it forced emergency patching across companies worth trillions of dollars combined, yet the maintainers who wrote the fix were, at the time, working nights and weekends without compensation tied to that work. The mismatch is structural: a company can put a $50,000 library into production with a single npm install and never send a dollar back to the person who wrote it, because nothing in the tooling or the incentive structure asks them to. Left-pad's 2016 removal from npm — an 11-line package whose disappearance broke builds across the internet, including for Node.js and Babel — showed the same fragility from the opposite angle: even trivial code can be load-bearing, and load-bearing code written for free gets no more protection than a hobby project.
Can money alone fix the maintainer crisis, or does it need something else?
Money helps, but funding without security process still leaves the same single points of failure in place. Following Log4Shell, Google and other major vendors backed the Open Source Security Foundation's (OpenSSF) Alpha-Omega Project in 2022 with an initial $5 million commitment aimed at directly funding security improvements in critical open source projects, and GitHub Sponsors, Tidelift, and Open Collective have all grown as channels for paying maintainers. These are meaningful steps, but they don't solve the underlying supply chain visibility problem: even a well-funded maintainer team is still one compromised credential, one social-engineered handoff, or one malicious dependency away from an xz-utils repeat, and most organizations consuming open source still have no systematic way to know which of their dependencies are maintained by a single unpaid volunteer versus a well-resourced team. Paying maintainers reduces burnout-driven risk; it does not, by itself, give downstream consumers the ability to detect when a trusted package starts behaving differently.
How Safeguard Helps
Safeguard treats the maintainer fragility exposed by xz-utils, event-stream, and colors.js as a first-class supply chain risk signal rather than an afterthought. Our platform continuously maps your software bill of materials against real maintainer and project health signals — single-maintainer status, commit and release cadence changes, sudden ownership transfers, and anomalous behavior in previously stable packages — so a change in who controls a critical dependency shows up as an alert, not as a postmortem. When a package like xz-utils receives a new maintainer, ships an unusual binary blob in a release archive, or goes quiet for months before a suspicious flurry of commits, Safeguard flags the deviation against that package's own history and against known supply chain attack patterns, rather than waiting for a CVE to be assigned. We combine this with SBOM-driven dependency monitoring and provenance verification, so security and engineering teams can see not just what libraries they run, but how exposed they are to the specific failure mode that made xz-utils, event-stream, and Log4j into incidents: critical code, thin staffing, and no independent verification layer watching for the moment things quietly change. In a software ecosystem built on unpaid open source maintainer labor, Safeguard is the layer that assumes burnout, betrayal, and takeover are possible, and builds detection around that assumption instead of hoping it never happens on your dependency tree.