Topic starter
02/08/2026 11:27 am
TL;DR: Install-time execution stays the weak point because poisoned packages can act before import or review, according to Aikido. Package installs now need explicit trust decisions, especially where Git, URLs, and build identities can trigger code during setup.
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: 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.
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.
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.
Glossary terms: Install-Time Execution, Lifecycle Script, Allowlist, Publish token
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 2 days ago by NHI Mgmt Group
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