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.

What the List Actually Buys You

I don't want to undersell SBOMs here, because the underlying idea is sound and the win is real when an incident actually hits. When Log4Shell detonated in December 2021, the organizations that recovered fastest weren't necessarily the most sophisticated — they were the ones who could answer "where does Log4j live in our environment" in minutes instead of weeks, because someone had already built the inventory. That's the entire value proposition in one sentence: an SBOM turns "do we use this component, and where" from an open-ended archaeology project into a query.

That value is now backed by regulatory teeth on both sides of the Atlantic. U.S. Executive Order 14028 pushed federal software vendors toward SBOM delivery starting in 2021, and the EU's Cyber Resilience Act has since raised the stakes for anyone selling software with digital elements into the European market: vulnerability and incident reporting obligations begin September 11, 2026, and the full SBOM and secure-by-design requirements land on December 11, 2027, backed by fines that can reach €15 million or 2.5 percent of global turnover. Compliance teams I talk to are treating this less as a paperwork exercise and more as a forcing function, which is the right instinct. But forcing functions only produce good outcomes if people understand what the artifact actually does — and what it was never built to do.

When the Ingredient List Becomes the Worm

If xz-utils illustrates a poisoned ingredient sitting still inside a static list, the npm ecosystem spent the back half of 2025 demonstrating what happens when the poison starts moving on its own. On September 15, security researchers identified a self-replicating piece of malware that came to be called Shai-Hulud, which spread by stealing developer credentials and npm publishing tokens, then using those tokens to inject itself into every other package the compromised maintainer had access to — silently republishing trojanized versions across the registry. It traced back to an account-takeover incident from late August known as the s1ngularity/Nx compromise, and by the time researchers had mapped it, more than 500 packages had been touched, including infrastructure used by CrowdStrike. Unit 42 later assessed, with moderate confidence, that the malicious shell script itself had been drafted with the help of an LLM — based on the comments and emoji left in the code, which is the kind of detail that makes this beat simultaneously fascinating and exhausting to cover.

The worm didn't stay down. A second wave — Shai-Hulud 2.0 — surfaced in late November 2025, this time executing during the pre-install phase rather than post-install, which widened its reach into CI/CD pipelines well before any human reviewed the package contents. By the time defenders had a handle on it, the campaign had touched more than 25,000 GitHub repositories across roughly 350 accounts. Sonatype's 2026 State of the Software Supply Chain report puts the broader trend in context: more than 454,000 newly identified malicious packages in 2025 alone, pushing the cumulative known total past 1.2 million across npm, PyPI, and similar registries — a haul that reportedly even included output from North Korea's Lazarus Group, which alone published several hundred trojanized npm packages over the year.

This is where the metaphor in this piece's title stops being a metaphor. An SBOM is a snapshot taken at build time. A self-propagating worm doesn't wait for your next build. By the time your inventory catches up to what's actually running in production, the compromised version may already have spread three hops further than the document describing it.

Why Signing and Provenance Close Part of the Gap

The honest fix isn't a better SBOM. It's pairing the SBOM with proof of where the artifact actually came from, which is what the Sigstore project and the SLSA framework exist to provide. Sigstore's components do three specific jobs: Fulcio issues short-lived signing certificates tied to a developer or CI identity via OIDC, instead of the long-lived private keys that inevitably end up mismanaged; Cosign signs and verifies the resulting artifacts; and Rekor records every signing event in a public, append-only transparency log, so a substituted artifact leaves a visible gap rather than a silent one. SLSA layers maturity levels on top of that: Level 2 is now realistic to reach in an afternoon on GitHub Actions, largely because GitHub's native attestation support has matured since 2024, and the Linux Foundation pushed out SLSA 1.2 in late 2025 with more granular tracking for both build and source provenance.

Run the GhostAction incident from earlier in 2025 through that lens, and the gap becomes obvious. Attackers compromised a widely used third-party GitHub Action and modified its workflow code to exfiltrate secrets, and because downstream repositories had pinned that action by a mutable version tag rather than an immutable commit SHA, every project referencing @v1 automatically pulled the poisoned update with zero additional effort from the attacker. Signed provenance tied to a specific, verified commit wouldn't have stopped someone from compromising the upstream repository — but it would have made the substitution detectable the moment a consuming pipeline tried to verify what it was actually pulling, instead of trusting a tag that anyone with write access could quietly repoint.

What a Mature Pipeline Actually Refuses to Run

The pattern I'd point any engineering leader toward right now isn't exotic, it's just rarely implemented end to end: nothing gets promoted unless it clears a gate that checks signature, provenance, and SBOM together, not any one of the three in isolation.

Source Commit
      |
      v
Build System
      |
      ----generate----> SBOM (CycloneDX/SPDX)
      |
      |--sign via Cosign---> Signature + SLSA Provenance (Rekor log)
      |
      v
Deploy Gate
      <----checks all three---->
      [Signature valid?
       Provenance matches?
       SBOM clean of known CVEs?]
      |
PASS --------> Production
      |
FAIL --------> Blocked, alert raised, artifact quarantined

Notice what that gate is actually doing: it isn't asking "do we have an SBOM," which is a yes/no compliance question. It's asking whether the artifact about to run matches the provenance it claims, whether that provenance traces to an approved build system, and whether the components it declares are still considered safe as of right now rather than as of whenever the document was generated. Kubernetes admission controllers and policy-as-code tools can enforce exactly this today — refusing to schedule any image lacking a valid signature, with human review reserved for the exceptions the policy can't resolve automatically.

The Part Nobody Wants to Hear

SolarWinds remains the cautionary tale everyone reaches for, and fairly, the absence of meaningful supply-chain visibility let that compromise propagate to roughly 18,000 customers before anyone outside the attackers understood the scope. But I'd argue the more instructive lesson of the past two years is the opposite kind of failure: organizations that have an SBOM, dutifully generated at every release, sitting in a compliance folder nobody has reopened since. Cloudsmith's research into current practice keeps surfacing the same pattern — SBOMs produced once at build time and then never looked at again, which makes them a point-in-time artifact masquerading as an ongoing control.

My honest prediction for the next eighteen months: the EU's reporting deadline this September is going to force more genuine automation into supply-chain pipelines than three years of SBOM evangelism managed on its own, simply because a 24-hour reporting clock doesn't tolerate a quarterly spreadsheet review. Regulation rarely produces elegant security architecture. It does, reliably, produce urgency — and on this particular problem, urgency has been in short supply for exactly the wrong reason: the list looked complete, so everyone assumed the kitchen was safe.