Topic starter
02/08/2026 11:27 am
TL;DR: npm v12 will stop running dependency install scripts by default, closing a major supply chain attack path that recent worms and credential stealers repeatedly abused, according to Aikido. The change matters because package install remains a trust boundary, and allowlist-based execution is now the safer default for modern software supply chains.
Editorial analysis by NHI Mgmt Group, based on content published by Aikido: “npm v12 delivers one of the biggest security improvements in years”.
Key questions
Q: What breaks when npm dependencies can execute install scripts automatically?
A: Install-time scripts turn a dependency into active code, so package presence is no longer the same as package safety.
Q: When should teams prioritise allowlisting over script blocking alone?
A: Teams should prioritise allowlisting when packages legitimately need install-time execution, because the real decision is not whether scripts exist but which packages are trusted to run them.
Q: What are the signs that install-time package trust is failing?
A: Common warning signs include unexpected lifecycle activity, packages that execute during install without a clear operational need, unreviewed Git or remote dependencies, and secret exposure from build or developer environments after a new version is published.
Practitioner guidance
- Inventory all install-time execution paths Catalog lifecycle scripts, Git dependencies, remote tarballs, and native build triggers across your repositories and build pipelines so you know where code can still run during install.
- Move package execution to explicit approval Adopt allowlists for packages that are permitted to run scripts, and require teams to justify every approved dependency that executes during installation.
- Test npm 11.16.0 warnings before upgrading Use the warning period to identify what will break when scripts stop running by default, then fix or approve only the dependencies that genuinely need execution.
Bottom line: Install-time execution remains the core weakness in software supply chains because it lets a poisoned package run before anyone imports it or reviews runtime behaviour.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 12:43 pm
Install-time execution is now a governance problem, not just a build convenience issue. Package managers that run third-party code by default turn dependency resolution into a trusted execution boundary, which is exactly where supply chain attackers want the control gap to live. The practical lesson is that package install must be treated as an approval event, not an automatic one.
A few things that frame the scale:
- The blast radius of the Salesloft-Drift OAuth supply chain attack was 10 times greater than earlier incidents in which attackers breached Salesforce directly.
A question worth separating out:
Q: What should teams do when a malicious package has already been installed on developer machines?
A: Isolate affected systems, identify every machine that installed the package, and remove the dependency from build paths and caches. Then hunt for follow on downloads, temporary files, suspicious Python processes, and outbound requests to the attacker infrastructure. Rebuild affected environments from trusted sources, rotate any credentials exposed on those systems, and add detections for the package name and its indicators of compromise.
👉 Read our full editorial: npm v12 makes install-time supply chain attacks harder to execute