Scan both, but base release evidence on the built artifact. A lockfile scan is fast and useful during development, yet it describes what you intended to ship. The artifact scan describes what you actually built, including the base image, system packages and anything the lockfile does not capture.
What each scan sees
| Scan target | Sees | Misses |
|---|---|---|
| Lockfile or manifest | Declared application dependencies and versions | Base image, OS packages, vendored code, build-time additions |
| Source repository | Code and config patterns | Resolved dependency versions if not locked |
| Built artifact or image | Everything in the final package | Context about why a component is there |
A lockfile says "these package versions were resolved." It does not say what else ended up in the container, such as an operating system library pulled in by the base image.
Why the difference matters for release gates
If your gate checks only the lockfile, a vulnerability in the base image reaches production without ever failing a check. If it checks only the artifact, developers find out late. Using both gives early signals and a final authoritative answer.
The idea of a build matching its inputs is also what reproducible builds address. The Reproducible Builds project defines a build as reproducible if given the same source code, build environment and build instructions, any party can recreate bit-by-bit identical copies of all specified artifacts. Not every team reaches that, but moving toward it makes the link between inputs and outputs checkable.
How to use both
- Run a lockfile scan on pull requests for quick feedback.
- Build once, then scan the artifact and generate the SBOM from it.
- Compare the artifact SBOM with the lockfile. Large unexplained differences are worth a look.
- Store the artifact result against the digest as the release evidence.
- Keep the lockfile result as supporting context.
Lockfile hygiene
Commit your lockfile and install from it in CI. Floating version ranges mean two builds of the same commit can differ. Where a build fetches dependencies at build time, record what was fetched.
What to say in an audit
A clear statement helps: "Pull requests are checked against the lockfile. Each release artifact is scanned after build, and that result is stored against the artifact digest and approved at deploy." That describes layered control and names the primary evidence.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how many findings remain once reachability is applied to a long list.
Safeguard provides SBOM and dependency scanning with reachability analysis, and a free scan is at gold.safeguard.sh/scan.
Quick check
Is a lockfile scan enough for compliance?
Rarely for release evidence. It misses what the lockfile does not list. Add an artifact scan.
Do we need reproducible builds?
Not required, but they make it easier to prove an artifact matches its source.
Sources
Last reviewed: 19 October 2026.
