Reviewers should read the lockfile diff on pull requests and the SBOM diff on releases. The lockfile shows exactly what a developer asked the package manager for. The SBOM shows what ended up in the built artifact, including parts a lockfile never mentions, such as operating system packages.
What each file captures
A lockfile records resolved versions for one ecosystem. It is written by the package manager when a developer changes dependencies, so it changes only when a person acts.
An SBOM is generated from a source tree, an image or a binary. It can span several ecosystems, container layers and tools, and it is regenerated on every build. Because of that, it can change when nothing in the repository did, for example when a base image updates.
| Aspect | Lockfile diff | SBOM diff |
|---|---|---|
| Covers | One package manager | Whatever the generator found |
| Changes when | A developer edits dependencies | The build output changes |
| Shows OS packages | No | Yes, for image scans |
| Shows licenses and hashes | Rarely | Often, depending on the generator |
| Best moment | Pull request | Release candidate |
When the lockfile is enough
For a pull request that bumps a library, the lockfile diff is short, precise and attributable to a person. Reviewers can ask why a package was added and check the direct versus indirect split. GitHub's dependency review reads these changes and shows added, removed and updated dependencies, including indirect ones from lock files.
When you need the SBOM
Use the SBOM diff when the question is about the shipped artifact. A new base image, a changed build stage, a vendored library or a binary added to the image will not show in any lockfile. Docker notes that BuildKit scans only the final stage of a multi-stage build unless told otherwise, so what the SBOM contains also depends on how it was generated. Know your settings before you trust the comparison.
A practical split
- Pull request: read the lockfile diff and the dependency review result.
- Merge to main: generate and store an SBOM.
- Release candidate: diff the SBOM against the last release and attach the result.
- If the two views disagree, investigate. The gap usually points to something outside the package manager.
A warning about trust
Neither file proves the code is safe. Both describe what is present. They are inputs to review, not verdicts, and a clean diff means only that nothing unexpected moved.
Safeguard scans dependencies and generates SBOMs, so both the project view and the artifact view can be checked in one place. Try your own repository at gold.safeguard.sh/scan.
Quick check
Can a lockfile replace an SBOM?
Not fully. A lockfile covers one ecosystem and omits things like operating system packages in an image.
Why might the SBOM change when the lockfile did not?
The build environment or base image changed, or the generator settings did.
Sources
Last reviewed: 19 October 2026.
