The xz backdoor of 2024 showed that the thing people audit, the git source, can differ from the thing people install, the release tarball. Attestations, such as signed build provenance, make that difference checkable. They do not tell you whether the code itself is trustworthy.
What happened with xz?
On 29 March 2024, developer Andres Freund posted to the oss-security list that the upstream xz repository and tarballs had been backdoored, after noticing odd symptoms with ssh logins on Debian sid: high CPU use and valgrind errors. He wrote that one part of the backdoor lived solely in the distributed tarballs. A line in a build macro file, present in the tarballs for 5.6.0 and 5.6.1, was not in the upstream source and was not used by xz in git. It injected an obfuscated script that ran at the end of configure.
CISA's alert, the same day, assigned CVE-2024-3094 to malicious code in XZ Utils 5.6.0 and 5.6.1 and recommended downgrading to an uncompromised version such as 5.4.6, hunting for malicious activity and reporting findings.
Where would an attestation help?
Where a tarball and a git tag disagree. An attestation is a signed statement about an artifact. Build provenance, as defined by SLSA, says what entity built an artifact, by what process and from what inputs. At Build L2, provenance is signed and generated by a hosted build platform, which protects against tampering after the build.
If a release is built by a platform from a named commit and the provenance records that commit, a consumer can check that the artifact came from the expected source and process. A tarball assembled by hand with extra files would either have no provenance or provenance pointing somewhere unexpected. That is a check, not a guess.
Where would it not help?
Provenance does not read code. If the malicious change is committed to the repository and built by the official pipeline, the provenance is valid and the artifact is still malicious. Attestation answers "was this built as claimed?", not "is it safe?". Human review, maintainer trust and behavior monitoring remain separate problems. I have not seen a source that says provenance alone would have stopped this case, so do not read that into it.
How do SBOMs fit?
An SBOM tells you whether xz 5.6.0 or 5.6.1 is in a product, which is what teams needed on 29 March 2024. The 2026 SBOM minimum elements add a component hash and an SBOM signature, so the inventory itself can be verified. Together: the SBOM says what you have, the attestation says how it was made.
Constructed example: a distribution packager gets a new upstream release. Its script builds from the git tag and also downloads the release tarball, then compares file lists. Any file in the tarball and not in git is flagged for human review before the build proceeds. That one check targets exactly the mismatch described above.
Why was the tarball an effective hiding place?
Because most people read the repository and install the release. Code review, static analysis and contributor discussion all work on the git tree. The tarball is a separate artifact, and nobody compares them by default. Whoever controls the release step controls what users receive.
That is the real lesson for attestation: the gap between reviewed source and shipped artifact is a place to put a control, and a verifiable record of how the artifact was made narrows it. The control is only as good as the checks consumers actually run.
What to do
- For critical dependencies, compare the release artifact with the tagged source and review differences.
- Prefer building from source in your own pipeline for the most sensitive components.
- Ask upstream projects for signed provenance and verify it when available.
- Keep SBOMs with hashes so you can find every product containing a bad version fast.
- Monitor for behavior change in packages that run in sensitive paths.
- Treat unusual maintainer or release changes as a review trigger.
Safeguard's SBOM and dependency scanning helps you find where a given version is in use and policies and gates can block known bad versions. It cannot make a malicious maintainer trustworthy.
Quick check
Would a signed release have caught xz?
A signature proves who published an artifact, not that the contents are benign. A maintainer's own signature on a backdoored release would still verify.
What is the cheapest control?
Diffing a release artifact against its source tag for dependencies that matter, and pinning versions.
Sources
- Andres Freund, backdoor in upstream xz/liblzma (oss-security, 29 March 2024)
- CISA alert, CVE-2024-3094 in XZ Utils
- SLSA specification v1.0: levels and tracks
- CISA, 2026 Minimum Elements for a Software Bill of Materials (SBOM)
Last reviewed: 18 October 2026.
