Lockfile analysis is the usual balance for most teams, because it records the exact versions installed. Manifest-only reading is fast but guesses at versions. Build-time observation is the most accurate for what ships, but needs more setup. Many tools combine them, so ask which one they use for your stack.
Manifest scanning
A manifest, such as a file listing the packages your project asks for, usually states version ranges rather than exact versions. A tool that reads only manifests has to guess which version you resolved.
Strengths: it needs no build, runs quickly and works on any repository. Weaknesses: it may report versions you do not use, miss transitive dependencies, and miss anything added by scripts. It fits a first quick look, not an evidence trail.
Lockfile scanning
A lockfile records the exact versions chosen, including transitive ones. Reading it gives a precise inventory of what a fresh install would produce.
Strengths: accurate versions, full dependency tree, no build needed, easy to run in CI. Weaknesses: it depends on the lockfile being committed and current. Libraries and some ecosystems often do not commit one. The lockfile also describes what would be installed, which may differ from what was shipped if the build changes things.
Build-time analysis
Here the tool observes the real build or the final artifact, such as an image or compiled output, and reports what is actually inside.
Strengths: closest to ground truth, catches vendored code, system packages and anything pulled at build time. Weaknesses: needs integration with the build, takes longer, and results depend on the build environment. Mapping a binary back to package identifiers can also be imperfect.
How to decide
Match the approach to your question:
- Want a fast, broad first view of many repositories: lockfile, with manifest as a fallback
- Need to know exactly what is in a released artifact: build-time or artifact scanning
- Ship libraries without lockfiles: manifest plus build-time resolution in CI
- Need audit evidence: lockfile or build-time, because versions are exact
Many teams run lockfile scanning on every pull request and artifact scanning on release. The two together catch most cases and cost little extra.
What to test in a trial
Pick a repository whose lockfile you know differs from its manifest ranges. Check the version the tool reports against what is actually installed. Remove the lockfile and see whether the tool warns, falls back or silently reports nothing. Then scan the built image and compare the lists.
Try it yourself
Open the demo and look at how the inventory shows version and depth for each package. Compare that detail with what a manifest alone could tell you.
Click through it at your own pace, or open it full screen.
Where Safeguard fits: Safeguard offers SBOM and dependency scanning, and the free scan at gold.safeguard.sh/scan is a quick way to see how your own repository is inventoried.
Quick check
Should libraries commit lockfiles?
Conventions vary by ecosystem. Either way, test your library in CI against fresh resolution and scan that result.
Last reviewed: 19 October 2026.
