TL;DR: npm is changing default behaviour so dependency install scripts no longer run automatically, closing a long-used supply chain attack path that let compromised packages execute code during install, according to Semgrep. The real lesson is that trusted package execution should be explicit, not inherited from the dependency tree.
At a glance
What this is: npm is changing default package-install behaviour so dependency scripts no longer execute automatically, reducing one common route for supply chain compromise.
Why it matters: This matters because build and install-time code runs with developer or CI privileges, so any auto-executed dependency script can become a credential theft or malware delivery path.
Context
Package managers are not just download tools, because they can also execute code during installation. In this case, the security problem is trust: third-party package behaviour was being granted runtime authority before teams had a meaningful review step, which turns dependency installation into an execution event rather than a simple fetch operation.
That matters most in CI/CD and developer environments, where install-time scripts can reach cloud credentials, deployment tokens, and other secrets. For IAM and NHI programmes, the issue is not only malicious packages but also uncontrolled execution paths that let transitive dependencies act with the privileges of the machine or pipeline running the install.
The change is therefore less about npm alone than about a broader governance shift in software supply chain security. The typical environment has relied on convenience defaults that assumed package maintainers were trustworthy enough to run code automatically, and this article shows that assumption is no longer defensible.
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 make package supply-chain attacks more dangerous?
A: Install scripts run automatically, so they bypass the assumption that code must be imported or called before it can do harm. In practice, that gives attackers an execution path inside build systems, containers, and serverless layers, where they can read environment variables, contact runtime APIs, or stage follow-on exfiltration.
Q: What are the signs that dependency script controls are too permissive?
A: Warning signs include packages with unexpected postinstall hooks, CI jobs that require broad environment secrets during installs, and dependency trees that change behaviour without an approval step. If teams cannot explain which packages are allowed to run scripts and why, the control boundary is too open.
Q: Should teams prefer default-deny package execution or per-package allowlists?
A: Default-deny with per-package allowlists is the safer model because it forces each script to justify its existence. That approach preserves legitimate cases such as native builds or binary downloads, while preventing the automatic execution of arbitrary code from the wider dependency tree.
Technical breakdown
Why install-time scripts are a supply chain execution problem
Lifecycle scripts such as preinstall, install, postinstall, and prepare run shell commands while packages are being installed. That means the package manager is not just resolving dependencies, it is executing third-party code with the privileges of the process that launched the install. In practice, that can be a laptop, a build runner, or a deployment pipeline. The risk is amplified by transitive dependencies, because teams may never have selected or reviewed the package that actually contains the script. A compromise in any upstream package can therefore become code execution at install time.
Practical implication: Treat install hooks as execution surfaces, not harmless metadata, and review them before they are allowed in any build path.
Why transitive dependencies become the real trust boundary
The article’s key point is that the dangerous code often lives outside the package a team believes it installed. npm historically ran scripts from packages several layers deep in the tree, which means trust was inherited across the dependency graph without explicit approval. That model breaks the normal security expectation that only directly selected software should receive execution rights. Once a transitive package can run a script automatically, maintainers, provenance, and release controls all matter more than the visible top-level dependency list.
Practical implication: Map execution privilege to the full dependency tree, not just direct dependencies, and block unknown transitive script runners by default.
How default-deny aligns with software supply chain governance
The shift to blocking dependency scripts, remote URLs, and some git-based paths by default moves npm closer to a default-deny model for package execution. That does not eliminate malicious packages, typosquatting, dependency confusion, or runtime malware, but it removes one of the easiest ways attackers convert a package compromise into immediate code execution. For security teams, the control question changes from how to detect every malicious install script to which packages genuinely require script execution and under what approval process.
Practical implication: Use allowlisting for the small set of packages that truly need scripts and keep every other dependency on a no-execution baseline.
Threat narrative
Attacker objective: The attacker’s objective is to turn a trusted dependency install into credential theft, malware delivery, or downstream supply chain compromise.
- Entry occurs when an attacker compromises or publishes a malicious package into the dependency tree, often by hijacking a maintainer account or abusing a trusted release path.
- Credential access follows when the package’s install script runs in a developer workstation or CI/CD runner and harvests secrets, tokens, or environment variables.
- Impact arrives when the payload exfiltrates data, installs malware, or uses stolen credentials to move through the broader software supply chain.
Breaches seen in the wild
- LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.
- Miasma and Hades Supply Chain Worms: Self-propagating supply chain worms Miasma and Hades compromise npm, PyPI, and Azure credential stores.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Default script execution is the real governance failure, not just a package-manager quirk. npm’s old model treated install-time code as routine dependency behaviour, but that turned every transitive package into a potential execution principal. For identity and access governance, the lesson is that privilege assignment during software installation needs the same scrutiny as any other delegated access path. Practitioners should classify package execution as an access decision, not a convenience setting.
Transitive dependency trust is a hidden privilege chain. The article shows that the package teams think they installed is often not the component that actually runs code. That creates an identity-like problem for software supply chains: execution authority is inherited through layers of dependency relationships that most teams do not actively govern. The result is a control blind spot that conventional code review and dependency inventory tools do not fully close.
Shift-left only works when the default is no-execution. If a package manager automatically runs third-party scripts, security review happens after authority has already been granted. The new default-deny behaviour aligns better with least privilege, because packages must now justify why they need install-time execution at all. That is the right direction for supply chain governance, especially in CI/CD environments where privileged credentials are commonly present.
Supply chain risk is becoming a policy problem, not just a malware problem. The recurring attacks described here were possible because the ecosystem allowed a normal installation path to double as a code execution channel. That means teams need policy around which dependencies may execute, where, and under what approval model. The practical conclusion is simple: if a package needs script execution, it should earn that exception explicitly.
Build-time authority should be scoped as tightly as any other machine identity. Install scripts often run in environments that also hold secrets, deployment access, or cloud credentials, so the exposure is not abstract. The stronger governance model is to treat build runners and package installers as privileged execution contexts with narrow, reviewable rights. Security teams should align this thinking with NHI and CI/CD governance rather than treating package installs as low-risk plumbing.
From our research library:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
What this signals
Install-time execution is now a policy boundary, not a tooling convenience. Teams that still permit dependency scripts by default are preserving an old trust model that attackers have exploited repeatedly. The more defensible posture is to decide which packages may execute code at install time and to remove everything else from that trust path.
Build runners deserve machine-identity-style governance. When CI/CD environments can run third-party scripts while holding deployment credentials, they behave like privileged non-human identities. That means the same questions used for NHI governance apply here: who can act, what can they reach, and when is that authority revoked?
The shift to default-deny should be measured by exception count, not by package count. If many dependencies still need script execution, the exception process itself may be telling you where hidden build dependency risk remains. The goal is to narrow the set of packages that can run code, then keep that approval list small and reviewable.
For practitioners
- Define an allowlist for install scripts Review which dependencies truly require install-time execution and permit only those packages under explicit approval. Everything else should remain blocked by default in developer and CI environments.
- Separate package install from privileged secrets Remove cloud credentials, deployment tokens, and other sensitive environment variables from build contexts that can execute third-party scripts. Install steps should not have access to secrets they do not need.
- Audit transitive dependencies for script hooks Inspect dependency trees for preinstall, install, postinstall, and prepare scripts, including packages several layers deep. Transitive packages are part of the execution boundary, not just the visibility boundary.
- Adopt no-execution defaults in CI/CD Configure pipelines so dependency scripts do not run unless an exception is documented and approved. This is especially important for runners that can reach source control, package registries, or cloud control planes.
- Track package-manager policy drift Monitor changes in npm, pnpm, Bun, and Yarn defaults so local developer settings do not quietly reintroduce automatic script execution. Consistent policy matters more than the specific tool choice.
Key takeaways
- npm’s default script execution model created a supply chain control gap by allowing third-party code to run at install time with machine-level privileges.
- The article highlights a long-running pattern in which compromised packages used postinstall hooks to steal secrets and deliver malware through trusted builds.
- The practical response is to make package execution explicit, block transitive script hooks by default, and reserve allowlists for the small set of packages that genuinely need them.
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 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Install scripts can read secrets from developer and CI environments during dependency installation. |
| NHI-10 — Human Use of NHI | Developer and CI contexts often act as privileged non-human identities when running package installs. | |
| Recommendation — Block dependency scripts from environments that expose secrets and revoke any credentials reachable during installs. Scope build-time privileges so installers cannot act as unmanaged machine identities with broad access. | ||
| MITRE ATT&CK | TA0006;TA0011 — Credential Access; Command and Control | The attack path centers on stealing secrets during install and reaching out to attacker infrastructure. |
| Recommendation — Map install-script abuse to credential access and command-and-control activity in your detection pipeline. | ||
| CIS Controls v8 | CIS-5 — Account Management | Build and developer credentials used during installs need explicit lifecycle governance. |
| Recommendation — Limit install-time access to only the accounts and tokens required for the build job. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about removing default execution rights from dependency installs. |
| Recommendation — Review install paths as authorization decisions and remove implicit execution permissions from dependencies. | ||
Key terms
- Lifecycle Script: A lifecycle script is code that runs automatically during package installation or build steps, such as preinstall or postinstall hooks. These scripts are useful for legitimate automation but create a high-risk execution path because they can run before developers fully inspect the package.
- Transitive Dependency: A transitive dependency is a package that your software uses indirectly through another library rather than calling it directly. These dependencies often hide in Java estates, which makes visibility and runtime validation necessary to understand what code is actually present and active.
- Default-deny Package Execution: Default-deny package execution means dependency scripts are blocked unless a team explicitly allows them. This model reduces hidden trust in package installs by forcing review before code from third-party packages can run in developer, build, or deployment environments.
- Supply-chain execution path: A supply-chain execution path is the route by which remote code enters a trusted environment through dependency resolution, package fetching, or extension activation. It matters because the code is executed inside a legitimate workflow, which can hide the origin of the compromise until after identity assets have been exposed.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle controls. It is designed for practitioners who need to govern privileged non-human access across modern security programmes.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org