npm removes default script execution: supply chain risk shifts left

At a glance

What this is: npm is disabling automatic execution of dependency lifecycle scripts, reducing a common supply chain abuse path where compromised packages could run code at install time.

Why it matters: This matters because package installation often happens in developer workstations and CI pipelines that contain secrets, so identity, credential, and build trust boundaries all need tighter control.

By the numbers:

• axios is used in roughly 80% of cloud and code environments with approximately 83 million weekly downloads.
• the first compromise hit an endpoint 89 seconds after publication
• around 2.2% of npm packages actually use install scripts

👉 Read Semgrep's analysis of npm's default script execution change

Context

npm lifecycle scripts created a default trust model that let third-party code execute during install, often before teams had any opportunity to inspect what had been pulled into a dependency tree. That is a classic supply chain governance problem, not just a package manager quirk, because it turns installation into code execution and expands the attack surface into developer laptops and CI pipelines. The issue becomes sharper where those environments hold cloud credentials, deployment tokens, and other secrets.

For identity and access practitioners, the article sits at the intersection of software supply chain control and secret exposure. A package install that can run arbitrary shell commands behaves like a delegated identity action with broad local privilege, which is why script execution policy, dependency review, and secrets hygiene need to be treated as one control plane rather than separate concerns.

Key questions

Q: What breaks when dependency install scripts are disabled by default?

A: Packages that rely on install-time compilation or setup, such as native addons or binary downloaders, may need explicit approval or alternate build paths. What breaks most often is convenience, not function. Teams that depended on silent execution must now decide which packages truly need code execution and which should use prebuilt artefacts or safer runtime setup.

Q: Why do install scripts create such a large supply chain risk?

A: They turn package installation into code execution, often inside environments that contain secrets and elevated build privileges. A compromised dependency does not need to alter application logic to cause damage. It only needs one automatic execution opportunity to steal credentials, stage malware, or spread through transitive packages.

Q: What do security teams get wrong about dependency scanning?

A: They often assume a clean manifest means a clean environment. In reality, package managers can resolve transitive code dynamically and execute scripts during installation. A scan can confirm what should have been installed, but it cannot prove what actually ran or what secrets the code reached.

Q: How should organisations respond when package installs can access secrets?

A: They should treat package installation as a privileged workflow and remove secrets that are not required for build or install. Use short-lived credentials, tighter environment segmentation, and script allowlists so install-time code cannot read more than it needs. That reduces the blast radius if a dependency is compromised.

Technical breakdown

Why lifecycle scripts became a supply chain execution channel

npm lifecycle scripts such as preinstall, install, and postinstall execute shell commands during package installation. That means code from a package, including transitive dependencies, can run with the privileges of the user or CI job performing the install. The security problem is not that scripts exist, but that they were trusted by default and inherited through the tree, which let malicious packages piggyback on a legitimate software distribution path.

Practical implication: review dependency script execution as an allowlist problem, not a malware detection problem.

How transitive dependencies widen blast radius

Most developers choose a top-level package, not the hundreds of packages nested underneath it. Once install-time execution is automatic, a compromised maintainer account, a backdoored release, or a malicious nested dependency can trigger code without ever touching the application’s own source files. That is why supply chain attacks often hide inside package metadata and lifecycle hooks rather than obvious application code.

Practical implication: treat transitive dependency trust as a separate control domain from source code review.

Why install-time controls matter for secrets and NHI exposure

Package installs often run in environments containing secrets such as cloud keys, deploy tokens, signing material, and service account credentials. If lifecycle scripts can read those values, attackers do not need persistence in the application itself to cause harm. They only need one execution window during install to harvest credentials, pivot into other systems, or plant follow-on payloads.

Practical implication: reduce the secret footprint of build and install environments before tightening dependency execution policy.

Threat narrative

Attacker objective: The attacker wants to execute code inside trusted build and developer environments so they can steal secrets, persist through follow-on packages, and move laterally through the software supply chain.

1. Entry occurred when attackers compromised a maintainer account or slipped a backdoored dependency into the package ecosystem, then published a malicious release that downstream installs fetched automatically.
2. Credential access followed when the postinstall payload executed during npm install and searched the environment for cloud credentials, deployment tokens, and other secrets exposed in developer or CI contexts.
3. Impact arrived when the payload exfiltrated credentials, installed additional malware, or enabled worm-like propagation through other packages in the dependency tree.

NHI Mgmt Group analysis

Default script execution was the real governance failure, not just malicious packages. npm’s previous model assumed that third-party install scripts could be trusted unless proven otherwise. That assumption collapsed because package managers distribute code across highly privileged environments that often contain secrets. The control failure is the default, not the exception, and that is why blocking automatic execution changes the governance baseline for the entire ecosystem.

Install-time trust is a delegated identity problem. A package that executes during install acts like a temporary software identity with access to the host environment. That makes lifecycle scripts an identity boundary, not just a build convenience. Where the install process can read credentials, tokens, or certificates, the security model needs explicit authorisation and bounded privilege, not inherited trust.

Secret exposure and dependency execution form a single attack surface. The article shows why build systems and developer machines must be treated as credential-rich execution zones. If package managers can run code automatically, then secret management, software supply chain policy, and endpoint hardening cannot be separated into different conversations. Practitioners should treat install policy as part of secrets governance, not as a narrow developer experience issue.

Transitive trust sprawl is the named concept this change exposes. Most teams audit direct dependencies but do not have meaningful visibility into everything that can execute underneath them. That gap creates a trust sprawl problem where control is inherited from packages that teams never intended to trust. The practical conclusion is that review, allowlisting, and runtime boundaries must extend to the full dependency tree, not just the top-level package.

What this signals

Install-time execution needs to be treated as a policy boundary, not a convenience feature. Teams that rely on package managers inside CI should assume that dependency metadata can act like code and that code can reach secrets if the environment is not segmented. The practical shift is to build explicit approval paths for dependency scripts and to keep build identities narrowly scoped. For control mapping, the NIST Cybersecurity Framework 2.0 and NIST SP 800-53 Rev 5 Security and Privacy Controls both support this kind of restricted execution model.

Secrets sprawl in developer tooling is what turns supply chain compromise into identity compromise. When installers run inside environments with cloud tokens, deploy keys, or service account credentials, the problem is no longer limited to malware delivery. It becomes a credential governance issue, where short-lived access and better secret placement matter as much as package vetting. That is the same structural lesson visible in our 52 NHI Breaches Analysis: exposure windows are what attackers exploit, not abstract trust claims.

Transitive dependency control is the named risk teams should now operationalise. The dependency tree can conceal execution paths that ordinary code review will never see, which means secure software delivery needs allowlists, build isolation, and continuous inventory of packages that can execute. For practitioners looking for a governance lens, the OWASP Non-Human Identity Top 10 is a useful way to connect secret handling, workload identity, and software supply chain controls.

For practitioners

• Block automatic dependency script execution Default to disallowing preinstall, install, and postinstall scripts in dependency installs, then allow only the packages that have a documented operational need for build-time code execution. This is especially important in CI jobs and developer environments that handle cloud credentials or deployment secrets.
• Separate install environments from secret-bearing environments Reduce the number of secrets present during package installation by using short-lived credentials, isolated build identities, and environment-specific token scoping. If a package does not need access to production secrets, do not place those secrets in reach during npm install.
• Inventory transitive packages that request scripts Review dependency trees for packages that use lifecycle hooks, especially transitive dependencies that were never explicitly approved. Build an allowlist workflow for install-time execution so engineering teams can make explicit decisions instead of inheriting hidden trust.
• Harden CI and developer endpoints against install-time abuse Treat package installation as an untrusted execution point in endpoint and build hardening baselines. Restrict filesystem access, limit outbound network paths, and monitor for unexpected process spawning from package managers inside build jobs.

Key takeaways

• npm’s change matters because automatic dependency execution was a supply chain trust shortcut that attackers repeatedly abused.
• The real risk is not only malicious code in packages, but code execution inside environments that already contain secrets and elevated build access.
• Teams should respond by separating install-time trust from runtime trust, tightening secrets exposure, and explicitly allowlisting the few packages that truly need scripts.

Key terms

• Lifecycle Script: A lifecycle script is a command that runs automatically at a defined point in a package installation or publish process. In package ecosystems, these scripts can become a code execution path if they are trusted by default, especially when they inherit the privileges of the user or CI job running the install.
• Transitive Dependency: A transitive dependency is a package that your project uses indirectly because one of your direct dependencies depends on it. These nested packages are often the hardest to govern because teams do not choose them explicitly, yet they can still introduce code, scripts, and trust relationships into the build chain.
• Install-Time Execution: Install-time execution is code that runs while dependencies are being installed rather than when an application is launched. In supply chain attacks, this matters because the install phase often has access to the richest secrets in developer and CI environments, making it a high-value privilege boundary.
• Secret exposure window: A secret exposure window is the period between when a credential becomes visible to an attacker and when it is detected, revoked, or rotated. In CI/CD environments that window can be extremely short, which is why detection speed and identity-linked revocation matter as much as storage hygiene.

What's in the full article

Semgrep's full article covers the operational detail this post intentionally leaves for the source:

• A closer walkthrough of npm v12 defaults and which script paths are blocked by allowScripts, allow-git, and allow-remote.
• Examples of legitimate lifecycle-script use cases such as native addons and binary downloads, useful when deciding what to allowlist.
• The attack patterns behind Axios, Shai-Hulud, and similar package compromise campaigns that used install-time execution.
• Practical comparison points across npm, pnpm, Bun, and Yarn for teams standardising package policy.

👉 Semgrep's full post covers the attack patterns, package-manager defaults, and edge cases that implementation teams need to evaluate.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management for practitioners who need to tighten access boundaries. It is designed for teams building repeatable identity controls across development, cloud, and security programmes.