Valid provenance is not valid code: a supply-chain worm shipped with a valid SLSA attestation

In May 2026, a supply-chain worm did something the security community had been warning about for years: it got the receipt.

According to Akamai's analysis, the May 11–12 wave of the Mini Shai-Hulud campaign didn't steal an npm token. It poisoned a GitHub Actions CI cache through a fork-pull-request misconfiguration in the TanStack release workflow, waited for a legitimate maintainer merge, then ran inside the trusted release pipeline. The worm scraped credentials from the runner's memory and exchanged them for publish credentials through npm's own OIDC token endpoint. The result, in Akamai's words, was that the attack was "invisible and grant[ed] it SLSA attestation validation." (Akamai Security Intelligence Group, May 15 2026)

Across the full campaign (an earlier wave hit SAP's @cap-js packages, PyTorch Lightning, and Intercom in late April/early May), Cloud Security Alliance counts 180+ compromised packages, 400+ malicious versions, affecting packages with more than 518 million cumulative historical downloads. (CSA research note)

The worm also installed persistence into Claude Code session hooks and VS Code task automation — which means it specifically dug into the agent tooling layer, and survived an npm uninstall.

What the attestation actually attests

This is not a Sigstore flaw, and it's not a SLSA flaw. The provenance system worked exactly as designed. A SLSA Build Level 3 attestation answers one question:

Was this artifact produced by the trusted build environment, from the claimed source?

It does not answer:

Is the code in this artifact what the maintainer thinks it is?

When the build environment itself is compromised, the attestation is produced honestly — by a dishonest environment. The signature is valid. The certificate is valid. The log entry is valid. The code is a worm.

Valid provenance is not valid code.

Keyless signing (the Sigstore/Fulcio model) binds identity to a short-lived OIDC token issued to the CI environment. That's a great default for the overwhelming majority of projects, and we use the same transparency log it writes to (more on that below). But it draws the trust boundary around the build environment — and the build environment is exactly what Mini Shai-Hulud attacked.

Two layers the receipt doesn't cover

Reading the post-incident writeups, two gaps keep showing up:

1. Content-first evidence. Attestations are environment-first: they certify where and how something was built. A content-first receipt certifies what the code is: a canonical manifest of every file and its hash, signed, anchored to a transparency log, with a durable citation that outlives any single registry or CI system. You can answer "does this byte-for-byte match what was anchored at release time?" offline, without asking anyone's server.

2. An optional key-isolation path. Keyless signing has no concept of "the signing key never touches CI." For most projects that's fine — convenience wins. For high-assurance releases (infrastructure packages, agent runtimes, anything that harvests credentials by design), there's value in a mode where the signing key lives outside the runner: an offline signer, a human approval step, or a KMS. Compromising a runner then no longer yields the ability to mint a valid release identity. The ecosystem has the building blocks (cosign supports bring-your-own keys), but the content-manifest-and-durable-anchor layer around them is still DIY.

There's also a third gap that matters specifically for AI assets: hashes answer "is this identical," but never "is this derived from mine." A model fine-tuned from your weights, or a plugin forked past recognition, hashes differently by design. That requires semantic comparison — a different problem from signing.

What we built (and what we refuse to claim)

We work on this problem. Our open-source code birth certificate produces a signed content manifest (JCS-canonical hashes, Ed25519), anchors it to the public Rekor transparency log, and optionally mints a Zenodo DOI as a durable citation. A zero-configuration GitHub Action runs it on release; verification needs no account and no server of ours — the public key is embedded in the receipt, so verification is fully offline.

Our own dogfood anchors are public and independently checkable: Rekor log index 2694324795 with DOI 10.5281/zenodo.22266162. The GitHub Action that mints these certificates anchors its own repository on every run inside CI — the latest such self-anchor is Rekor index 2695953558, produced by a public GitHub Actions run rather than anyone's laptop.

Three things we want to be explicit about, because a supply-chain incident is a bad time for marketing ambiguity:

• If you run our Action with the signing key stored in a CI secret, you stand on the same side of the trust boundary as keyless signing. That's the convenience mode, and it's a reasonable default. The key-isolation mode — key held outside the runner — is the one that changes the threat model. Pick deliberately.
• We build on Sigstore, not against it. Our anchors are Rekor entries. We're an application layer on top of the public transparency-log ecosystem, not a replacement. "Sign everything keyless by default" remains the right advice for most projects.
• Anchoring proves existence, timestamp, and content binding — nothing else. It doesn't prove code is safe, isn't malware, or isn't infringing. A DOI is evidence of existence and timestamp, not a copyright registration. And no signature — ours or anyone's — would have stopped Mini Shai-Hulud's persistence in Claude Code hooks. That's a runtime problem: what the agent does after install, which is the other half of what we work on.

The practical takeaway

After Mini Shai-Hulud, the question "is your supply chain signed?" is no longer enough. Three better questions:

1. Does the receipt certify the build environment — or the code's content? Ideally both, and you should know which you're looking at.
2. Where does the signing key live? "Short-lived token inside the runner" is fine until the runner is the target. Know your mode.
3. What watches the code after it runs? Signed packages can still be worms. Agents that install hooks into your editor doubly so.

Attestations got us from "trust me" to "trust the build." The next step is "trust the content — and verify it yourself."

---

We're Correctover — we build evidence infrastructure for the AI age: verifiable provenance for code and runtime assurance for agents. The birth-certificate tooling is open source (MIT); the transparency logs and DOI registry it uses are public infrastructure maintained by the Sigstore and Zenodo communities.