Diff against the baseline that matches your question. Use the last released SBOM to see what customers will newly receive, the main branch SBOM to review what a pull request adds, and the deployed SBOM to find what runs differently from what you built. One baseline cannot answer all three.
Why the choice matters
An SBOM diff only tells you what changed relative to something. If the baseline is wrong, the diff is either overwhelming or misleading. A release candidate compared with a build from six months ago shows hundreds of version bumps, most of them already reviewed. A pull request compared with the last release mixes this change with everything merged since.
The three baselines
| Question | Baseline | Who reads it |
|---|---|---|
| What does this pull request add? | SBOM of the target branch tip | Code reviewer |
| What is new for customers in this release? | SBOM of the last tagged release | Release owner, security reviewer |
| Does production match what we built? | SBOM recorded at deploy time for that version | Platform or operations team |
Steps to set them up
- Store an SBOM for every build and tag release builds distinctly. Name the file with the version or commit.
- On pull requests, generate the SBOM for the branch and fetch the one for the target branch tip. Diff them.
- On release candidates, fetch the SBOM attached to the previous release tag. Diff it and attach the output to the release record.
- For production, record which SBOM belongs to each deployed version, then compare the running inventory against it on a schedule.
Edge cases
Hotfixes branch from a release, so diff them against that release, not against main. Long lived release branches need their own baseline per branch. If a release was skipped or withdrawn, diff against the last one that actually shipped.
If the project has several deployable services, give each its own baseline. A merged company wide SBOM diffs poorly against a single service file, so compare like with like.
Keep baselines trustworthy
A baseline is only useful if it was produced the same way as the new file. Record the generator version and settings beside each SBOM. If you change tools, regenerate the baseline once from the old source with the new tool, then carry on. Otherwise the first diff after a switch reports the tool change as a software change.
GitHub's dependency review shows added, removed and updated dependencies on a pull request, including indirect ones for lock files, which is the first baseline in the table. Release and production comparisons you generally build yourself or get from your SBOM platform.
Safeguard stores SBOMs and scans dependencies, so a release can be compared with the one before it. The free scan at gold.safeguard.sh/scan is a quick way to see a single project's inventory first.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how a change is flagged relative to an earlier state. That earlier state is the baseline.
Quick check
Is one baseline enough?
Usually not. Pull request review, release review and production comparison each answer a different question.
What baseline should a hotfix use?
The release it branched from, because that is what customers already have.
Sources
Last reviewed: 19 October 2026.
