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.
Expanded Definition
Lockfile drift describes a situation where the dependency graph captured in a lockfile no longer matches the packages, transitive dependencies, or build outputs that are actually present at install time or runtime. In secure software supply chains, the lockfile is meant to freeze resolution so that repeated builds produce the same artifact from the same inputs. When drift appears, that assurance breaks, and teams can no longer treat the lockfile as a faithful record of what was shipped.
This term matters most in CI/CD, container builds, and release pipelines where small changes in package manager behaviour, indirect dependency updates, or non-reproducible build steps can alter what executes. The concept overlaps with dependency pinning, but it is narrower: pinning expresses intent, while lockfile drift is the failure of that intent to hold. Guidance on software supply chain integrity in the NIST Cybersecurity Framework 2.0 supports treating repeatable builds and change control as core trust requirements.
The most common misapplication is assuming a committed lockfile guarantees reproducibility, which occurs when build scripts, registry access, or package-manager flags still allow version re-resolution during installation.
Examples and Use Cases
Implementing lockfile governance rigorously often introduces release friction, requiring organisations to weigh build speed against the cost of stricter determinism and review.
- A Node.js pipeline commits package-lock.json, but a CI job runs
npm installinstead of a frozen install, so indirect dependencies shift between runs. - A Python project records dependencies in
poetry.lock, yet a developer rebuilds the environment with a relaxed resolver and pulls newer transitive packages than the audited set. - A container image is rebuilt from the same source commit, but the package manager re-downloads patched versions because the build step did not enforce immutable resolution.
- A security team compares a software bill of materials against the artifact in production and finds the runtime package set differs from the lockfile, complicating provenance validation.
- An internal platform uses the SLSA model to require repeatable builds, making lockfile drift a release-blocking issue rather than a cosmetic mismatch.
Why It Matters for Security Teams
Lockfile drift weakens confidence in vulnerability triage, incident response, and compliance evidence because the dependency set that was reviewed is not necessarily the dependency set that executed. That gap can hide vulnerable transitive packages, introduce unapproved code paths, or create false assurances about patch status. For AppSec and platform teams, the issue is not only whether a lockfile exists, but whether the pipeline actually honours it across all environments.
This becomes especially important when supply chain controls depend on artifact integrity, provenance, and attestations. A lockfile that drifts can undermine SBOM accuracy, break reproducibility checks, and make it harder to prove that a build corresponds to a reviewed source state. In practice, teams often need to pair locked dependencies with immutable build steps, controlled registries, and verification of the resolved artifact set against policy. The concept also intersects with identity and access management when automated build agents, package registries, and deployment identities can alter resolution behaviour or retrieve different content under the same credentials. Security programs that track software lifecycle controls under the NIST Cybersecurity Framework 2.0 treat this as a trust problem, not just a developer convenience issue.
Organisations typically encounter the operational impact only after a rebuild, incident, or audit reveals that the deployed artifact no longer matches the reviewed dependency record, at which point lockfile drift becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-53 Rev 5, SLSA and NIST AI RMF set the technical controls, while ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.IP-1 | Protective processes cover configuration and change control for reproducible builds. |
| NIST SP 800-53 Rev 5 | CM-3 | Configuration change control fits lockfile governance and build determinism. |
| ISO/IEC 27001:2022 | A.8.29 | Secure coding and system change controls support dependency consistency. |
| SLSA | Build integrity | SLSA directly addresses reproducible, verifiable software builds and provenance. |
| NIST AI RMF | AI systems also rely on dependency integrity for trustworthy model and tool pipelines. |
Apply dependency determinism controls to AI build and deployment pipelines as part of risk management.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 2, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
