Security teams should assume install-time code can read any credential present in the build environment. The safest approach is to keep installs away from production secrets, use ephemeral runners, and enforce least privilege on every token. Secret detection matters, but automated revocation and scoped access reduce the real blast radius.
Why This Matters for Security Teams
npm supply chain attacks are dangerous because install-time execution can expose whatever is already present in the build environment. That means the real issue is not only malicious package code, but secret placement, token scope, and whether the runner can reach production-grade credentials at all. NHIMG research on the Shai Hulud npm malware campaign shows how quickly attackers convert package compromise into secret theft and downstream access.
This is why classic “scan for secrets after the fact” thinking is insufficient. The safer model is to reduce what is exposed during install, shorten token lifetime, and constrain every NHI to the smallest usable permission set. The OWASP Non-Human Identity Top 10 reinforces that NHI governance is about limiting blast radius, not just detecting leakage. In practice, many security teams discover secret exposure only after a malicious install has already exfiltrated credentials, rather than through intentional control design.
How It Works in Practice
Reduce risk by treating build and install jobs as untrusted execution zones. Keep them away from production secrets, use ephemeral runners, and inject only the minimum credentials needed for the task. Where possible, issue just-in-time secrets or short-lived tokens that expire as soon as the job completes. That approach aligns with the current guidance in NIST Cybersecurity Framework 2.0, which emphasises controlled access, monitoring, and recovery.
For npm pipelines, the practical controls are straightforward:
- Separate dependency installation from release signing, deployment, and production configuration access.
- Use isolated CI runners with no long-lived cloud credentials mounted by default.
- Bind tokens to a single repository, environment, or workflow step, then revoke them immediately after use.
- Prefer workload identity and brokered access over static secrets stored in environment variables or config files.
- Alert on unusual post-install network calls, credential reads, and token exchange activity.
NHIMG’s LiteLLM PyPI package breach and the Reviewdog GitHub Action supply chain attack both illustrate the same lesson: once a build step can read secrets, package provenance alone is not enough. The best practice is to assume every install can attempt credential access and to engineer the environment so there is little of value to steal. These controls tend to break down when monolithic CI jobs mix dependency installation, signing, and deployment in a single privileged pipeline because one compromise inherits every secret in scope.
Common Variations and Edge Cases
Tighter secret controls often increase pipeline complexity, so organisations have to balance deployment speed against blast-radius reduction. That tradeoff is especially visible in legacy CI systems, multi-tenant runners, and developer environments that still rely on shared service accounts.
Current guidance suggests a few patterns, though there is no universal standard for every stack yet. Some teams move to per-job OIDC federation; others use vaulted secret brokers with short TTLs; still others use ephemeral credentials only for release workflows and remove all secrets from ordinary install jobs. The right answer depends on how much trust the pipeline can actually earn.
Two situations deserve extra caution. First, “secretless” builds are often not truly secretless if the runner can still reach metadata services or cached credentials. Second, automated revocation only helps when the organisation can detect compromise quickly enough to revoke before reuse. NHIMG’s Guide to the Secret Sprawl Challenge is a useful reminder that fragmented secret stores and inconsistent ownership make response slower, not faster. For broader governance context, the 52 NHI Breaches Analysis shows how access paths compound once one identity is overexposed. The practical goal is not perfect prevention but shrinking the number of credentials any npm install can possibly reach.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and SPIFFE/SPIRE set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Secret exposure and over-privileged NHI tokens are core to npm supply chain theft. |
| NIST CSF 2.0 | PR.AC-4 | Least privilege and access restriction directly reduce build-time secret blast radius. |
| SPIFFE/SPIRE | Workload identity is a strong alternative to static secrets in ephemeral runners. |
Use short-lived, least-privilege NHI credentials and remove secrets from install-time execution paths.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on May 16, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
