What breaks when a build pipeline trusts npm dependencies only at the registry layer?

What actually breaks in the supply chain trust model?

When a build pipeline treats npm as the only trust boundary, it confuses package approval with package execution. The registry may show a benign tarball, but the installer can still follow dependency hooks, remote fetches, scripts, or redirect paths that change what code actually runs. That breaks the assumption that the reviewed artefact is the artefact being built.

That distinction matters because supply chain controls only work when provenance, inspection, and execution all refer to the same object. Once they diverge, the pipeline can bless one package while executing another, which makes release assurance look stronger than it is.

A useful reference point is the build-provenance discipline in SLSA, which is designed to keep source, build inputs, and produced artefacts tied together rather than trusted by registry reputation alone.

Why registry-only trust creates blind spots for dependency risk

Registry checks can reduce obvious typosquatting and metadata abuse, but they do not eliminate the ways installers resolve, transform, or execute dependency content at build time. If policy only evaluates the registry record, it can miss lifecycle events such as postinstall execution, transitive substitution, lockfile drift, or external fetches that happen after approval.

That blind spot is especially dangerous in pipelines that sign releases, generate SBOMs, or cache dependencies as if the registry view were authoritative. The result is a false sense of control: the package name is known, but the code path is not fully bounded.

For teams hardening this area, the most relevant control question is whether dependency policy applies to the source package alone or also to what the installer is permitted to execute. Supply chain assurance depends on the latter, not the former.

Registry-centric trust also weakens the value of scanning. If the scanner inspects a package record but the installer later resolves an external payload or script, detection and approval are no longer looking at the same content. That gap is where malicious code can slip past review while still entering the build identity, token, or signing context.

How attackers exploit the gap between package approval and package execution

Attackers like this gap because it lets them hide in a trusted channel. A dependency can look legitimate in the registry and still trigger code paths that steal secrets, alter build output, or stage follow-on compromise during installation. The defender is watching the catalogue entry; the attacker is abusing the runtime behaviour.

This is the pattern seen across npm supply chain incidents: a package identity may be trusted, yet a malicious install path can still harvest credentials, tamper with CI/CD state, or pivot into source control and signing workflows. The harm is not limited to the dependency itself, it is the authority granted to the pipeline while it processes that dependency.

Related attack-path analysis is covered in MITRE ATT&CK Enterprise, which helps map credential access, execution, and persistence behaviours once malicious code reaches the build environment.

Recent npm-focused campaigns also show why registry trust is insufficient. NHIMG’s Shai Hulud npm malware campaign and Mastra npm Supply Chain Attack, Sapphire Sleet both illustrate how quickly a malicious package can convert installer trust into secret theft and downstream compromise.

Practitioner Guidance

What to verify: Verify that the artefact approved by policy is the same artefact the installer resolves and executes. If your controls do not bind registry identity, lockfile state, script execution, and fetched content to one provenance chain, the pipeline is still trusting by reputation rather than by evidence.

What to prioritise: Prioritise controls that remove hidden execution paths first, then tighten provenance and signing. Disable or constrain install-time scripts where possible, pin and attest dependencies, and treat any external fetch during build as a separate trust decision rather than an implementation detail.

Common mistake: The common mistake is to treat package review as sufficient once the registry entry is clean. For build systems, the real decision is whether the pipeline can prove what it executed, not just what it intended to download.

Practitioner takeaway: If registry trust and execution trust are not the same control point, your supply chain assurance is already weaker than your tooling reports.

Related resources from NHI Mgmt Group

• What breaks when a malicious dependency can execute on import in a build or ML pipeline?
• What breaks when remote dynamic dependencies are not controlled in npm builds?
• What fails when a malicious npm package reaches a mobile app build pipeline?
• What breaks when an npm maintainer identity is compromised in a CI/CD pipeline?