The xz backdoor was a social engineering attack and we responded with more scanners

The xz backdoor gets retold as a supply-chain security story, and it is one, but the retelling usually skips the part that mattered.

The technical work was extraordinary — an obfuscated payload hidden in binary test fixtures, a build-system hook that only triggered in distro packaging, an IFUNC resolver hijack that let it intercept the RSA verification path in sshd. Genuinely first-rate tradecraft. It was caught by an engineer investigating a half-second of unexplained latency in an SSH login, which is the most Unix ending any story has ever had.

But none of that was the attack. That was the payload. The attack was the two years before it.

The actual technique

A single maintainer had been running xz-utils for years, largely alone, largely unpaid, and had said publicly that he was struggling with long-term mental health issues and had limited capacity to maintain it.

A new contributor appeared. Helpful. Competent. Patient. Submitted real, useful patches over a long period and built genuine trust. Then, alongside that, a set of accounts began pressuring the maintainer in the issue tracker — complaining about slow releases, questioning whether the project was adequately maintained, suggesting the burden should be shared with someone more active.

Push on one side, offer relief on the other. The maintainer, exhausted and being told publicly he was failing the project, handed over commit rights to the person who’d been helping.

That’s the attack. Everything after it was engineering.

What we built in response

A great deal, and most of it good in its own right: SBOM mandates, reproducible builds pushed forward, dependency scanning everywhere, provenance attestation, sigstore adoption, more scrutiny of build artifacts that differ from repo contents.

Reproducible builds genuinely would have helped here — the payload lived in the release tarball and not in the git tree, and a build that reproduces from source catches exactly that. That work deserves the attention it got.

But an SBOM would have listed xz-utils as a dependency, at the correct version, with the correct hash, signed. Every box green. The library was legitimately in the tree, legitimately released, legitimately signed by its legitimate maintainer. Provenance verifies that the artifact came from the source it claims. It cannot tell you the source was compromised by someone with commit rights, because from the tooling’s perspective, nothing anomalous happened at all.

We hardened the parts of the pipeline that a machine can check, because those are the parts a machine can check. The compromised link was a human being under sustained pressure with nobody helping him.

The number that hasn’t moved

Here’s the part I keep coming back to. After the most attention-grabbing supply chain incident in the history of open source, go count the critical libraries in your dependency tree with exactly one active maintainer.

It has not meaningfully changed. In some ecosystems it’s worse, because the number of transitive dependencies keeps growing while the pool of people maintaining them doesn’t.

The xkcd about the entire edifice resting on a project some person in Nebraska has been thanklessly maintaining since 2003 stopped being funny somewhere around 2024. It’s now just a description of the threat model, and we’ve responded to it by adding a scanner that confirms the Nebraska project is present at the expected version.

I said funding wouldn’t fix it. I was partly wrong.

My position at the time was that money doesn’t solve this — you can’t pay someone into caring, and a maintainer with a stipend is still one person with commit rights and a finite amount of resilience.

What I underweighted is that the attack vector was specifically isolation and exhaustion. Not incompetence. Not malice. A person alone, tired, being told publicly he wasn’t keeping up. Funding doesn’t fix that directly. But funding buys co-maintainers, and a project with three active maintainers is dramatically harder to socially engineer than a project with one — there’s someone to review the commit, someone to notice the pressure campaign, someone to say “that’s weird” out loud.

Sovereign tech funds and the corporate foundations that followed have put real money into exactly this. Not enough, and distributed unevenly toward projects that are already visible. But it’s the first mitigation anyone deployed that’s aimed at the layer where the attack actually happened, and I was wrong to dismiss it.

The uncomfortable version

If you ship software commercially, you have a dependency tree, and somewhere in it is a project maintained by one exhausted person who has never received a cent from you.

You can scan that dependency. You can sign it, attest it, list it in a bill of materials, and pin its hash. None of that touches the actual risk. The actual risk is that they’re alone, and someone patient is being very helpful to them right now.