Notifications
Clear all
Topic starter
18/08/2026 2:14 pm
TL;DR: GitHub's npm v12 will make install scripts, Git dependencies, and remote-URL packages opt-in, changing a decade of default behavior that attackers exploited for install-time malware, according to LEGIT Security. The shift reduces the blast radius of poisoned packages, but it also raises the governance burden on approvals, publisher identity, and runtime monitoring.
NHIMG editorial — based on content published by LEGIT Security: npm v12 shifts install-time code execution to opt-in
Questions worth separating out
Q: What breaks when npm package installation is allowed to execute lifecycle scripts by default?
A: A malicious dependency can run code before installation completes, which turns normal package resolution into a payload delivery mechanism.
Q: Why do Git and remote-URL dependencies increase supply chain risk?
A: They let package resolution reach outside the registry and, in some cases, invoke local tooling that can be manipulated through configuration.
Q: How do security teams know if dependency controls are actually working?
A: Look for whether build systems prevent unauthorised version drift, whether package provenance is checked before install, and whether secret-handling code is isolated from broad application reach.
Practitioner guidance
- Implement explicit script approval workflows Use npm approve-scripts to identify every package requesting lifecycle execution, then approve only the dependencies that have a documented build reason and a named reviewer.
- Inventory Git and remote-URL dependencies Enumerate packages that rely on Git sources or remote tarballs, then remove any that persist only because they were never challenged.
- Replace long-lived publishing tokens Move package publishing to short-lived, phishing-resistant sessions and Trusted Publishing so CI does not store reusable credentials.
What's in the full article
LEGIT Security's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step guidance for approving, blocking, and auditing npm install scripts across development and CI environments
- The exact npm version and rollout sequence for allowScripts, --allow-git, and --allow-remote enforcement
- Practical examples of how Shai-Hulud, eslint-config-prettier, and related package compromises map to the new defaults
- Guidance on replacing classic publishing tokens with Trusted Publishing and WebAuthn-based 2FA
👉 Read LEGIT Security's analysis of npm v12 breaking changes and supply chain risk →
npm v12 and install scripts: are your pipelines ready?
Explore further
18/08/2026 3:05 pm
Install-time execution trust is the governance flaw npm v12 is finally narrowing. For years, npm treated package installation as a trusted execution moment, which meant transitive dependencies could run code before any review or policy check. That is not just a software convenience issue. It is a lifecycle governance problem because the build system was allowed to execute code without explicit authorization. Practitioners should treat this as a prompt to separate package acquisition from code execution policy.
A question worth separating out:
Q: Who is accountable when a poisoned package reaches production through approved dependencies?
A: Accountability usually sits with both the platform team that owns package policy and the application owners who accepted the exception. Once a package is allowed to execute, it becomes a governed privilege decision. That means approvals, publisher identity checks, and revocation procedures need ownership just like any other elevated access path.
👉 Read our full editorial: npm v12 shifts install-time code execution to opt-in
