A good dependency scanner reads lockfiles, because a lockfile records the exact versions installed, while a manifest only records allowed ranges. To test this in a proof of concept, scan a repo twice, once with the lockfile and once without, and compare the version numbers the scanner reports.
Manifest versus lockfile
A manifest, such as package.json, lists what you asked for, often as a range. A lockfile lists what you actually got. npm's documentation describes package-lock.json as describing the exact tree that was generated, so later installs produce identical trees regardless of intermediate dependency updates, and says the file is intended to be committed to source repositories.
Why this matters for scanning: a vulnerability is tied to a version range. If the scanner guesses your version from a range, it may flag a fixed version or miss a vulnerable one.
The five step test
- Pick a repo with a committed lockfile.
- Run the scanner normally and export the package list with versions.
- Run your real install command and list installed packages. For npm in automation, npm ci installs from the lockfile and, per the docs, exits with an error if the lockfile and package.json disagree.
- Diff the two lists by name and version.
- Remove the lockfile in a throwaway branch, scan again, and note how the output changes.
Step five is the telling one. If results barely change, the scanner may be resolving versions itself. If they change a lot, you now know how much the lockfile matters for that tool, and you know which repos without lockfiles are at risk of poor results.
What to record
| Check | Pass | Fail |
|---|---|---|
| Versions match installed versions | Differences explained | Unexplained mismatches |
| Lockfile formats you use are supported | All main formats | A main format ignored |
| Behavior without a lockfile is documented | Clear warning or fallback | Silent guessing |
| Dev dependencies labeled | Visible in output | Mixed in unlabeled |
Repos with no lockfile
Some repos genuinely have none, especially libraries and older projects. Ask the scanner to say so. A trustworthy tool warns that versions are inferred and lowers its confidence. Silent inference is the failure. The fix on your side is usually to commit a lockfile, which also makes builds repeatable.
Other ecosystems
The same idea applies elsewhere. For Python, pip documents pinning with the double equals operator in a requirements file as a way to get repeatable environments, and our post on unpinned requirements covers what that means for scanning. For Java, Maven resolves transitive dependencies from project files, so the scanner needs to resolve the same tree rather than read only the direct list.
Try it yourself
Open the demo and check how each package shows an exact version, then compare that with your own lockfile output.
Click through it at your own pace, or open it full screen.
Quick check
Is a lockfile scan always more accurate?
It is more accurate about versions. It does not tell you whether the vulnerable code is used, which is a separate reachability question.
Do we need to commit lockfiles for a PoC?
If they exist in the repo, yes, leave them. If they are missing, note it as a finding rather than adding them silently.
Sources
- npm docs: package-lock.json
- npm docs: npm ci
- pip docs: Repeatable installs
- Maven: Introduction to the dependency mechanism
Safeguard offers SBOM and dependency scanning with reachability analysis, and you can try a free scan at gold.safeguard.sh/scan before you plan a longer test. The CLI, desktop app and IDE extensions are listed on safeguard.sh/download.
Last reviewed: 19 October 2026.
