npm packages often execute automatically when imported, which means a malicious release can run without any lifecycle script or user action. If the package can read environment variables, local config, SSH material, cloud tokens, or AI tool settings, it can exfiltrate secrets from both build systems and developer endpoints before defenders notice.
Why This Matters for Security Teams
Compromised npm packages are dangerous because modern software pipelines trust package code at import time, which turns dependency resolution into an execution channel. A malicious package can inspect environment variables, local caches, CI secrets, cloud tokens, SSH material, and AI tool settings before a reviewer notices anything unusual. That makes the blast radius much larger than a single application bug.
This is not just an application security issue. It is a secrets governance problem that spans developer endpoints, build agents, artifact stores, and cloud control planes. NHIMG’s Guide to the Secret Sprawl Challenge shows how fragmented secret handling creates openings that attackers can exploit once code runs in a trusted context. The same pattern appears in real npm supply chain incidents such as the Shai Hulud npm malware campaign. In practice, many security teams discover package-driven secret theft only after credentials have already been used elsewhere.
How It Works in Practice
The risk comes from three properties working together: automatic execution, broad filesystem and process access, and the high value of secrets sitting in developer and CI environments. When a package is imported, its code can run before the application fully starts. If that code can read process.env, local dotfiles, cloud config, or tool-specific credential stores, it can collect secrets and exfiltrate them in seconds.
Security teams should treat package installation and runtime import as separate trust events. Current guidance suggests reducing exposure through least privilege, secret minimisation, and strong egress controls, but there is no universal standard for all pipelines yet. Practical defences usually combine:
- short-lived credentials instead of long-lived static tokens;
- separate identities for developers, build jobs, and deployment automation;
- secret scanning on source, logs, and artifacts;
- egress filtering and proxying from CI runners;
- policy checks on dependency provenance and package integrity.
For identity and access governance, the issue maps directly to NHI controls. The 52 NHI Breaches Analysis highlights how attackers repeatedly abuse non-human credentials once they are exposed, while the OWASP Non-Human Identity Top 10 frames secret handling, rotation, and overprivilege as recurring failure modes. NIST also stresses control of software supply chain risk in the NIST Cybersecurity Framework 2.0. These controls tend to break down when CI runners inherit broad cloud permissions and reuse the same tokens across many jobs, because a single malicious dependency can pivot from code execution to infrastructure access.
Common Variations and Edge Cases
Tighter dependency controls often increase build friction, requiring organisations to balance delivery speed against the risk of package compromise. The tradeoff becomes sharper in monorepos, ephemeral runners, and AI-assisted development environments, where more tools and more automation mean more places for secrets to leak. NHIMG’s CI/CD pipeline exploitation case study shows how small trust gaps in build orchestration can become full credential exposure events.
Two edge cases deserve special attention. First, packages that do not appear malicious at install time may still become dangerous after a maintainer compromise or dependency update, so provenance checks need to continue after initial approval. Second, AI development stacks often place API keys, model endpoints, and orchestration tokens in the same environment as code execution, which makes a compromised package able to steal both cloud and AI control-plane access. The Anthropic report on an AI-orchestrated cyber espionage campaign reinforces how automation amplifies credential theft once an attacker gets a foothold. Best practice is evolving, but the direction is clear: reduce standing secrets, isolate build identities, and assume imported code may act immediately on whatever it can 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, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Addresses secret rotation and exposure after package compromise. |
| OWASP Agentic AI Top 10 | A-06 | Package attacks can execute tooling paths like autonomous software agents. |
| CSA MAESTRO | TR-2 | Covers trust and runtime control for autonomous or automated software actions. |
| NIST CSF 2.0 | PR.AC-1 | Least privilege is central when dependencies can run with pipeline access. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero trust network limits contain exfiltration from compromised build environments. |
Replace long-lived pipeline secrets with short-lived NHI credentials and rotate any exposed secrets immediately.
Related resources from NHI Mgmt Group
- Why do compromised IDE extensions create such broad identity and secrets risk in cloud-native environments?
- Why do exposed software supply chain packages create such a high-risk path to cloud and CI/CD compromise?
- Why do compromised open source packages create such high risk for secrets and access control?
- Why do supply chain attacks against npm packages create such high operational risk for cloud and GitHub credentials?
