npm token hardening shows why standing secrets fail in CI pipelines

At a glance

What this is: Akeyless argues that npm token hardening is really a rejection of standing secrets, after a single compromised token enabled a rapid supply chain attack across hundreds of packages.

Why it matters: This matters because CI pipelines often mix publishing credentials with broader machine identities, and IAM teams need controls that remove durable secrets rather than just rotate them faster.

👉 Read Akeyless's analysis of npm token hardening and CI standing secrets

Context

The core issue is simple: CI pipelines still depend on credentials that outlive the job they were meant to serve. When a token remains valid after the workflow ends, attackers can steal it, reuse it, and pivot from publishing access into broader environment access.

In npm’s case, the governance gap is not package publishing alone but the persistence of standing secrets inside build infrastructure. Once a maintainer token can be reused outside the original workflow, the boundary between build-time access and administrative privilege collapses.

GitHub’s move toward live 2FA for account and package management, followed by OIDC trusted publishing for direct releases, reflects a wider shift in machine identity governance. The question for practitioners is no longer how to protect long-lived tokens better, but where they should exist at all.

Key questions

Q: What breaks when CI pipelines still rely on standing npm tokens?

A: Standing npm tokens turn a release workflow into a reusable identity artifact. If the token is stolen, the attacker can reuse it outside the intended run, publish malicious packages, and often pivot into adjacent secrets on the same runner. The break is not only authentication. It is the collapse of containment around machine identity.

Q: Why do long-lived authentication tokens create more risk in CI/CD systems than short-lived credentials?

A: Long-lived tokens expand the window in which an exposed credential can be reused, especially when build and deployment systems have broad permissions. If a token never expires, an attacker can wait, blend into normal activity, and reuse it later without needing to defeat rotation. Short-lived credentials reduce that exposure by limiting both lifetime and replay opportunities.

Q: What are the signs that a release pipeline is over-reliant on machine identity secrets?

A: Common warning signs include tokens stored in CI variables, publish access shared across multiple jobs, and runners that can reach unrelated cloud or vault secrets. If a single build host can expose both publishing and administrative credentials, the pipeline has already turned identity sprawl into blast-radius risk.

Q: Should teams prioritize OIDC trusted publishing over token rotation for npm releases?

A: Yes, when the registry and CI platform support it, because rotation still leaves a reusable secret in place between cycles. OIDC trusted publishing removes the standing credential entirely, which is a stronger control than trying to manage the lifetime of a token that should not exist in the first place.

Technical breakdown

Why standing npm tokens fail in CI pipelines

A standing token is a reusable authenticator that remains valid until revoked or expired. In CI, that means the credential can be copied from logs, environment variables, build artifacts, caches, or a compromised runner after the job completes. The problem is structural: the token proves identity later, when the workflow that justified it is already over. That turns a publish credential into a persistent attack surface, especially when the same runner also holds cloud keys, signing material, or registry access. The right technical framing is not token strength but credential lifetime and reuse scope.

Practical implication: Treat any reusable CI token as a standing identity asset with an exposure window, not as a one-time build artifact.

How OIDC trusted publishing changes the trust model

OIDC trusted publishing replaces a stored secret with a signed assertion from the CI provider about a specific workflow run. The registry exchanges that assertion for a short-lived publish credential tied to that single execution context, then discards it when the run ends. That means there is no durable token sitting in a secret store for an attacker to exfiltrate later. The trust anchor shifts from possession of a secret to proof that a sanctioned workflow is currently running, which is a much narrower and more governable condition.

Practical implication: Move release workflows toward ephemeral, workload-bound credentials so publish access cannot be reused outside the job that earned it.

Why co-located secrets turn one token into a wider breach

Mini Shai-Hulud showed the real hazard of CI compromise: the first credential is often only the entry point. Once a runner is trusted with npm access, it may also expose GitHub tokens, cloud keys, SSH material, Kubernetes service accounts, or vault-backed secrets in the same execution environment. That creates a blast-radius problem, not a single-token problem. The attack succeeds when unrelated credentials share one runtime boundary and are retrievable after the initial compromise, which is why secret segregation matters as much as token removal.

Practical implication: Separate publishing credentials from cloud and admin credentials so a single CI compromise cannot cascade across the pipeline.

Threat narrative

Attacker objective: The objective was to turn one trusted publishing credential into broad supply chain control and secondary credential theft across the build environment.

1. Entry occurred through a compromised npm token that gave the attacker valid publishing access inside the maintainer workflow.
2. Credential harvesting expanded when the compromised runner exposed additional secrets alongside the npm token, including cloud keys and other privileged material.
3. Escalation followed as the attacker used the trusted credential to publish malicious package versions at scale and extend access across the supply chain.
4. Impact was a rapid software supply chain blast radius, with malicious packages distributed before defenders could meaningfully intervene.

Breaches seen in the wild

• Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Standing CI secrets are now a governance failure, not a convenience choice. A reusable npm token creates a control problem because its authority outlives the workflow that needed it. That breaks the basic assumption that build credentials can be reviewed, rotated, and contained after the fact. Practitioners should treat token persistence as a design defect in machine identity governance.

Secretless publishing is the correct endpoint for package release identity. OIDC trusted publishing changes the unit of trust from a stored credential to a live workflow assertion, which is exactly where release authorization belongs. This is not just a better authentication pattern. It is a change in where authority resides, from durable secrets to ephemeral execution context, and teams should align release governance to that model.

Credential lifetime, not credential complexity, is the decisive control variable. The article makes clear that harder-to-steal tokens still fail if they exist long enough to be copied or replayed. That is why Zero Standing Privileges is the more durable governance principle for CI and build systems. Teams should measure how much authority persists after a job ends, not how many layers sit around the secret.

Mini Shai-Hulud exposes the identity blast radius hidden inside build runners. The npm token was only the first credential. The real damage came from adjacent secrets sharing the same runtime boundary, which turned package publishing into a gateway for cloud, vault, and SSH exposure. Practitioners need to govern runners as identity aggregation points, not just as execution hosts.

Access review assumptions do not hold for ephemeral machine identity. Access review processes were designed for access that lasts long enough to be observed, certified, and recertified. OIDC-scoped credentials can exist only for one workflow run, so the review model shifts from post-use inspection to issuance-time policy. The implication is that governance must move upstream of execution, or it will miss the identity entirely.

What this signals

Standing secrets in CI create identity blast radius. The important governance question is no longer how to rotate tokens faster, but which workflows still depend on credentials that remain valid after the job ends. When a runner can access publishing, cloud, and vault secrets at the same time, the pipeline has become an identity concentration point that magnifies every compromise.

Ephemeral release identity is the more defensible model for package ecosystems. OIDC-backed publishing shifts authority into the workflow context and removes the reusable token from the attacker’s target set. For practitioners, that means release governance should be evaluated alongside runner isolation, secret segregation, and post-job credential invalidation, not as a separate package-management concern.

For practitioners

• Replace standing publish tokens with OIDC release identity Use OIDC trusted publishing for package release workflows wherever the registry and CI platform support it, so the credential exists only for the duration of a single run. Do not preserve bypass tokens as a default release path once an ephemeral alternative is available.
• Quarantine remaining npm tokens in the transition window Store any bypass-2FA npm tokens outside CI variables, restrict their use to the smallest possible egress path, and log every read and reissue event. Treat them as temporary privileged assets until direct publishing is fully retired.
• Separate release credentials from adjacent secrets Keep cloud keys, signing certificates, database passwords, and registry tokens in different trust boundaries so a compromised runner cannot harvest them together. The goal is to prevent one publish credential from opening access to unrelated machine identities.
• Review runner exposure as an identity problem Map which credentials a CI runner can access before, during, and after a job, then remove anything that remains valid after the workflow ends. The runner should not become a general-purpose vault for standing secrets.

Key takeaways

• The article shows that npm hardening is really about removing standing credentials from CI, not just making them harder to steal.
• The Mini Shai-Hulud campaign illustrates how one compromised token can become a supply chain multiplier when other secrets share the same runner.
• Practitioners should shift release governance toward ephemeral workflow identity and away from reusable publish tokens.

Key terms

• Standing Secret: A standing secret is a long-lived credential that remains valid until it is manually replaced or revoked. In practice, it expands attack exposure because the secret can outlive the service change process, especially when ownership and usage tracking are incomplete.
• OIDC Trusted Publishing: OIDC trusted publishing uses a short-lived federated assertion from the CI system to prove a workflow is current and authorised. The registry exchanges that proof for ephemeral publish access, which removes the need to store a durable package token.
• Zero Standing Privileges (ZSP): A security posture where no identity, human or non-human, holds persistent access rights. Access is provisioned dynamically on demand and automatically revoked after use. ZSP is the gold standard for NHI access control.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

What's in the full article

Akeyless's full analysis covers the operational detail this post intentionally leaves for the source:

• How the transition from bypass-2FA npm tokens to OIDC trusted publishing affects release workflows and self-hosted runners
• How Akeyless positions secret storage, controlled reissue, and audit logging during the January 2027 transition window
• How the same secretless model is applied to cloud keys, signing material, and other machine identities in CI
• How privileged npm administration shifts into a PAM-style human access pattern under the new model

👉 Akeyless's full post covers the Mini Shai-Hulud attack chain, transition window controls, and secretless release patterns.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.