Notifications
Clear all
Topic starter
02/08/2026 9:44 am
TL;DR: The most dangerous period for npm supply chain attacks is the short window between publication and independent review, according to Semgrep, and pinning versions, disabling install-time scripts, and delaying automated updates can materially reduce exposure. The core lesson is that perfect pre-install analysis is unrealistic, so controlling execution timing matters more than trusting every new package immediately.
NHIMG editorial — based on content published by Semgrep: LLMjacking: How Attackers Hijack AI Using Compromised NHIs
Questions worth separating out
Q: How should teams reduce risk from malicious npm package installs?
A: Treat package installation as a controlled operation, not an implicit trust event.
Q: Why do npm supply chain attacks create such a large IAM risk?
A: Because npm, GitHub, and cloud credentials often coexist in the same developer and build environments.
Q: What breaks when install-time scripts are left enabled by default?
A: Install-time scripts create an automatic execution path that can run malicious logic before a developer inspects the package contents.
Practitioner guidance
- Pin dependency versions before release promotion Freeze package versions in build and deployment pipelines so newly published malicious releases do not enter production automatically.
- Disable install-time script execution by default Use --ignore-scripts or equivalent controls to prevent preinstall and postinstall hooks from running automatically during package installation.
- Delay automated dependency merges for 24 to 48 hours Hold Dependabot or equivalent update PRs long enough for registry maintainers and researchers to identify malicious releases.
What's in the full article
Semgrep's full analysis covers the operational detail this post intentionally leaves for the source:
- How Semgrep tested readable, minified, obfuscated, and binary payloads with LLMs during dependency triage.
- Why lifecycle script abuse in npm maps to real-world install-time execution risk for developers and build systems.
- What Semgrep recommends for pinning versions, delaying merges, and using --ignore-scripts in practice.
- The BSides Delaware 2025 talk and slides that expand the hands-on examples behind the analysis.
👉 Read Semgrep's analysis of the npm supply chain exposure window →
npm supply chain attacks: how much exposure window is left?
Explore further
02/08/2026 12:37 pm
Supply chain security is now an identity and execution problem, not just a code review problem. The article shows that the real risk comes from when code is allowed to run and which credentials can be abused during that period. That places developer tokens, build access, and package trust squarely inside the governance scope of IAM and PAM teams. Practitioners should treat dependency intake as a privileged access decision, not a routine tooling choice.
A question worth separating out:
Q: Who is accountable when a malicious dependency enters a build pipeline?
A: Accountability is shared across engineering, security, and platform teams, but the control owner should be clear. Dependency intake, script execution, and publishing credentials are all governance points. In practice, the teams responsible for CI/CD, package policy, and non-human credential lifecycle must define who can approve, who can execute, and who can revoke.
👉 Read our full editorial: Shortening the npm exposure window reduces supply chain malware risk
