What breaks when organisations rely on package version checks without verifying what code actually runs during dependency installation?

Why This Matters for Security Teams

Version checks answer only one question: whether a dependency name and release number match what the inventory expects. They do not prove that the installed code is the same code that was reviewed, tested, or approved. That gap matters because modern supply chain attacks often hide in install-time behaviour, where a package can pass version validation while running scripts, fetching payloads, or modifying the local environment. NIST SP 800-53 Rev 5 Security and Privacy Controls makes the broader point that integrity, least privilege, and change control all need explicit enforcement, not assumption.

Security teams often focus on vulnerability management and miss the fact that malicious behaviour can arrive before runtime scanning ever sees the package. Package ecosystems routinely allow postinstall actions, optional build steps, and transitive dependencies that expand the trust boundary beyond the version string. A dependency can therefore be “known” and still be unsafe in practice if its installation path is untrusted or opaque. This is especially relevant in CI/CD, where automation grants broad access to source code, secrets, and artifact signing material.

In practice, many security teams encounter dependency abuse only after a build pipeline has already executed unreviewed install-time code, rather than through intentional supply chain validation.

How It Works in Practice

The core failure is treating version metadata as a proxy for execution integrity. A package manager may verify that a release number exists in a repository, but that does not confirm what scripts ran during installation, what files were added, or whether the package fetched additional content from an external location. Current guidance suggests using layered controls that check both provenance and behaviour. NIST SP 800-207 Zero Trust Architecture is useful here because it assumes no implicit trust in packages, build workers, or repositories simply because they are inside an approved workflow.

Practitioners should validate the full install path, not just the package record. That usually means combining repository trust, artifact integrity, and runtime observation.

• Require signed or otherwise authenticated package sources where available.
• Inspect install scripts, build steps, and lifecycle hooks before promotion.
• Monitor for new files, unexpected network connections, and altered environment variables during installation.
• Compare the installed artifact hash or provenance attestation against the expected release content.
• Score dependency risk using maintainer activity, release churn, and unusual permission requests.

This approach is strongest when paired with a software bill of materials, dependency allowlisting, and pipeline isolation that limits secrets and outbound network access. It also helps to separate the trust decision for package metadata from the trust decision for execution. Those are not the same control. A package can be correctly versioned and still execute code that no one intended to ship, which is why runtime and install-time telemetry matter as much as repository review. These controls tend to break down when build systems have unrestricted internet access and shared secrets, because malicious install scripts can exfiltrate data before detection logic runs.

Common Variations and Edge Cases

Tighter dependency verification often increases build friction, requiring organisations to balance release speed against stronger supply chain assurance. That tradeoff becomes more visible in polyglot environments, where each ecosystem handles lifecycle scripts, lockfiles, and provenance differently.

Best practice is evolving, and there is no universal standard for this yet. Some teams can block install scripts entirely in CI, while others need them for legitimate native builds or private package generation. In those cases, the safer pattern is controlled execution: run installs in disposable environments, restrict network egress, and review any artifact changes before publication. For package ecosystems with weak provenance support, the absence of a signature or attestation should be treated as a risk signal rather than a pass. The same applies when transitive dependencies introduce unexpected install-time behaviour that the primary package never advertised.

This issue also intersects with identity and NHI governance when automation tokens, build agents, or publishing credentials are available during dependency installation. If those non-human identities are over-privileged, a hostile package can turn an installation event into a repository compromise. For governance and control mapping, NIST SP 800-53 Rev 5 Security and Privacy Controls remains the clearest baseline for integrity and change management, while software supply chain checks should be aligned to the actual execution path, not the catalog entry alone.

Related resources from NHI Mgmt Group

• What breaks when a malicious package runs during dependency installation?
• What breaks when security teams rely on package version checks alone for dependency risk decisions?
• What breaks when organisations rely on visual inspection alone for ID checks?
• What breaks when organisations rely on SAML without lifecycle automation?