Why do long-lived npm and GitHub tokens make supply chain worms harder to contain?

Why This Matters for Security Teams

Long-lived npm and GitHub tokens turn a single compromise into repeatable abuse because they are not just secrets, they are standing delegated authority. In supply chain incidents, that means an attacker can publish malicious package versions, alter workflows, or pivot into adjacent repositories long after the initial theft. The risk is amplified when tokens are broad, reused, or stored in CI logs and developer tooling.

This is why NHI governance treats package and repository tokens as high-value operational identities, not disposable credentials. The OWASP Non-Human Identity Top 10 frames overprivileged and poorly rotated machine identities as a root cause of downstream blast radius. NHIMG research on the Shai Hulud npm malware campaign shows how one exposed credential can be reused to spread across ecosystems instead of dying with the first host. The practical failure mode is simple: containment assumptions built for human logins collapse when the token can authenticate unattended, at scale, and without friction. In practice, many security teams encounter the worm only after the token has already been used to distribute additional payloads and seed persistence.

How It Works in Practice

Supply chain worms succeed when the stolen token can do more than authenticate once. A valid npm token can publish new package versions, and a GitHub token can trigger workflows, modify repository content, or create additional credentials if its scopes allow it. If the token remains valid for weeks or months, the attacker does not need to race the defenders. They can retry, automate propagation, and use the normal build and release systems as a delivery channel.

Containment improves when teams treat these tokens as ephemeral workload identities with tight scope, short TTL, and automatic revocation. That approach aligns with the emerging guidance in the Miasma and Hades Supply Chain Worms research, where propagation depended on surviving credentials and broad execution paths. Practically, the control stack should include:

• Short-lived tokens issued per job or release step, not shared across developer devices and CI runners.
• Minimum-scoped permissions for publish, install, workflow write, and package ownership actions.
• Automatic rotation and revocation on completion, compromise signal, or unusual publishing activity.
• Repository and registry policy checks at request time, rather than relying only on pre-approved account roles.
• Separate identities for human developers, CI runners, and release automation so one leak does not authenticate everywhere.

For teams implementing this pattern, the core idea is to shift from “who owns the token” to “what task is this workload allowed to perform right now.” That is the same operational logic described in NHIMG’s The State of Secrets Sprawl 2026, where valid leaked secrets often remain exploitable because revocation lags behind detection. These controls tend to break down in legacy release pipelines that depend on long-lived personal access tokens and manual publishing approvals because the tooling was never designed for per-task identity issuance.

Common Variations and Edge Cases

Tighter token controls often increase delivery friction, so organisations have to balance blast-radius reduction against build and release overhead. That tradeoff is real, especially in ecosystems with older npm publishing practices or GitHub automation that still assumes stable credentials.

Best practice is evolving, and there is no universal standard for every package or repository workflow yet. Some environments can move to OIDC-backed ephemeral credentials quickly, while others need a transition period with scoped classic tokens, stronger monitoring, and rapid revocation playbooks. The highest-risk edge cases are bots that publish across many repositories, third-party GitHub Actions with broad permissions, and cross-tenant automation that reuses the same secret across environments. NHIMG reporting on the Nx Package Attack and the Reviewdog GitHub Action supply chain attack shows how quickly secrets exposure can expand when CI/CD runners and automation accounts are over-trusted.

Where teams need a decision rule, it is this: if a token can publish, mutate workflows, or create more credentials, it should be treated as a worm multiplier, not a convenience credential. Once that mindset is adopted, short TTLs, scoped permissions, and automated revocation become containment controls rather than hygiene tasks.

Related resources from NHI Mgmt Group

• Why do compromised tokens and API keys make npm supply chain attacks harder to contain?
• Why do stolen service credentials make supply chain incidents harder to contain?
• Why do spoofed developer identities make supply chain attacks harder to detect?
• Why do CI/CD workflows make supply chain worms harder to contain?