Why do stolen publishing credentials make supply chain attacks worse?

Why Stolen Publishing Credentials Turn a Compromise into Propagation

Publishing access is different from ordinary user access because it can change what downstream teams install, trust, and execute. Once a package maintainer token, npm publish key, or release pipeline credential is stolen, an attacker no longer needs repeated intrusion to cause harm. They can seed malicious versions, preserve access long enough to reissue poisoned releases, and blend into legitimate update traffic. That is why the problem maps directly to OWASP Non-Human Identity Top 10 concerns around over-privileged secrets and to the patterns documented in Shai Hulud npm malware campaign reporting.

For security teams, the risk is not only credential theft but the attacker’s ability to use that credential as an amplification channel across the software supply chain. In practice, many security teams encounter the blast radius only after a malicious release has already propagated through internal mirrors, automated build systems, and developer workstations, rather than through intentional review.

How It Works in Practice

Publishing credentials are high-leverage because they sit at the point where code becomes distribution. The attacker’s sequence is usually straightforward: steal the token, authenticate as the maintainer or automation account, publish a new package version, and let dependency update mechanisms do the rest. A short-lived compromise can become a long-lived supply chain event if the credential is not revoked quickly and if release pipelines do not enforce strong verification on every publish.

This is why current guidance increasingly treats publishing authority as a workload identity problem, not just a secrets-management problem. The right control plane is usually a combination of:

• short-lived, task-bound secrets instead of reusable static tokens
• strong separation between build, test, and publish identities
• human approval or policy checks for release promotion
• tamper-evident provenance and package signing
• rapid revocation and rotation when publishing credentials are exposed

NHIMG research on Guide to the Secret Sprawl Challenge and the LiteLLM PyPI package breach shows the practical problem: once secrets are scattered across build logs, developer machines, and CI variables, revocation is slower than attacker reuse. That pattern is echoed by vendor research noting that exposed AWS credentials are often attacked within minutes, as covered in LLMjacking: How Attackers Hijack AI Using Compromised NHIs. When publishing rights are coupled to a single static token, attackers can bypass normal change control and create a versioned, trusted artifact before defenders notice.

These controls tend to break down in highly automated release environments where a single credential is reused across multiple packages, environments, and CI runners because revocation becomes disruptive and the organisation delays action.

Where the Standard Answer Breaks Down

Tighter publishing control often increases release friction, requiring organisations to balance delivery speed against the cost of stronger verification. That tradeoff is real, especially for open-source maintainers, small platform teams, and monorepos that publish many artifacts per day. There is no universal standard for every ecosystem yet, but best practice is evolving toward least-privilege publishing identities, separate signing keys, and per-release approvals for high-impact packages.

Edge cases matter. Some ecosystems still depend on long-lived tokens for legacy tooling, and some internal package registries do not yet support granular publisher roles. In those environments, compensating controls become more important: lock down token storage, scope access to a single package or namespace, monitor for anomalous publish times, and alert on new maintainer additions. The 52 NHI Breaches Analysis and the OWASP NHI Top 10 both point to the same operational lesson: once identity is reused as a release mechanism, compromise scales faster than manual response. The practical answer is to make publishing credentials disposable, narrowly scoped, and easy to revoke before they become a propagation path.

Related resources from NHI Mgmt Group

• How do attackers turn a supply-chain incident into wider NHI compromise?
• Why do non-human identities make supply chain attacks harder to contain?
• Why do NHI credentials increase blast radius in supply-chain attacks?
• What are the risks of using static credentials in MCP servers?