What breaks when CI/CD pipelines allow unfrozen dependency installs?

Why unfrozen installs break the build contract

Unfrozen dependency installs break the basic promise that the same input produces the same output. A pipeline that is allowed to float to newer matching versions can silently change what gets built, tested, signed, and deployed. That turns dependency resolution into a moving target, so the build no longer represents a fixed, reviewable software bill of materials for that run.

That matters even when the project uses a lockfile, because the pipeline policy can override it. Once the resolver is free to advance versions, version ranges become an implicit trust decision, not just a convenience for maintenance. In practice, the dependency graph can change without a code change, which makes approvals, diffs, and repeatability much harder to trust.

SLSA is the clearest external frame here because build provenance depends on controlled inputs, including dependency selection. If you permit installs to drift, you weaken the ability to prove what artifact was actually built from what source and dependency set.

How drift becomes a supply chain exposure

The risk is not only accidental version churn. Unfrozen installs enlarge the window in which a malicious package update, maintainer compromise, typo-squat, or dependency hijack can enter the build path. The pipeline may pull a version that passed semantic-version rules but was never intended by the team, which is exactly how supply chain boundaries get crossed.

This is especially dangerous in CI/CD because build systems often run with broad access to source, signing material, deployment tokens, or release automation. A single unexpected dependency can become a delivery mechanism for code execution, credential exposure, or poisoned artifacts. OpenSSF guidance is relevant because the practical defense is to constrain inputs and verify the software path, not to assume package registries remain stable or benign.

Mastra npm Supply Chain Attack, Sapphire Sleet and tj-actions/changed-files compromise 2025 show the same underlying pattern from different angles: trusted delivery paths become dangerous when a dependency or action can be swapped underneath a pipeline. The lesson is that drift is not just a maintenance issue, it is an attack surface.

What frozen installs preserve in practice

Frozen installs preserve the exact dependency set that was reviewed and previously resolved. That gives teams a stable build boundary, better test fidelity, and a cleaner audit trail when investigating why a release changed. It also makes dependency changes intentional, because any update must come through a separate review and refresh step rather than slipping in during an ordinary build.

The control is strongest when paired with pinned source references, integrity checks, and a clear update workflow. Teams should treat dependency refreshes as controlled events, not as a side effect of routine CI execution. That is where reproducibility, provenance, and release confidence come from: the build process stops making version decisions on the fly and starts enforcing the version decisions that were already made.

CI/CD Pipeline Identity Security Guide is useful because dependency control is only one part of the larger pipeline trust model, and build integrity depends on both software inputs and the identities that can change them.

Risk and Threat Considerations

Allowing unfrozen installs creates a supply chain risk because the pipeline can ingest code that no reviewer explicitly approved for that build. The failure mode is often subtle, since the build still “works” while the artifact, test outcome, or runtime behaviour has already shifted.

Failure mechanism: Semver ranges and resolver behaviour let the pipeline select a newer dependency than the one locked or previously validated, which can introduce malicious or simply untested code into the build path.

Impact: Release reproducibility weakens, incident investigation becomes harder, and a compromised dependency can spread through signed artifacts, caches, or downstream deployments before the change is noticed.

Practitioner Guidance

What to verify: Confirm that CI uses frozen or lockfile-enforced installation modes for release builds, and that dependency refreshes happen only in a separate, reviewable update workflow. If the same job both resolves and ships dependencies, you are blending change control with delivery.

Decision rule: If a pipeline can select versions from a range during a production build, treat that as a release integrity problem, not a convenience feature. If the build must update dependencies, make that update explicit, reviewable, and attributable.

What practitioners underestimate: The issue is not limited to a bad package getting in once. The deeper problem is that every build becomes a new dependency decision, which makes provenance, rollback, and forensic comparison much less reliable.

Practitioner takeaway: Frozen installs are less about package hygiene and more about preserving the trust boundary between reviewed source and shipped artifact.

Related resources from NHI Mgmt Group

• What breaks when dependency confusion is allowed in CI/CD pipelines?
• How should security teams implement dependency validation for npm installs in CI/CD pipelines?
• What breaks when CI/CD pipelines rely on static secrets?
• What breaks when CI/CD pipelines rely on static YAML alone?