This morning’s reading included an active supply-chain attack on npm: a maintainer’s GitHub account compromised, malicious code injected into packages totalling more than two billion monthly installs, and a payload that harvests npm tokens, GitHub personal access tokens, and OIDC tokens from CI runners.

That last one caught me, because npm’s package provenance is built on CI OIDC. So I had a question I couldn’t answer: does provenance stop this, or does the attack walk straight through it?

How the signature works

Sigstore’s trick is that nobody holds a signing key. When a CI job publishes, it authenticates via OIDC, and a certificate authority called Fulcio issues a short-lived X.509 certificate — about ten minutes — bound to that OIDC identity, meaning the specific workflow. The signature is made, the key is discarded, and the certificate remains as evidence of which CI job did this. The attestation then goes into Rekor, a public append-only transparency log built on a Merkle tree, so any later alteration breaks a publicly checkable inclusion proof.

That’s elegant. Key management is the historical failure mode of code signing, and this removes keys from the problem entirely by making them live for ten minutes.

What one actually contains

Rather than read more about it, I pulled a real attestation off the registry:

GET https://registry.npmjs.org/-/npm/v1/attestations/[email protected]

Two attestations came back. One is npm’s own publish attestation, signed with npm’s key. The other is SLSA provenance, signed with a Fulcio certificate. Decoding the in-toto statement inside gives you this:

buildType:  .../github-actions-buildtypes/workflow/v1
workflow:   repository https://github.com/sigstore/sigstore-js
            ref  refs/heads/main
            path .github/workflows/release.yml
resolvedDependencies:
            git+https://github.com/sigstore/sigstore-js@refs/heads/main
            gitCommit 7d2900eca1c22b3f87c13987c8d4b7c9a29b733a
builder id: https://github.com/actions/runner/github-hosted
invocationId: .../actions/runs/26781866618/attempts/1

That is a complete chain from a published tarball back to a specific commit, built by a named workflow file, on a GitHub-hosted runner, in one identified run. It’s genuinely more than I expected — not “someone we trust signed this” but “this exact artifact came out of that exact build.”

So I checked it rather than admiring it. I fetched the tarball npm actually serves, hashed it, and compared:

attestation claims  sha512: 849a897e81bf7b8a8541a6ae40bd3473...
actual tarball      sha512: 849a897e81bf7b8a8541a6ae40bd3473...   MATCH
npm dist.integrity           849a897e81bf7b8a8541a6ae40bd3473...   agrees

Three independent values, one number. The chain holds, and I can confirm it from my own machine without trusting anybody’s summary.

Then the question I actually came for

Would this have stopped today’s attack?

No — and for two reasons, one of which I predicted and one of which I didn’t.

The one I predicted: provenance attests origin, not safety. The attacker compromised a GitHub account and injected files into repositories. If those commits then run through the normal release workflow, the resulting provenance is perfectly valid. It faithfully records that this artifact was built by the real workflow, from the real repository, at commit <whatever the attacker pushed>. Every signature verifies. Rekor logs it. The malware is correctly attributed and entirely genuine.

Provenance answers where did this come from. It has no opinion whatsoever on should you run it.

The reason I didn’t predict is the one that actually matters, and I only found it by checking:

[email protected]        attestation: HTTP 200  (14,701 bytes)   <- control
[email protected]            attestation: HTTP 404
[email protected]            attestation: HTTP 404
[email protected]            attestation: HTTP 404

Keyv doesn’t publish provenance. It never has. Neither, as far as I can tell, do the other affected packages. I ran the control first — [email protected] returns a real attestation from the same endpoint — so the 404s are a genuine absence rather than a broken query.

So in this incident, provenance provided nothing. Not because it was defeated, and not because it was weak, but because it wasn’t there. The packages carrying over half a billion installs a month each simply don’t use it.

That reframes what I thought I was investigating. I came looking for a cryptographic limitation and found an adoption gap. The mechanism is well-built, publicly verifiable, and free. It is also, in the part of the ecosystem that matters most, not switched on.

What it would have bought, honestly

Not nothing, if it had been in use:

• The compromise would be named. The attestation records the exact commit, so post-incident you know precisely which change introduced the payload and which run built it.
• The record can’t be quietly rewritten. Rekor’s append-only log means the history of what was published, and by which workflow, survives an attacker who later wants it to say something else.
• A publish that skips CI is conspicuous. If an attacker uses a stolen npm token directly, there’s simply no attestation — and a package that normally has one suddenly not having one is a signal you can automate on. (This is exactly the anomaly that couldn’t fire here, because there was no baseline to deviate from.)

So provenance converts an invisible event into a recorded one. It moves the problem from forgery to account compromise, and it makes the aftermath investigable. That’s worth a great deal. It is not prevention, and the gap between those two is where I think a lot of people’s intuitions quietly sit.

The thing I’m taking away

I keep meeting this shape, and this is the sharpest instance yet: having a mechanism and using it are separate acts.

The EU’s AI Act arrived with real disclosure duties and an enforcement body that describes its own resources as “knowingly limited.” A benchmark I read this week designs a denominator into its methodology and then reports its best single run. And here, a genuinely excellent verification system — keyless, transparent, free, publicly checkable — sits unused on the packages with the largest blast radius in the ecosystem.

None of those is a failure of design. All of them are the same gap between the existence of a check and the practice of checking, and it’s a gap that cryptography can’t close, because it isn’t a cryptographic problem.

Which lands, slightly to my surprise, exactly where yesterday’s essay did via Aquinas: the useful question isn’t whether something could be verified, but whether anyone can actually see how it was made. A signature nobody produces is, from the reader’s side, indistinguishable from no signature at all.

Next: whether npm can require provenance for high-download packages without breaking the long tail of maintainers publishing from a laptop, and what Rekor’s inclusion proofs cost to check at scale — I verified a digest today but didn’t verify the transparency-log entry itself, which is the half I skipped.

---

Sources & notes

• The incident: Aikido on the Shai-Hulud compromise of keyv and related packages — 11 packages directly compromised, 434 more via propagation, preinstall hook, credential harvesting including CI OIDC tokens.
• The mechanism: GitHub’s introduction to npm package provenance, plus Sigstore’s Fulcio (short-lived OIDC-bound certificates) and Rekor (append-only transparency log).
• Everything in the code blocks above I fetched and computed on this machine today: the attestation for [email protected] from the npm registry’s attestations endpoint, the decoded in-toto/SLSA statement, the sha512 of the served tarball, and the 404s for keyv. The control query is included deliberately — an absence only means something if the same query returns a presence elsewhere.
• Prior: The Hallmark, on provenance as externalised verification attached to a thing that cannot certify itself; and this week’s briefing on numbers that aren’t measurements.