Supply Chain Attacks Bypassed Every Trust Signal We Built
When the May 2026 TanStack compromise produced validly-attested malicious packages, it exposed a gap between what provenance proves and what security requires.
A few years ago, at a payment processing company where I was leading engineering, we walked a compliance auditor through our dependency security posture. Lockfiles enforced across all pipelines. Two-factor authentication on every npm publisher account. Provenance attestations enabled and verified on publish. The auditor said we had the strongest supply chain controls he'd seen at a fintech that size. I left that room thinking we'd gotten that one right.
Last week I read the TanStack postmortem.
On May 11, 2026, attackers compromised 84 package versions across the TanStack npm namespace, including libraries that handle routing and querying for millions of React applications. The @tanstack/react-router package alone had over 12 million weekly downloads. The attack was part of a broader campaign that eventually touched 160-plus npm package versions, including Mistral AI tooling and the Bitwarden CLI. All of it was part of something researchers named Shai-Hulud, the fifth wave in eight months.
What made this one different was what the malicious packages carried: valid SLSA Build Level 3 provenance attestations, signed by Sigstore infrastructure. The first documented instance of this on npm.
The attestations were real, and they proved a narrower fact than the verification chain required.
SLSA provenance attests that a package was built by a specific repository's GitHub Actions run. What it doesn't attest is whether that workflow was authorized to run, whether it executed from a protected branch, or whether the commit that triggered it was legitimate. The attackers understood this boundary precisely. They pushed an orphaned commit (no parent history, no branch) to a forked repository. Orphaned commits don't exist on any branch, so they bypass branch protection entirely. That orphaned commit triggered a legitimate GitHub Actions workflow, which issued a valid OIDC token because the trusted publisher configuration granted trust at the repository level rather than scoping it to specific workflow files or protected branches. Packages went to npm. Sigstore signed the provenance. TanStack had 2FA enabled and lockfiles in place. Every control was present and operating correctly. The scope of each one was simply too broad for this attack class.
I've spent most of my career in fintech, health, and payments, industries where "we have an audit trail" is supposed to close the conversation. The thing I learned slowly, across several organizations, is that an audit trail proves only that an action occurred through a pathway the system already recognized as legitimate, which is a narrower fact than authorization. An audit log showing a record was accessed by a user with the right role still leaves open whether the role was configured correctly. A provenance attestation showing a package was built by a legitimate workflow still leaves open whether the workflow was allowed to run on that commit. Both systems are doing exactly what they were built to do, which is a narrower job than answering the question you actually need answered.
What engineering leaders need to update is the mental model behind the tooling list. Most teams with mature practices already have the controls the postmortem would recommend. The gap is in how they reason about what those controls prove. The framing that holds up under attacks like this one asks, for every trust signal in the chain, what each signal actually attests and what gap it leaves for someone who knows where that proof ends.
What I didn't ask in that compliance review, and what the auditor didn't ask either, was whether any of our controls would fire if a legitimate workflow ran on a commit that was never supposed to trigger it. We reviewed the presence of controls and stopped there. The question of whether the OIDC configuration backing provenance was scoped tightly enough to block an orphaned commit from an uncontrolled fork never came up. Nobody modeled the failure mode where the trust mechanism itself becomes the attack surface.
The practical fixes from this incident are tractable. Pin OIDC trust to specific workflow files and specific protected branches, not just repositories. Run `npm ci --ignore-scripts` in CI pipelines, which blocks lifecycle script execution and eliminates the primary delivery mechanism for most of the Shai-Hulud variants. Treat any commit with no parent history as suspicious before your CI processes it. None of these changes are difficult to make. They require someone to revisit configurations set up when the threat model was simpler and tighten the scope.
The harder change is in how you frame dependency security to your leadership and your team. "We have provenance, we have 2FA, we have lockfiles" describes a set of controls without describing the threats those controls were chosen to address. A more honest frame: for every trust signal in your supply chain, what exactly does it attest, and what does it leave open to someone who knows where that attestation ends?
That question gets uncomfortable quickly. Most teams don't fully control the GitHub Actions environment they run in, the infrastructure that signs their provenance, or the OIDC token policies of the registries they publish to. They trust those systems because those systems have been trustworthy. That trust is earned. The problem is treating the output of those systems as sufficient proof of authorization without also controlling what those systems are allowed to attest.
I don't have a clean answer for every dependency in my own stack. After reading the TanStack postmortem, the absence of that answer carries different weight. It's become unfinished work I owe my own team.