Topic starter
02/08/2026 11:25 am
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.
Editorial analysis by NHI Mgmt Group, based on content published by Semgrep: “RIP post/preinstall scripts: An obituary for the npm feature only TeamPCP will miss”.
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.
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.
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.
Practitioner guidance
- Define an allowlist for install scripts Review which dependencies truly require install-time execution and permit only those packages under explicit approval.
- 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.
- Audit transitive dependencies for script hooks Inspect dependency trees for preinstall, install, postinstall, and prepare scripts, including packages several layers deep.
Bottom line: 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.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 12:42 pm
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.
A few things that frame the scale:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
A question worth separating out:
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.
👉 Read our full editorial: npm removes default script execution: supply chain risk shifts left