The xz backdoor: what CVE-2024-3094 means for your supply chain

On March 29, 2024, a Microsoft engineer named Andres Freund noticed that SSH logins on a test machine were running about half a second slower than they should. Chasing that half-second led him to one of the most sophisticated supply-chain attacks the open-source world has ever seen: a backdoor, planted in the xz compression library (CVE-2024-3094), that was days away from shipping in mainstream Linux distributions.

What actually happened

xz is a small, unglamorous compression library that nearly every Linux system depends on, directly or indirectly. Over roughly two years, an attacker operating as a helpful volunteer maintainer earned commit rights to the project, then quietly introduced obfuscated code into the release tarballs — not the public Git source — that hijacked the SSH authentication path on systems where the library was loaded.

The attack had three properties that should worry anyone shipping software:

1. It targeted the build, not the source. The malicious payload lived in the distributed tarball and test fixtures, not in the clean Git history most people audit.
2. It exploited trust, not a bug. There was no vulnerability to patch. A human being was socially engineered into the project over years.
3. It was nearly invisible. Only a performance regression — not a security scanner — caught it.

Why an SBOM would not have "caught" it, and why you still need one

Let us be honest about the limits. A Software Bill of Materials is an inventory, not a malware scanner. On the day xz was compromised, an SBOM would have listed the trusted version number like any other dependency.

What an SBOM changes is everything that happens after disclosure. When CVE-2024-3094 dropped, every security team on earth asked the same question: do we ship xz, and if so, which version, in which products? Teams with current SBOMs answered in minutes. Teams without them spent days grepping build systems and emailing vendors.

That gap — between knowing and finding out — is the entire value of supply-chain visibility. Incident response is a race, and the SBOM is the map you wish you had drawn before the fire.

The harder lesson: provenance

xz is also an argument for caring about where your components come from, not just what they are. Two things help:

• Build provenance (for example, SLSA attestations) ties a binary back to the exact source and build process that produced it, making tarball-versus-source divergence detectable.
• Maintainer and project-health signals — how many maintainers, how recently active, how releases are handled — are increasingly part of risk scoring.

What to do this quarter

You cannot prevent the next xz with tooling alone. But you can make sure it costs you hours, not weeks:

1. Generate an SBOM for every product you ship, and keep it current with each build.
2. Make sure you can answer "where do we use component X, version Y?" across your whole estate in one query.
3. Start capturing build provenance for your most critical artifacts.

The attacker who built the xz backdoor was patient, skilled, and nearly successful. The defenders who fare best against the next one are simply the ones who already know what they ship.