GitHub npm v12 Disables Dependency Scripts by Default
Key insights
- npm v12 blocks all dependency install scripts by default, requiring explicit opt-in approval via the new approve-scripts workflow before running.
- Git dependencies and remote URL packages now each require explicit CLI flags: --allow-git and --allow-remote respectively.
- npm 11.16.0 already surfaces script warnings so teams can audit and approve trusted packages ahead of the v12 release.
Why this matters
The JavaScript ecosystem's default install behavior has long been an unrestricted code-execution channel; v12 turns every project's dependency scripts into an explicit, auditable decision rather than an automatic one. Teams running automated builds, CI pipelines, or any workflow that invokes npm install programmatically face potential build breakage if they do not audit and approve scripts before v12 ships next month. The approve-scripts model also creates a defensible record for organizations that need to demonstrate software supply chain oversight to auditors or enterprise customers.
Summary
npm v12, due next month, will no longer run install scripts from dependencies by default. GitHub calls these lifecycle scripts 'the single largest code-execution surface in the npm ecosystem,' and the change closes three vectors: preinstall, install, and postinstall scripts from all dependencies; git-sourced packages (now requiring --allow-git); and remote URL packages like HTTPS tarballs (now requiring --allow-remote).
A single compromised package anywhere in a dependency tree can currently execute arbitrary code on developer machines or CI runners at install time. v12 requires explicit approval before any of that runs.
Essentially: GitHub (npm) inverts the default from opt-out to opt-in for all dependency code execution.
- Teams use npm approve-scripts --allow-scripts-pending to vet packages ahead of the upgrade
- Git and remote-URL dependencies each require separate opt-in flags
- npm 11.16.0 already surfaces warnings for teams preparing to migrate
Every JavaScript project that runs npm install programmatically is in scope for this change.
Potential risks and opportunities
Risks
- Projects relying on postinstall for binary downloads or native add-on compilation face broken builds at the npm v12 cutover unless maintainers and consumers coordinate script approval before next month's release.
- Teams that respond by blanket-approving all scripts via approve-scripts eliminate the security benefit entirely and remain exposed to the supply chain attacks the change was designed to prevent.
- CI runners and automated deployment pipelines that invoke npm install non-interactively cannot prompt for approval, requiring new pipeline-level configuration or builds will fail after v12 ships.
Opportunities
- Software composition analysis vendors (Snyk, Socket, Chainguard) can offer pre-vetted script-approval policies as a managed workflow layered on top of the npm approve-scripts primitive.
- Private artifact registry providers (JFrog Artifactory, Sonatype Nexus) can add organization-wide script-approval policies and audit logs as an enterprise differentiator ahead of the v12 release.
- Package authors who proactively remove or minimize install scripts gain a trust signal over competitors that still require approval, creating competitive pressure to reduce install-time code execution ecosystem-wide.
What we don't know yet
- No details provided on how transitive-dependency approval scales in projects with hundreds of indirect dependencies that rely on install scripts.
- The article does not address whether approved-script state will be stored in package-lock.json or whether approval must be repeated per environment or per developer machine.
- No data given on what share of top-ranked npm packages currently use install scripts and would be directly affected by the default change.
Originally reported by thehackernews.com
Read the original article →Original headline: GitHub to Disable npm Install Scripts by Default in npm v12 to Block Supply Chain Attacks