SLSA Provenance Didn’t Stop the Keyv npm Worm. It Vouched For It.

Every poisoned version of Keyv that went out this week carried a valid SLSA attestation and a legitimate OIDC signature. The build pipeline ran exactly the way it was supposed to. The provenance record was accurate. And the package was malicious anyway.

A worm that started in keyv@6.0.0 spread through a preinstall script into hundreds of packages across multiple maintainers on npm. SafeDep verified 353 poisoned versions across 79 package names before the wider estimates from other vendors got contested. The payload harvested GitHub, npm, cloud, Vault, Kubernetes, database, and private key material from any developer laptop or CI runner that executed it, then used whatever publishing access it stole to poison the next package down the line.

In my last few board conversations about a portfolio company’s security posture, someone always brings up SLSA level like it closes the question. It closes a much narrower question than most people in that room think it does.

SLSA and OIDC-based provenance prove something specific and real: this artifact came out of the build workflow it claims to have come from, signed by the identity that workflow is authorized to use. That’s a genuine improvement over the world before it, where you had no way to tell if a package on the registry matched the code in the repository at all. But it proves the pipeline ran cleanly. It says nothing about whether the source that entered the pipeline was trustworthy in the first place.

The Keyv incident is almost a controlled experiment in that gap. The poisoned release passed through the project’s legitimate GitHub Actions release workflow, so it inherited a clean, verifiable attestation. The commit that planted a second execution path, a set of dormant Claude Code and VS Code hooks in the repository itself, carried a green GitHub-verified badge. Its author field read github-actions[bot]. Both of those facts are completely real. Neither one tells you who actually controlled the credential that submitted the commit. The badge confirms a signature was valid. It cannot confirm the intent behind what was signed.

The payload also assumed defenders would follow the standard incident response script, and built around it. It installed a credential-revocation watcher, so a responder who rotated exposed tokens before removing the watcher would trigger an attacker-controlled handler instead of closing the hole. Standard practice, the thing every playbook tells you to do first, became the trigger. That’s the kind of design decision that tells you this wasn’t opportunistic. Someone modeled how a security team actually responds and built a trap into the response itself.

None of this is new as a technique, which is the part that should worry buyers more than the technique itself. Semgrep documented the same setup.mjs filename, the same Claude Code and VS Code hooks, and the same Bun binary download pattern in an April compromise of the PyTorch Lightning package on PyPI. Aikido places the August activity in the same Shai-Hulud malware family that hit npm packages earlier this year. This is an operating pattern from a group that has run this exact playbook across at least two package ecosystems in under four months, and the industry’s main structural defense against it, cryptographic build provenance, was present and valid in every instance.

I’ve sat through enough vendor security reviews to know how this plays out in a room. A startup puts “SLSA Level 3” or “provenance-verified builds” on a due diligence questionnaire, and it reads as a checked box. It should read as one narrow control among several, not a substitute for reviewing what actually goes into a release. The buyers who get burned aren’t the ones who skip provenance. They’re the ones who stop asking questions once they see it.

There is a real structural fix moving through the ecosystem right now, and it’s more mundane than any attestation framework: npm 12 disables dependency lifecycle scripts, including preinstall, by default. That single change would have blocked this exact worm’s execution path on any client running it, no signature verification required. It’s a less elegant story than “cryptographically verified supply chain,” and it will matter more in practice, because it removes the capability instead of trying to vouch for how it was used.

The gap here isn’t a Keyv problem or an npm problem. It’s what happens whenever an industry adopts a control that verifies the wrong layer and markets it as verifying the right one. SBOM mandates have the same failure mode: a bill of materials tells you what’s in the box, not whether what’s in the box was safe when it went in. Provenance tells you the box wasn’t tampered with in shipping, not that the factory wasn’t compromised.

So here’s the concrete test, and any security team or investor can run it in the next vendor conversation. Ask what the provenance attestation actually covers: does it extend to a source review step before code enters the build, or does it start at the point the build workflow triggers. If the answer is the build workflow, the attestation is honest and useful and covers exactly the scope the Keyv worm exploited without friction. Ask the question anyway. Most vendors haven’t been asked it yet, and watching whether they know the difference tells you more about their security maturity than the badge does.

Amit Spitzer is CTO and CISO at Glilot Capital, an early-stage VC investing in cybersecurity, AI, and enterprise infrastructure.