A lockfile shows whether a team can rebuild the same software twice. If it is committed, lists exact versions and carries integrity hashes, the team has repeatable installs and reviewable dependency changes. If it is missing, ignored or regenerated on every build, assume nobody knows exactly what ships.
What the file actually records
The npm documentation says package-lock.json describes the exact tree that was generated, so later installs produce identical trees. Each entry records the version, a resolved location, and an integrity hash of the package contents. For git dependencies, the resolved value includes a commit SHA.
That is why the file matters to a reviewer. It is a record of what the build pulled in, with a fingerprint for each item, and changes to it show up in pull request diffs.
Five things to look at
- Is it committed? Check the repository root and each service folder. A lockfile in the gitignore is a flag.
- Is it recent? Compare the last change date with the manifest. A manifest edited weekly and a lockfile untouched for a year suggests builds ignore it.
- Do entries have integrity values? Missing hashes mean the registry could serve different content for the same version without anyone noticing.
- Any git or URL dependencies? These can point at moving targets or personal forks. Look for pinned commit SHAs.
- How are install scripts handled? npm marks packages with install scripts in the lockfile. Ask whether the team reviews them or disables them in CI.
The Python equivalent
Python has no single lockfile, so look at how requirements are pinned. The pip documentation describes hash-checking mode, switched on with the require-hashes option, where every requirement must be pinned and carry a hash. It also lists the cost: the file must be updated whenever dependencies change, and it is easy to miss a transitive dependency. A team using it has made a deliberate trade of effort for assurance.
Reading the result
| Observation | Likely meaning |
|---|---|
| Lockfile committed, hashes present, CI installs from it | Repeatable builds |
| Lockfile committed but CI runs a plain install | Lockfile is decoration |
| No lockfile | Versions float, builds drift |
| Many git dependencies | Review each one by hand |
None of these is proof of a vulnerability. They tell you where to ask follow-up questions, and how much trust to place in the SBOM the team hands you.
Try it yourself
Open the demo and see how an inventory is built from the project's declared packages. Look at how versions and relationships appear once a lockfile is parsed.
Click through it at your own pace, or open it full screen.
Safeguard's CLI and IDE extensions read lockfiles and manifests as part of SBOM and dependency scanning, and a free scan gives you a view of your own project first.
Quick check
Should a library commit its lockfile?
Practice varies by ecosystem and project type. For an application or service you deploy, commit it. For a library, check the ecosystem guidance.
Does a lockfile protect against a compromised package?
It stops silent version drift and detects changed content through hashes. It does not make a pinned malicious version safe.
Sources
Last reviewed: 19 October 2026.
