The recent npm supply chain compromises — AsyncAPI, and the TanStack-adjacent Mini Shai-Hulud campaign — share a mechanism that's easy to miss if you're watching for the wrong thing. A cryptographic primitive was not cracked. A registry's core infrastructure was not directly breached. Attackers went after a soft target: the build systems and CI/CD pipelines that hold the keys to publishing.
That matters more. Package registries were built on a simple trust model — anyone holding a valid token could publish. The system had no mechanism to ask a simple question: did this artefact actually come from the workflow it claims to have come from? Once attackers realised the registry itself didn't need to be touched, the pipeline became the target.
Look closely at how these compromises actually unfolded and three separate control failures stack on top of each other. Pipelines were routinely provisioned with account-wide or organisation-wide publishing rights, rather than access scoped to "publish version X of package Y". Compromising a single workflow gave attackers release capability across entire organisations, not just one package. On top of that, static secrets sat inside CI/CD configuration indefinitely, with no enforced rotation. A credential leaked through runner memory, a malicious pull request, or an exfiltrated environment variable stayed valid for future misuse long after the initial exposure. And finally, registries accepted releases on bearer-token possession alone. There was no way to distinguish a legitimate automated release from a malicious push originating from an unauthorised environment using a stolen token.
None of these failures is unexpected. They're the kind of thing that accumulates quietly in any CI/CD setup that's grown organically over years, without anyone asking "is this fine?"
The mitigations that matter here aren't vulnerability patches — they remove the things attackers were relying on in the first place. OIDC trusted publishing is the primary fix for the pipeline side. Instead of a static secret sitting in a secrets manager, the CI environment requests a short-lived credential dynamically, per workflow run, via OpenID Connect. There's nothing persistent to exfiltrate, because nothing persistent exists. The token is only minted if the request comes from a cryptographically verified workflow run — matching the exact repository, branch, and commit.
MFA-gated publishing handles the human side, enforcing a multi-factor prompt whenever a maintainer triggers a publish from a local terminal or developer machine. And SLSA (Supply-chain Levels for Software Artifacts) provenance attestation binds the compiled artefact cryptographically to its source commit, repository, and workflow run. This is the piece that lets downstream consumers verify the chain of custody themselves, rather than trusting the registry's word for it.
It's tempting to reach for IP-allowlisting as a simpler fix, and it's worth being clear about why that doesn't hold up here. IP-allowlisting defends against external use of a stolen token — someone outside the network trying to use credentials that leaked. It assumes the threat originates outside the perimeter. But once an attacker has code execution on a CI runner, they're already inside that perimeter. Network origin becomes irrelevant. OIDC's strict context binding limits what the runner can do regardless of where the request originates — which is precisely why identity-bound, ephemeral credentials are the stronger control, not a network boundary.