Analysis
VentureBeat reported that the Shai-Hulud npm worm did not counterfeit the supply-chain provenance signals defenders rely on. It obtained genuine ones, because the malicious publish executed inside a legitimate maintainer's CI pipeline using that maintainer's real credentials.
This inverts the defensive model most engineering organizations adopted after the 2021-2024 wave of npm attacks. Sigstore-backed provenance attestations, SLSA levels and signed builds all answer one question: did this artifact come from the repository and pipeline it claims to come from? Shai-Hulud's answer is yes. The attestation is accurate. The build was authentic. The code inside it was hostile.
“This inverts the defensive model most engineering organizations adopted after the 2021-2024 wave of npm attacks.”
The attack path is the one every organization with automated publishing shares. A maintainer token is stolen, the attacker pushes a commit, CI builds and signs and publishes it, and the resulting package arrives in downstream installs carrying a valid chain of custody. Provenance proves origin; it was never designed to prove intent, and treating a green attestation as a safety verdict is the mistake being exposed here.
Practical consequences for engineering teams: attestation checks belong in the pipeline but cannot be the last gate. Pinned versions with integrity hashes, delayed adoption windows for new releases of critical dependencies, and CI credentials scoped so a publish token cannot also reach production secrets all matter more than the badge. GitHub, npm and the OpenSSF have all pushed provenance as the answer for three years; this is the case that shows what it does not cover.
What to watch: whether npm introduces publish-time behavioral analysis rather than origin verification alone, and whether the major package registries adopt mandatory two-person review for releases of high-download packages. Until then, an authentic signature on a hostile package is a repeatable attack, not a one-off.