Read a lockfile-only pull request by checking four things in the diff: only the named package and its expected children changed, every resolved source is your usual registry, integrity hashes are present, and no new package gained an install script. It takes a few minutes once you know the fields.
Why lockfiles deserve a real look
A lockfile is the exact list of what your project installs. The npm documentation says it describes the exact tree generated so that later installs produce identical trees, and that it is meant to be committed so changes are visible in readable source control diffs. That visibility only helps if someone reads the diff.
The examples below use npm's package-lock.json because npm documents its fields clearly. Other ecosystems keep similar data in different places.
The checklist
- Count the changed packages. The title names one package. The diff should show that package and, at most, a few transitive ones that the update needs. A dozen unrelated packages moving is a question for the author.
- Check the resolved field. Per npm's documentation,
resolvedis where the package was fetched from. For registry packages it is a tarball URL, and the registry's own address is a magic value meaning the currently configured registry. A URL pointing somewhere unexpected is a red flag. - Check for git or link sources. For git dependencies,
resolvedholds a full git URL with a commit hash, and for link dependencies it holds a path. A bot security update that suddenly points at a git URL needs an explanation. - Check the integrity field. Each entry should carry an
integrityvalue, a sha512 or sha1 hash of the unpacked artifact. A missing hash on a changed entry is worth a question. - Look for install scripts. The
hasInstallScriptflag marks packages with a preinstall, install, or postinstall script. A newly flagged package runs code on every machine that installs it. Treat it with care. - Compare with the manifest. If the lockfile changed but the manifest range did not move, confirm that is what you expect. Security updates sometimes change only the lockfile.
A quick way to see it
git diff --stat origin/main...HEAD
git diff origin/main...HEAD -- package-lock.json | grep -E '^[+-].*("resolved"|"hasInstallScript")'
The first command shows how many files changed. The second prints only the lines that matter for sources and install scripts. Adjust the file name for your ecosystem.
Then check the package itself
Open the registry page for the new version. Confirm the publisher is the one you expect and that the release date makes sense. If a release is hours old and your update is not urgent, waiting a few days costs little. GitHub's Dependabot options include a cooldown setting that delays version updates, with a default of 3 days that does not apply to security updates.
Where Safeguard fits
Safeguard's SBOM and dependency scanning list the components in a project and their known vulnerabilities, which gives you a second view of what a lockfile change adds. Start with the free scan at https://gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Notice how direct and transitive packages are listed together.
Quick check
Do I need to read every line of a big lockfile diff?
No. Filter for the fields above and read the packages that changed or gained scripts.
Is a matching integrity hash proof the package is safe?
No. It proves you got the same bytes the lockfile recorded. It says nothing about whether those bytes are trustworthy.
Sources
Last reviewed: 19 October 2026.
