Dependency Pinning vs Floating Versions

Dependency pinning , specifying exact version numbers rather than version ranges in dependency specifications , is the practice that ensures that the same dependency versions are resolved on every build, in every environment, at every point in time. Floating version specifications , using >= or ~= or similar range operators that allow the package manager to resolve newer compatible versions , create deployments where the software that runs in production may be different from the software that was tested, because a new dependency version was published between the test run and the production deployment.

The phantom dependency change mechanism is the specific risk. When a CI/CD pipeline is configured with floating version specifications, the dependencies resolved during the test run may be different from the dependencies resolved when the same pipeline runs again the next day , if any package matching a floating specification published a new version in the interim. The test run resolves the dependencies available at test time; the production deployment resolves the dependencies available at deployment time. Without lock files that record the exact resolved versions, the two sets of dependencies may be different, and the difference will not be visible in any diff of the application code.

The supply chain security implication extends beyond bugs. A floating version specification that resolves a new version of a dependency is a mechanism through which a supply chain attacker can reach production deployments: publish a malicious package version that satisfies a widely-used floating specification, and that version will be resolved by any build that runs after publication , until the malicious version is removed, flagged, or superseded by a higher version. Dependency pinning does not eliminate this risk entirely , pinned dependencies can still be updated by a developer who intentionally pulls a new version , but it prevents the automatic resolution of new versions without explicit developer action.

Why this matters

Dependency pinning matters for TPRM because floating version specifications in vendor codebases mean that the software a vendor delivered yesterday may differ from the software they build tomorrow , even if no application code was changed. For supply chain security, reproducibility of dependency resolution is a foundational control. Vendors who use floating specifications without lock file enforcement are building software whose composition changes with each build.

• Floating version specifications , resolved software changes with new package publications
• Lock file absent or not enforced , no record of exact resolved versions
• Test-to-production dependency divergence , different versions tested and deployed
• Supply chain attack vector through floating specs , malicious version satisfies range
• Build reproducibility undermined by non-pinned dependencies

What good looks like

Mature dependency management programmes use exact version pinning in dependency specifications or enforce lock file usage , ensuring that dependency resolution is deterministic and that the exact resolved versions are recorded and reproducible across test, staging, and production environments.

• Exact version pinning or lock file enforcement for all production dependencies
• Lock file checked into version control , recorded resolved versions
• Lock file diff in code review , dependency changes visible and reviewed
• Deliberate dependency updates , developer intent required, not automatic resolution
• Pin verification in CI , builds fail if lock file is not current

Tooling

Dependency Pinning , npm ci (uses package-lock.json), pip install -r requirements.txt with hashes, Pipenv/Poetry for Python pinning

Language-specific package managers provide lock file mechanisms that record exact resolved dependency versions and enforce their use. npm ci installs from package-lock.json rather than resolving from package.json, preventing floating specification resolution. pip install with hash verification in requirements.txt pins both version and hash. For TPRM practitioners, asking whether vendors use lock file enforcement in production builds provides a specific dependency pinning question.

Governance challenges

The governance challenge with dependency pinning is the security update friction. Pinned dependencies do not automatically pick up security patches , the developer must explicitly update the lock file. This friction motivates some teams to prefer floating specifications so security patches are automatically resolved. The governance resolution is automated dependency update tooling , Dependabot, Renovate , that opens pull requests for lock file updates with security patches, combining the security patch responsiveness of floating specifications with the deployment reproducibility of pinned versions.

• Enforce lock files in production builds , floating specifications acceptable in dev with lock file
• Check lock files into version control , visible dependency change history
• Implement Dependabot or Renovate , automated security update PRs with lock file updates
• Include lock file review in code review requirements
• Pin verification in CI pipeline , build failure if lock file diverges

If you are a small team

Check whether your most critical software vendors' repositories contain lock files , package-lock.json for npm, Pipfile.lock or requirements.txt with hashes for Python, Gemfile.lock for Ruby. The presence of a committed lock file indicates dependency pinning. Ask vendors whether their production builds enforce lock file usage (npm ci rather than npm install for npm, for example). The lock file confirmation is visible in a repository check that takes seconds.

• Check vendor repositories for committed lock files
• Ask whether production builds use lock file enforcement (npm ci etc)
• Ask about automated security update tooling , Dependabot or Renovate
• Include lock file enforcement in vendor supply chain assessment

What to require

Ask directly:

"Do your production builds use lock file enforcement , specifically, do you use npm ci rather than npm install, pip install with hash verification, or equivalent mechanisms that ensure the same dependency versions are installed in every build?"

Expect as evidence

• Lock file existence in production repositories
• Lock file enforcement in CI/CD pipeline
• Automated dependency update tooling , Dependabot or Renovate
• Lock file change visibility in code review

A vendor who confirms dependency management should be asked about lock file enforcement. Dependency specifications define what versions are acceptable. Lock files record what versions are actually installed. Production builds using lock files ensure the same software is installed every time.

How to evidence it

• Lock file enforcement verification
• Repository lock file review
• Automated security update implementation
• CI build pin verification

Key Takeaway

Version spec: >=2.0.0. New version published Thursday. Tests passed Thursday. Production deployed different software Friday. No code changed. The resolved dependencies changed. Floating version specifications allow the package manager to resolve newer compatible versions automatically. Lock file enforcement prevents it: the exact versions recorded in the lock file are installed, not resolved fresh on each build. The supply chain attacker who publishes a malicious version satisfying a floating spec reaches every build that runs after publication. Lock file enforcement requires deliberate developer action to update the pinned versions, converting an automatic attack vector into a deliberate update workflow.

More on Third-party oversight

• Build Pipeline Integrity
• Vendor Patch Cadence Reality
• Artifact Registry Security