TL;DR: Recent NPM attacks exploit predictable gaps in version ranges, lockfile trust, cooldown timing, and package provenance, according to ArmorCode, and show how exact pinning, npm ci, release-age controls, and install-script review reduce exposure. The lesson is that dependency governance, not just scanning, now determines whether poisoned packages reach production.
At a glance
What this is: ArmorCode shows that NPM supply chain attacks keep bypassing simple version control because build systems still trust dependency resolution, lockfiles and install-time execution paths.
Why it matters: This matters because application security teams need governance over dependency resolution and provenance, not just vulnerability scanning, to stop poisoned packages reaching production.
Context
NPM supply chain attacks exploit a governance gap rather than a single technical flaw: teams often assume that version pinning, a lockfile, or an SCA scan is enough to control what code enters a build. In practice, package resolution, install scripts and publishing trust create multiple places where unreviewed code can slip through.
The identity angle is real even though the subject is software supply chain risk. Maintainer accounts, publishing tokens and provenance attestations determine who can publish trusted code, while CI runners and automation identities decide what gets executed in production paths. When those identities are weakly governed, dependency control becomes an access-control problem as much as a software hygiene problem.
The article's starting position is typical for modern JavaScript delivery environments: dependency trust is distributed across package registries, lockfiles and pipeline identities, so a single control rarely contains the whole risk.
Key questions
Q: What breaks when version pinning is the only defence against NPM supply chain attacks?
A: Version pinning limits automatic upgrades, but it does not stop poisoned lockfiles, malicious install scripts or compromised publisher accounts from introducing trusted-looking code. The real failure is assuming that one manifest setting can govern the whole dependency lifecycle. Teams need controls at resolution, publication and install time.
Q: Why do lockfiles and npm ci still fail after a dependency compromise?
A: They fail when the lockfile itself becomes the attacker’s target. If a malicious version is committed during an active compromise window, npm ci will faithfully install that poisoned state because determinism only preserves what was already trusted. The control works, but it works on potentially bad input.
Q: How do teams know whether a vulnerable dependency is actually risky?
A: Teams should test whether the vulnerable function is reachable from real application flows. If the code path cannot be invoked with application data, the finding may still exist, but the exploitability is lower and should be documented differently. Reachability evidence is far more defensible than counting raw CVEs alone.
Q: Should organisations prefer provenance verification or release-age controls for NPM risk?
A: They should use both because they address different failure points. Release-age controls reduce exposure to freshly weaponised packages, while provenance checks help confirm that the artifact came through a trusted publishing path. One filters timing, the other filters origin, and neither is sufficient alone.
Technical breakdown
Why SemVer ranges create hidden trust in package resolution
Semantic versioning ranges such as caret and tilde do not simply describe compatibility. They instruct npm to accept future releases inside a range, which means the build system is allowed to choose code the team has not explicitly reviewed. In supply chain attacks, that trust is the entry point: an attacker only needs to publish a malicious package version that still satisfies the range. Exact pinning removes that automatic choice, but it also shifts responsibility back to governance because every version bump now becomes a conscious approval decision.
Practical implication: Treat version range policy as a security control, not a convenience setting, and limit permissive ranges to low-risk development dependencies.
How lockfiles and npm ci enforce build determinism
A lockfile records the exact dependency tree that should be installed, including transitive packages. npm ci enforces that tree and fails when the lockfile and manifest diverge, which makes builds repeatable instead of opportunistic. The important limitation is that lockfiles can be poisoned before enforcement ever happens: if an attacker gets a malicious version into the lockfile during the vulnerable window, later deterministic installs will faithfully reproduce the compromise. Determinism is valuable, but only if the source of the locked state is trustworthy.
Practical implication: Require lockfile review and CI enforcement together, because deterministic installs do not protect against a compromised lockfile.
Why provenance and install-script review matter in NPM chains
Provenance attestation ties a published package to the source commit and the CI workflow that built it, which lets defenders distinguish software produced through trusted automation from software published through an account or token compromise. Install scripts matter for a different reason: they execute at install time, often before the package's behavior has been analysed. A new dependency with a postinstall hook is therefore a high-signal indicator of risk because it combines novelty with immediate execution. These two controls address different attack paths and should be evaluated together, not as substitutes.
Practical implication: Verify package provenance and flag new dependencies with install scripts before they are allowed into production branches.
Threat narrative
Attacker objective: The attacker wants to insert code into trusted software delivery paths so that compromised packages execute inside build or developer environments and spread into production releases.
- Entry occurs when attackers abuse maintainer credentials, typosquatted package names or dependency confusion to get malicious code into the NPM resolution path.
- Credential or publishing trust is then leveraged through version ranges, poisoned lockfiles or postinstall hooks so the malicious package is installed and executed by build automation.
- Impact follows when the build pipeline trusts the dependency and the malicious code reaches developer systems, CI runners or downstream production builds.
Breaches seen in the wild
- postmark-mcp malicious MCP server 2025: A fake Postmark MCP server on npm quietly BCC'd every email AI agents sent through it to an attacker, using victims' own Postmark tokens.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Dependency governance is now a build-time trust problem, not just a vulnerability-management problem. Version pinning, lockfiles and scanners each control only one part of the path from package publish to package execution. The attacker looks for the gap between those controls, which is why governance over resolution, provenance and install-time behavior has become the decisive layer. Practitioners should treat dependency trust as an access-control issue.
Lockfile determinism is only as trustworthy as the moment it was created. If the lockfile can be altered during a short attack window, every later deterministic build faithfully reproduces the compromise. That creates a specific failure mode: the control is not broken, but it is applied too late in the lifecycle. Teams need to review how build state becomes authoritative, not assume a locked file is inherently safe.
Package provenance should be treated as a publishing identity signal. The article shows why source commits, CI workflows and attestations matter: they establish who is allowed to produce the artifact. In identity terms, this is close to a machine identity problem, because the package publisher and the CI workflow are both trusted non-human actors. Practitioners should align provenance checks with broader NHI governance.
Install scripts remain one of the highest-value inspection points in NPM defense. A new dependency that also requests execution at install time collapses trust and execution into a single event. That is exactly the kind of pattern policy should surface before merge, because the risk is not the package name alone but the combination of novelty, execution and unresolved provenance. Teams should force manual review on that combination.
Package provenance gap: The core governance failure in recent NPM attacks is the assumption that a dependency is trustworthy once it appears in a lockfile or passes a basic scan. In reality, trust must be established at publication, at resolution and at install time, or an attacker can cross the gap between those checkpoints. Practitioners should design controls around that lifecycle break rather than around any single tool.
From our research library:
- The blast radius of the Salesloft-Drift OAuth supply chain attack was 10 times greater than earlier incidents in which attackers breached Salesforce directly.
- Read next: AI Supply Chain Security and AI-BOM Guide
What this signals
Package provenance is becoming a practical governance boundary for software delivery. Once teams accept that a lockfile can faithfully reproduce a compromise, the control point shifts to how the package was published and by whom. That makes provenance attestation and release-age filtering part of the same control conversation, not separate hygiene tasks.
Dependency trust now intersects with non-human identity governance. Maintainer accounts, publishing tokens and CI workflows are all non-human identities that can be abused to make malicious code look legitimate. The lesson for practitioners is that NHI governance no longer belongs only in infrastructure or secrets management teams; it belongs in software delivery policy as well.
For practitioners
- Enforce exact version pinning for production dependencies Remove caret-based ranges from production package.json files where feasible and reserve looser ranges for non-production dependencies only.
- Require npm ci in CI/CD pipelines Block builds that use npm install in production workflows so the pipeline installs exactly what the reviewed lockfile specifies.
- Review every lockfile delta before merge Treat package-lock.json changes as security-relevant and inspect unexpected version jumps, new packages and dependency tree expansion.
- Flag new dependencies with install scripts Add a CI check that catches packages newly introduced in the lockfile when hasInstallScript is true, then require manual approval.
- Verify package provenance before release Use provenance checks to confirm that packages were built from trusted source commits and CI workflows rather than ad hoc publishing paths.
Key takeaways
- NPM supply chain attacks succeed when teams trust dependency resolution, lockfiles and install-time execution as if they were the same control.
- The article shows that compromise can survive deterministic builds if the lockfile or publishing path was already poisoned.
- Practitioners should combine exact pinning, lockfile review, provenance checks and install-script gating rather than relying on scanning alone.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Package publishers, tokens and CI workflows are third-party identities in this supply chain attack pattern. |
| NHI-04 — Insecure Authentication | Maintainer account compromise and stolen publish tokens are central to the attack chain described. | |
| NHI-07 — Long-Lived Secrets | Publish tokens and build credentials become durable attack paths when they are not tightly governed. | |
| Recommendation — Assess third-party package trust paths under NHI-03 before allowing them into production builds. Harden publishing authentication and revoke weak credentials that can publish to npm. Rotate long-lived publishing secrets and reduce their exposure across developer and CI environments. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article’s attack chain includes credential theft and propagation through trusted software delivery paths. |
| Recommendation — Map credential theft and downstream package propagation to TA0006 and TA0008 in your detections. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Publishing rights, registry access and build permissions need explicit entitlement governance. |
| Recommendation — Apply PR.AA-05 to restrict who can publish, install and approve dependency changes. | ||
Key terms
- SemVer Range: A SemVer range tells a package manager which versions are acceptable, rather than naming one exact release. In NPM, permissive ranges can silently admit future package versions that have never been reviewed, which turns compatibility syntax into a security control problem.
- Lockfile Drift: Lockfile drift is the mismatch between the dependency tree recorded in a lockfile and the versions actually installed or executed. It usually happens when build commands allow semver-based resolution, turning a controlled artifact into a moving target and weakening assurance across CI/CD and production.
- Provenance Attestation: A provenance attestation is evidence that software was produced through a known pipeline or workflow. It helps verify origin, but it does not guarantee that the workflow was free of compromise, poisoned caches, or attacker-controlled inputs.
- Install Script: An install script is code that runs automatically when a package is installed. Because it executes before a package is fully trusted, it is a high-risk mechanism in NPM supply chain attacks and should trigger stronger review when attached to a new dependency.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It helps practitioners connect identity controls to the build and delivery systems that increasingly carry production risk.
Published by the NHIMG editorial team on August 19, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org