The xz-utils backdoor disclosed on 29 March 2024 (CVE-2024-3094) was present in the release tarballs for versions 5.6.0 and 5.6.1 but not in the equivalent state of the public git repository: the malicious build-to-host.m4 macro shipped only in the distributed archive and activated a payload hidden in test fixtures during the build. Which assumption in a normal supply-chain pipeline does this defeat, and what would have caught it?

The situation it exploited

Autotools projects conventionally ship a release tarball that is not a copy of the repository: the maintainer runs the generator tooling and includes the output, so downstream packagers do not need matching versions of autoconf and friends. Everybody knew this and nobody treated the difference as a trust boundary.

So the artefact that distributions actually built was one nobody reviewed. The repository was clean. Code review was clean. The diff between releases, as read by humans, was clean. The malicious macro existed only in the archive, and it assembled its payload from binary test fixtures that looked like what test fixtures for a compression library are supposed to look like.

Which assumption it defeats

That reviewing the source means reviewing what is built. Nearly every supply-chain control in common use assumes an unbroken chain from a reviewed commit to a running artefact, and this attack entered between the commit and the archive:

• Signed commits and protected branches protect the repository, and the repository was not modified.
• A software bill of materials lists the components; the component here was xz at a legitimate version, and the SBOM is correct and useless.
• Vulnerability scanning looks for known identifiers; there was no identifier until after the fact.
• A signed release proves the maintainer produced the archive, which they did.

What would have caught it

1. Building from the repository rather than from a tarball, with the generator tooling run inside the build. This removes the gap entirely and is what several distributions moved towards afterwards.
2. Reproducible builds with independent verification. If the artefact is a deterministic function of a reviewed tree, a second builder gets the same bytes, and any injection that is not in the tree shows up as a mismatch. This is the strongest available control and it is the one that scales, because verification can be done by anyone.
3. Diffing the release archive against the repository and reviewing what only exists in the archive. The set is small — generated build files — and it is exactly where this lived.
4. Treating test fixtures as executable input. Binary blobs in a repository that the build touches deserve the scrutiny of code, because that is what they were.
5. Provenance that names the source tree, not the publisher. A build attestation in the SLSA sense records which commit produced which artefact on which builder. It would not have stopped a tarball-based build, but it makes the question "what was this built from?" answerable rather than assumed.

Where copying the response would be a mistake

Reproducible builds are the right answer and for most application teams the cheap 90% is different: pin every dependency by digest rather than by tag, build in a container whose base image is pinned by digest, and never let a build fetch an unpinned artefact from the internet. A full bit-for-bit reproducible build for an application pulling 900 packages costs months and may not be achievable through the toolchains you depend on.

The transferable lesson is narrower and cheaper than the headline: know whether what you build is what you reviewed. Most teams cannot answer that, and finding out costs an afternoon.

When this is the wrong thing to worry about

If your builds already run from a checkout of your own repository, with pinned dependencies, this particular gap is closed and effort belongs elsewhere — most likely on the dependencies themselves, since a compromised package installed by your pinned-but-unaudited dependency tree is the far more probable route. Rank the work by which gate is actually missing, not by which incident was in the news.