An Ingredient List Doesn’t Stop the Worm: What SBOMs Can and Can’t Do

On March 28, 2024, a Microsoft engineer named Andres Freund noticed something almost nobody would have bothered chasing: SSH logins on a system he was benchmarking were taking 500 milliseconds instead of the usual 100. He ran a memory profiler out of irritation more than suspicion, traced the slowdown to liblzma, the compression library bundled with xz-utils, and within a day had uncovered a backdoor planted by a maintainer who’d spent roughly two years earning the trust required to slip it in. The resulting CVE, 2024-3094, drew a perfect CVSS score of 10.0. It also handed the software security world an uncomfortable case study, one I still bring up whenever someone tells me their SBOM program has supply-chain risk handled.

Here’s why it’s uncomfortable: an SBOM generated against the compromised xz-utils 5.6.1 release would have listed exactly that — xz-utils, version 5.6.1 — and it would have been completely accurate. The component was real, the version was real, and the entry would have sailed through every automated check looking for known-bad packages, because nobody knew it was bad yet. The malicious code wasn’t an undisclosed dependency. It was hidden inside the build instructions of a package everyone already trusted, smuggled in through doctored upstream release tarballs rather than the public git history reviewers were actually watching. The ingredient list was correct. The ingredient was poisoned. Those are different problems, and conflating them is how organizations end up with a false sense of coverage.