How should security teams handle npm packages that run code during install?

Why This Matters for Security Teams

Install-time scripts turn package retrieval into code execution, which means dependency management is also an attack surface for secrets, tokens, and CI credentials. That is especially dangerous in modern delivery pipelines where a single compromise can fan out across repositories and build systems. NHI guidance treats this as a workload identity problem as much as a software supply chain problem: if a package can execute during install, it can often reach the same secrets and service accounts that build jobs use. NHIMG research on the Shai Hulud npm malware campaign shows how quickly malicious package behavior can pivot into secret theft, and the NIST Cybersecurity Framework 2.0 still maps this to core supply-chain and access-control discipline. The practical mistake is assuming package install is a passive event when it is often an execution event with the privileges of the runner.

Teams also underestimate the blast radius because install hooks frequently run before security scanners, policy checks, or test gates have a chance to inspect the package. In practice, many security teams encounter credential exposure only after a poisoned dependency has already touched CI secrets, rather than through intentional review of install-time behavior.

How It Works in Practice

The safest operating model is to treat lifecycle scripts, postinstall hooks, and transitive package execution as privileged actions that must be explicitly approved. That usually starts with allowlisting trusted packages, blocking scripts by default for untrusted sources, and using isolated sandboxes for first-run testing. For high-value pipelines, build runners should receive only short-lived credentials and scoped access, so a malicious install script cannot reuse standing secrets. This is where NHI controls matter: packages should never be able to reach long-lived API keys simply because they are installed in a build job.

Security teams should also separate verification from execution. Dependency updates can be fetched, scanned, and diffed in a restricted environment before any install hook is permitted to run in CI. Where tooling supports it, use policy enforcement to deny script execution unless a package is approved by source, checksum, or provenance. The LiteLLM PyPI package breach is a useful reminder that package trust decisions can fail even when code looks legitimate at first glance. Current guidance suggests pairing this with NIST Cybersecurity Framework 2.0 governance, especially around protect, detect, and respond.

• Block install scripts by default, then allowlist only the packages that truly require them.
• Run dependency installs in isolated builders with ephemeral credentials and no standing secret access.
• Review package provenance, lockfiles, and diff output before scripts are allowed in CI.
• Log script execution separately so investigators can distinguish benign installs from malicious behavior.

These controls tend to break down when build systems share cached credentials across jobs, because one malicious install can then inherit a broad, persistent trust context.

Common Variations and Edge Cases

Tighter script blocking often increases build friction, requiring organisations to balance supply-chain safety against package ecosystem compatibility. Some packages genuinely need install-time logic for native compilation, platform detection, or artifact generation, and there is no universal standard for perfect script suppression yet. The best practice is evolving toward context-aware exceptions rather than blanket trust.

In regulated or legacy environments, teams may need a phased approach: start by blocking scripts for external packages, then create separate pipelines for packages that are known to require execution. For monorepos and developer laptops, the risk is often higher because local installs may have broader access to browser sessions, SSH agents, or cloud credentials than CI does. That makes Shai Hulud npm malware campaign especially relevant as a pattern for secret harvesting, while the NIST framework remains useful for deciding who approves exceptions and how they are monitored.

Where package managers cannot reliably disable all execution paths, teams should compensate with ephemeral tokens, restricted network egress, and separate accounts for dependency resolution versus build execution. The guidance becomes less effective in highly dynamic developer environments because local tooling, cached credentials, and ad hoc scripting can bypass central policy faster than controls can detect it.

Related resources from NHI Mgmt Group

• How should security teams run access reviews for non-human identities?
• How should security teams handle risks from AI browser extensions?
• How should security teams handle cloud secrets that are shared across applications and pipelines?
• How should security teams handle trusted integrations that can access production systems?