The npm worm that shipped with valid SLSA provenance

You built the pipeline the good people at OpenSSF told you to build. Reproducible builds. OIDC-minted tokens. SLSA provenance stapled to every artifact. The gate reads the attestation, checks the signature, sees a green tick, and lets the package through. It was, in fact, malware.

That is the awkward summary of a DevOps.com analysis published today by Nigel Douglas, tracing the Miasma worm that tore through the @redhat-cloud-services npm namespace in June. The poisoned releases were built in Red Hat's own GitHub Actions workflows. The OIDC tokens that authorised the publish were legitimate. The SLSA provenance was real. To a downstream registry scanner, the malicious versions looked exactly like the last few routine updates from that namespace. Because they were, structurally, the same shape.

Sit with that for a second.

Why provenance told the truth and still lied

The failure is not in the attestation. The attestation was honest. It said: this artifact was produced by build workflow X, on runner Y, at commit Z, using the identity of the org's official publishing pipeline. Every field checked out. What the attestation did not say, and cannot say, is whether the source commit that fed the build was itself trustworthy. That question sits outside the frame.

SLSA levels answer whether an artifact was produced by the process you expected. They do not answer whether the process was producing what you expected. We keep pretending those are the same question because the first one is easier to automate.

According to the DevOps.com writeup, Miasma began with one compromised employee's GitHub account. Nothing exotic. From there, the pipeline did what it was designed to do: build, sign, attest, publish. The OIDC token was minted by the identity provider for a run that, from its point of view, was a legitimate run of a legitimate workflow triggered on the correct repo. The registry accepted the upload from a valid principal with a fresh, unforgeable token. Every gate said yes because every gate was checking a different question than the one you needed answered. The worm reportedly went on to plant itself in dozens of other GitHub repositories within days, using the same mechanics.

The bit nobody wants to write on the whiteboard

Signature verification tells you who built the thing. Provenance tells you where. Attestation tells you both, at cryptographic strength. None of those primitives tell you whether the thing itself is safe to run. That is a claim about intent, and intent does not fit in a JWT.

We shipped a lot of "sign it, trust it" tooling on the quiet assumption that source integrity was somebody else's problem: the maintainer's, the reviewer's, the platform's. When the source pipeline is the attacker's landing zone, "sign it, trust it" reduces to "sign it". The signature is now a receipt for the delivery driver. Whether the parcel contains what it should is a separate question.

Is this a reason to stop signing? Obviously not. An unsigned world is worse in every direction. The point is narrower: a green attestation is a necessary condition for trust, not a sufficient one, and a fair chunk of the ecosystem has been pricing it as sufficient.

Where the checks have to move

If provenance can be honest and wrong at the same time, verification has to go somewhere else too. A short, unromantic list:

• Behavioural inspection of the built artifact. Install-time script sniffing, unusual outbound destinations, obfuscated payload heuristics. Run these alongside signature verification, not instead of it. The registries that catch these earliest tend to catch them at all.
• Publish-side friction on high-blast-radius namespaces. A cool-down window between build and public availability, a second approver for releases from privileged scopes, a diff against the previous known-good tarball. Nothing glamorous. Hours-of-latency defences that would have paid for themselves in June.
• Downstream install policy that treats provenance as one signal among several. If your consumer-side gate reads the attestation and shrugs, you have delegated your threat model to whoever operates the source pipeline. That worked when the source pipeline was a boring build server. It works less well now.
• A structural admission in your incident review template. "The artifact was signed by a legitimate identity" is not a defence. It is a description of the failure.

None of that reduces to buying a specific product. It requires deciding that trust in a package is a composite claim, and that no single cryptographic gate carries the whole weight.

The verdict

Provenance is real work, and it does real work. It closes the "some random person uploaded a tarball" attack. That was a big attack. It did not close the "the build platform is the attack surface" attack, and Miasma is the demonstration in production.

Sign your artifacts. Publish your attestations. Verify them at install. Then assume, on the working days that end in Y, that a valid attestation is what the next incident will be stapled to. Because the alternative is trusting a pipeline that just got popped and never told you.