Yes. A lockfile change is the moment new versions, including transitive ones nobody asked for by name, become part of your build. Treat every lockfile diff in a pull request as an intake event, and run your approval rules against the added and changed entries, not just the manifest.
Why the manifest alone is not enough
The manifest says what a developer asked for. The lockfile says what the build will actually fetch. One added line in package.json can bring dozens of new packages into package-lock.json, and those are the ones that nobody reviewed by name.
The npm documentation for the clean install command makes the lockfile's role plain: the project must have an existing lockfile, and if the dependencies in the lock do not match package.json, the command exits with an error instead of updating the lock. That makes the lockfile the authoritative record in CI, which is exactly why it deserves review.
What to look at in a lockfile diff
- Added entries. Each one is a new package that needs to pass the approval rules.
- Changed versions. Which are patch bumps, and which are major jumps?
- Changed resolved URLs. A package that moved to a different host or registry is a red flag.
- Changed integrity values with no version change. The same version with a different hash deserves a hard stop and a question.
- Removed entries. Usually fine, but confirm the removal matches the manifest change.
Make the review mostly automatic
Reading lockfiles by eye does not scale, so let tooling do the first pass.
- Parse the diff into a list of added, changed and removed packages.
- Run each addition through the same checks as a manual request: approved list, license, advisories, install scripts.
- Fail the check if a resolved URL points outside your mirror.
- Post a short summary in the pull request: "4 added, 2 changed, 0 off-mirror".
A human then reads the summary and the flagged items only.
Rules that catch real problems
| Lockfile signal | Suggested action |
|---|---|
| New package not on the approved list | Route to intake review |
| Resolved host is not your mirror | Block the merge |
| Integrity hash changed, version unchanged | Block and investigate |
| Large number of new transitive packages | Require a reviewer to look |
| Lockfile changed without a manifest change | Ask why, often an unplanned update |
The last row is easy to miss. A lockfile that changes alone often means someone ran a broad update, and that is a larger intake event than it looks.
Try it yourself
Click through it at your own pace, or open it full screen.
Click into a dependency and look at how direct and transitive packages are separated, since that is the split a lockfile review needs.
Where Safeguard fits
Safeguard's SBOM and dependency scanning read your lockfiles and show direct and transitive packages, and its gates can apply policy to a pull request. The free scan gives a quick view of one repository.
Quick check
Do I need to review lockfiles for every language?
Yes in principle. The file names differ, but the idea is the same: the resolved set is what ships.
What if the lockfile is generated in CI?
Then the intake check should run on the generated result, before it is used for the release build.
Sources
Last reviewed: 19 October 2026.
