PROVENANCE THEATRE :: Signed Is Not Safe and SLSA Was Never the Whole Answer

PROVENANCE THEATRE :: Signed Is Not Safe and SLSA Was Never the Whole Answer

slsasigstoreprovenancesupply-chaintrust-model

The supply-chain security industry spent four years selling SLSA as the answer to package compromise. SLSA — Supply-chain Levels for Software Artifacts — is a framework for build provenance. It gives you cryptographic attestations that a package was built by a specific pipeline in a specific repository on a specific reference. The pitch was: when your build environment is signed end-to-end, you can verify what you are running.

The TanStack compromise of May 11, 2026 is the case study that demonstrates what SLSA actually does and what it does not do. The SLSA attestations on the compromised TanStack packages were valid. Cryptographically valid. Issued by the right repository's release.yml workflow, running on refs/heads/main, in TanStack/router.

The packages were malware.

What the attestation actually claims

SLSA provenance is a set of structured claims about how an artifact was built. The claims are well-defined. They are also narrower than most consumers assume.

The provenance attests:

• The artifact was produced by build process X (workflow file, runner, build steps)
• The build process ran in environment Y (repository, ref, commit SHA)
• The build process was invoked at time T
• The cryptographic identity of the build system signing the attestation

The provenance does not attest:

• That the build process was authorized to run for this purpose
• That the source code at the attested commit had not been tampered with prior to the attested commit
• That the build inputs — caches, downloaded dependencies, base images, environment variables — were unmodified
• That the build workflow itself was the workflow the repository maintainers intended
• That the triggering event was legitimate

The gap between "what provenance attests" and "what defenders assume provenance attests" is the attack surface the TanStack chain exploited.

The TanStack mechanics, abbreviated

Briefly, because the chain has been covered in detail elsewhere:

1. Attacker forks the TanStack/router repository under a deceptive name to evade fork-list searches
2. Attacker opens a pull request from the fork; the upstream's pull_request_target workflow runs with the upstream's secrets, but checks out and executes the fork's code
3. Attacker-controlled workflow poisons the GitHub Actions cache with a malicious pnpm store
4. Maintainer later merges a legitimate PR to main; the legitimate release workflow restores the poisoned cache as part of its build
5. Build environment runs attacker-supplied code; attacker code reads the OIDC token from the runner process's memory and uses it to publish to npm

From SLSA's point of view, every step of this is legitimate. The build ran in the right repository, on the right branch, via the right workflow, with the right OIDC token. The provenance is true. The build is malicious.

Why this is not a SLSA bug

SLSA is not broken. SLSA is doing what it claims to do. The bug is in the trust model layered on top of it.

The industry sold SLSA-attested packages as inherently trustworthy. That is not what SLSA promises. SLSA provides verifiable evidence of where a build happened. The trustworthiness of "where a build happened" depends on whether the build environment is trustworthy in the first place. If the build environment is compromised — through cache poisoning, through pull_request_target abuse, through a malicious workflow committed to main, through credential theft, through any of the other paths that compromise build environments — then the SLSA attestation is faithfully reporting on a compromised build.

SLSA was always a building block. The industry treated it as the foundation.

What sufficient supply-chain trust actually looks like

SLSA is one control in a defense-in-depth stack. The other controls in that stack:

• Source authenticity. Branch protection, signed commits, required reviews, mandatory CI checks before merge. The commit that triggered the build was authorized by the maintainers.
• Workflow integrity. The workflow file at the attested ref is the workflow the maintainers intended. No surprise modifications. Branch protection on workflow paths specifically.
• Trigger authenticity. The build was triggered by a legitimate event from a legitimate principal. Manual triggers, scheduled triggers, push triggers to protected branches. Not pull_request_target from arbitrary forks.
• Input integrity. Build caches, dependencies, base images, environment configurations — all sourced from trusted locations, verified before use. The poisoned cache attack is mitigated by either disabling cross-context cache sharing or by verifying cache contents before use.
• Build isolation. Build environments should be ephemeral. Network-restricted. Unable to publish without a specific authorization step. The OIDC token should not be accessible from arbitrary processes inside the runner.
• Trusted publisher pinning. When OIDC trusted publishing is used, pin to specific workflow and specific branch. The default loose configuration is exploitable.
• Publishing approval. A human approval step before any package version goes to production. Inconvenient for fast-moving projects. Effective for slowing down attack windows.
• Runtime verification. Once published, downstream consumers verify not just the SLSA attestation, but also: lockfile diffs, dependency tree diffs, behavioral comparison against the previous version, security tooling on installed packages.

SLSA attestation is one signal in this stack. A useful signal. Not a sufficient signal.

The wider pattern

Cryptographic attestations have a general failure mode: they say what they say, and consumers infer more than what they say.

Examples:

• A code-signing certificate attests that a binary was signed by a key controlled by a specific entity. It does not attest that the entity intended to sign that specific binary, that the signing infrastructure was uncompromised, or that the binary's behavior is benign.
• A TLS certificate attests that a server controls a domain name. It does not attest that the server is operated by the organization the domain is associated with, that the content served is authentic, or that the server is uncompromised.
• A package signature attests that a package was published by a key. It does not attest that the key holder published this version intentionally.

The general principle: cryptographic evidence is necessary but not sufficient. The trust decision requires combining cryptographic evidence with operational evidence (was the build environment uncompromised?) and behavioral evidence (does this artifact behave like the previous artifact from this source?).

The takeaway

If your supply-chain security strategy is "verify the SLSA attestation," your supply-chain security strategy is incomplete.

Verify the attestation. Then verify that the build environment that produced the attestation was uncompromised at build time. Then verify that the artifact behaves consistently with previous artifacts from the same source. Then run runtime detection on what the artifact does once installed.

Signed does not mean safe. Attested does not mean authorized. Reproducible does not mean trustworthy when the inputs were tampered with. The signature is a claim. Treat it as one input to a trust decision, not the decision itself.

The supply-chain industry will sell you the next silver bullet within 18 months. It will work better than SLSA on the failure modes SLSA does not address, and it will fail to address some new class of failure modes that an attacker will find within 24 months. The control stack is the answer. The single-control answer has never been the answer.