Notifications
Clear all
Topic starter
02/08/2026 11:23 am
TL;DR: npm v12 will block automatic install scripts, Git dependencies, and remote URL dependencies by default, but OXSecurity argues those changes still leave account takeover, native builds, and publish-time intent detection unresolved as Shai-Hulud variants keep evolving. The deeper risk is that platform-level trust controls lag behind attacker adaptation, especially when compromised maintainers can still ship malicious releases.
NHIMG editorial — based on content published by OXSecurity: npm v12 will not close the gaps that matter most in the latest Shai-Hulud supply chain attacks
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: What breaks when a trusted npm package publisher is compromised?
A: When a trusted publisher is compromised, registry trust collapses because malicious code can arrive through a legitimate release path.
Q: Why do non-human identities matter in software supply chain security?
A: Non-human identities control publishing, automation, and distribution in modern software pipelines.
Q: How do security teams know whether package installation risk is under control?
A: Look for three signals: scripts are blocked or tightly governed during install, runner memory and local secrets are minimized, and package provenance is checked before deployment.
Practitioner guidance
- Classify package maintainers as privileged identities Map npm maintainers, bot accounts, CI publishers, and release automation into the privileged access model.
- Restrict publish tokens and automate revocation Issue short-lived or tightly scoped tokens for package publishing, and revoke them automatically when anomalous publish behaviour, account compromise, or repository drift is detected.
- Inspect execution paths beyond postinstall hooks Review native build triggers, import-time execution, and transitive dependency behaviour in addition to lifecycle scripts.
What's in the full article
OXSecurity's full analysis covers the operational detail this post intentionally leaves for the source:
- Specific examples of how Shai-Hulud variants evade sandboxing and detection infrastructure.
- The package and repository indicators that can help teams identify malicious publish behaviour earlier.
- Details on how native build paths can still execute attacker code even when install scripts are blocked.
- The article’s commentary on why platform owners, not just enterprise defenders, need to close these gaps.
👉 Read OXSecurity’s analysis of npm v12 and the Shai-Hulud supply chain attacks →
npm supply chain attacks: are v12 defaults enough for developers?
Explore further
02/08/2026 12:40 pm
Package publishing is now an NHI governance problem, not just a developer hygiene problem. npm packages are delivered through maintainer accounts, tokens, and automation systems that behave like non-human identities. When those identities are compromised, the package registry becomes a high-trust distribution layer for malware. That shifts ownership from only AppSec and build engineering to IAM, PAM, and secret governance teams as well. Practitioners should treat package publishing rights as privileged access with lifecycle controls, not as a generic developer entitlement.
A question worth separating out:
Q: Who is accountable when malicious code enters through a package registry?
A: Accountability usually spans the package maintainer, the registry controls, and the consuming organisation’s build governance. The maintainer identity is the publishing control point, but the consumer still owns script restrictions, lockfile enforcement, and credential protection on build systems. The right question is who owned each control layer, not who noticed the attack first.
👉 Read our full editorial: npm supply chain attacks expose the limits of v12 security defaults
