In October 2021, someone opened a pull request against an obscure compression library. It edited an .editorconfig file. By any measure available at the time it was polite, useful, and utterly unremarkable. Two and a half years later, that same contributor shipped a backdoor into xz-utils that came within days of landing in the stable channels of nearly every major Linux distribution. What made it work was not a clever exploit primitive. It was accumulated goodwill: precisely the asset that this analysis of how sustained visibility compounds into long-term authority treats as a competitive advantage, run in reverse and pointed at a build system. Reputation is an access-control layer. Most engineering organizations have never once reviewed the permissions it grants.
The Longest Con in Modern Infrastructure
The xz-utils incident, CVE-2024-3094, is usually filed under "supply chain attack." That framing undersells it. The technical payload was elegant — an IFUNC resolver hijacking RSA_public_decrypt at runtime, activating only on x86-64 glibc systems built with dpkg or rpm, obfuscated inside binary test fixtures and a modified build-to-host.m4 that appeared only in release tarballs and never in the public Git tree. That's good tradecraft. It is not the interesting part.
The interesting part is the two-and-a-half-year account warm-up that preceded it. First contribution: October 2021. First authored commit: January 2022. Then months of legitimate, genuinely useful work — code review, translations, CI maintenance, infrastructure cleanup. Around mid-2022, a cluster of accounts with thin histories and suspiciously recent creation dates appeared on the xz-devel mailing list, complaining about slow release cadence and pressuring the sole maintainer to bring on help. One of them wrapped the pressure in sympathy about the maintainer's mental health while insisting the community deserved more. That maintainer was one unpaid volunteer looking after a library embedded in essentially every Linux system in existence.
He relented. Commit access followed, then release authority. The backdoor commit landed 22 January 2024; version 5.6.0 shipped 24 February. It was caught on 28 March by a Microsoft engineer benchmarking PostgreSQL who noticed SSH logins were taking about half a second too long and refused to let it go.
The attacker did not bypass the trust model. The attacker satisfied it. Every gate the ecosystem had was social, and every one of them was cleared honestly.
Then the Attackers Automated the Social Layer
If xz was the artisanal version, September 2025 was the industrial one. A self-replicating npm worm nicknamed Shai-Hulud began harvesting credentials from developer machines and CI runners, then using the stolen npm tokens to publish poisoned versions of every other package the victim maintained. No operator in the loop. CISA's alert on the npm ecosystem compromise put the initial blast radius above 500 packages and told organizations to pin dependencies to releases published before 16 September 2025 and rotate every developer credential they had.
It kept evolving. The December 2025 wave moved execution into the preinstall phase, so the payload ran before tests or scanners ever got a turn. It dropped a Bun runtime, registered a self-hosted GitHub Actions runner, and used TruffleHog against the victim's own filesystem. Microsoft's Defender research team documented the campaign in detail, including a detail that ought to be taught in every onboarding session: some malicious commits were authored under the name "Linus Torvalds." A display name is not an identity. It never was.
The 2026 variants got worse. Later waves spanned npm and PyPI simultaneously, installed persistence hooks into local AI coding tools so every future session re-executed the payload, and — in at least one documented case — shipped malicious packages carrying valid SLSA Build Level 3 provenance attestations, because the release pipeline itself was the thing that got hijacked. Provenance proved the artifact came from the expected pipeline. It did not prove the pipeline was still yours.
The Number That Explains Everything
Here is the structural fact under all of this. Tidelift's maintainer research has found, across multiple years, that roughly 60% of open source maintainers are unpaid, and that unpaid maintainers overwhelmingly work alone. The same research found paid maintainers were about 55% more likely to have implemented core security practices — the gaps are stark on exactly the controls that matter here, including published security disclosure plans and signed releases with artifact provenance.
Read that against the xz timeline and the picture resolves. A social-engineering campaign targeting an exhausted solo volunteer is not a sophisticated attack. It is the cheapest available attack, and it is cheap because the ecosystem has spent two decades extracting enormous value from people it declined to pay. Roughly 60% of maintainers report having quit or seriously considered quitting. Every one of those exits is a project looking for a new maintainer, which is to say a project with an open application process for adversaries.
Hardening the Layer You Cannot Compile
Concrete things that actually change the risk profile, roughly in order of effort-to-benefit:
- Add a soak period. New versions sit for 24–72 hours before your builds adopt them. Nearly every worm in this family was caught within that window.
-
Kill install scripts by default (
npm ci --ignore-scripts) and allowlist the handful of packages that genuinely need them. - Move from long-lived tokens to trusted publishing / OIDC, and require WebAuthn rather than TOTP for publish operations.
- Treat CI secrets as already-leaked. Short TTLs, narrow scopes, no ambient cloud credentials on build runners.
- Verify commit signatures, because display names are free and signatures are not.
- Audit maintainer concentration in your dependency tree — a bus factor of one is a security finding, not a trivia fact.
- Fund the maintainers you depend on, which is the only item on this list that reduces the attack surface rather than merely observing it.
What This Means If You Are the One Being Trusted
Flip the perspective. If you ship a library, run a dev tool company, or maintain anything other people build on, the same mechanics apply to you, just with the polarity reversed.
Your credibility is what buys you the benefit of the doubt during an incident, the willingness to upgrade, the assumption of good faith when something breaks at 3am. It is also, uncomfortably, the thing an attacker would inherit if they compromised your publishing pipeline. Both facts point to the same discipline: make your identity verifiable rather than merely familiar. Signed releases. A SECURITY.md with real response timelines. Named humans attached to decisions. Provenance you can explain. A public record of how you behaved the last time something went wrong.
That work is slow and it does not trend. It also cannot be faked on a two-year timeline by a determined adversary, which is more than can be said for a friendly commit history.
The Uncomfortable Conclusion
We spent years building cryptographic verification for artifacts and almost none for the humans authorized to produce them. Sigstore, SLSA, and SBOMs all answer "did this come from where it claims?" None of them answer "should that place still be trusted?" The 2026 attestation-carrying worm demonstrated that gap in production.
The honest position is that trust in software is transitive, unmonitored, and granted mostly by vibes accumulated over time. Attackers understood that before we did. The defense is not more suspicion of strangers — open source dies without newcomers. The defense is making trust explicit, revocable, observable, and, wherever money is involved, actually paid for.
Check your package-lock.json. Then check who maintains the top twenty entries, and whether any of them have posted in the last six months.
Top comments (0)