Cybersecurity glossary
What is a Lockfile?
Learn what a lockfile is, how it records exact dependency versions, sources, and integrity hashes, and why committed lockfiles improve supply-chain security.
Definition
A lockfile is a package-manager-generated file that records the exact resolved dependency graph, including versions and often integrity hashes, so installs can be reproduced consistently.
Why lockfiles matter
A dependency manifest can say "use a compatible version," but package ecosystems often define compatibility as a range. Without a lockfile, two installs from the same commit can produce different transitive dependency trees.
Lockfiles make dependency resolution explicit and reviewable. They are essential for reproducible installs, accurate vulnerability scanning, and understanding what changed when an upgrade pull request lands.
What a lockfile records
Exact versions
Resolved package versions for direct and transitive dependencies.
Source locations
Registry URLs, package tarballs, git references, or workspace links.
Integrity hashes
Checksums that help detect tampered downloads where ecosystems support them.
Graph relationships
Which packages depend on which nested packages and under what constraints.
How lockfiles stabilize installs
Manifest declares ranges
Developers add dependencies using package-manager rules such as exact versions or compatible ranges.
Resolver chooses versions
The package manager selects a full graph that satisfies direct and transitive constraints.
Lockfile captures the graph
Resolved versions, sources, and hashes are written to a lockfile.
CI installs from the lock
Builds use frozen-install modes so unexpected lockfile changes fail instead of drifting silently.
Updates become visible
Dependency update PRs show exactly which graph entries changed and why reviewers should care.
Lockfile versus related controls
| Concept | Role | Security note |
|---|---|---|
| Lockfile | Records exact resolved dependency graph | Prevents silent graph drift but can preserve vulnerable versions |
| Dependency pinning | Constrains versions, sources, or digests | A policy choice often implemented through lockfiles |
| Integrity hash | Verifies downloaded package bytes | Helps detect tampering for the recorded artifact |
| SBOM | Shares component inventory beyond the repo | Useful for post-release monitoring and customer assurance |
Lockfile checklist
- Commit lockfiles for deployable applications, services, and container builds.
- Use frozen or immutable install modes in CI.
- Fail builds if installation mutates the lockfile unexpectedly.
- Scan lockfiles, not only package manifests, for vulnerable transitive dependencies.
- Review lockfile diffs for unexpected registries, git URLs, and package additions.
- Prefer package managers that record integrity hashes and verify them during install.
- Refresh lockfiles through controlled update pull requests with tests.
- Treat large unexplained lockfile rewrites as supply-chain review events.
The practical takeaway
Lockfile data turns dependency resolution from an invisible network event into a versioned artifact. That makes builds more repeatable and makes dependency risk easier to scan and review.
Lockfiles are not a substitute for updating vulnerable packages. They give you a stable map; you still need a process for moving that map when security advisories arrive.
Related security terms
Dependency Pinning
The broader practice of constraining dependencies to exact versions and sources.
Dependency Scanning
Scanners rely on lockfiles to know which versions are actually installed.
Reproducible Build
Lockfiles are one input needed for deterministic build behavior.
Software Bill of Materials (SBOM)
An SBOM often derives component inventory from resolved dependency data.
Software Supply Chain Attack
Unexpected dependency resolution is a common entry point for supply-chain compromise.
Frequently asked questions
What is a lockfile in simple terms?
A lockfile is the receipt for dependency resolution. It records exactly which package versions were chosen so future installs choose the same ones.
Is a lockfile the same as dependency pinning?
No. Pinning is the intent to constrain versions. A lockfile is a common mechanism that captures the full resolved graph, including transitive dependencies.
Should lockfiles be committed?
Applications and services should usually commit lockfiles so CI and production builds install the same dependency graph. Published libraries may follow ecosystem-specific conventions.
Why do lockfiles include transitive dependencies?
Most installed packages are indirect. Recording transitive versions prevents nested packages from floating to unexpected versions between builds.
Do lockfiles improve security?
Yes, by reducing surprise dependency drift and enabling accurate scanning. They do not guarantee a dependency is safe, so scanning and update discipline still matter.
Can a lockfile become dangerous?
Yes. A stale lockfile can preserve vulnerable versions, and a malicious lockfile change can redirect packages or hashes if review is weak.
What should reviewers inspect in lockfile changes?
Review unexpected new packages, source URLs, integrity hashes, maintainer-sensitive upgrades, major version jumps, and large transitive graph changes.
References
Explore authoritative guidance and frameworks related to lockfile.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.