Generate the SBOM in CI at release time and store it with the release artifact. Commit one to Git only when you want reviewers to see dependency changes in pull requests. A committed SBOM goes stale the moment someone changes a dependency without regenerating it.
Three places an SBOM can live
| Location | Strength | Weakness |
|---|---|---|
| Committed to the repository | Visible in review, diffable | Goes stale, adds noise to history |
| Generated in CI per build | Always current for that build | Not visible until the job runs |
| Stored with the release | Matches what shipped, easy to hand over | Needs a store and retention rule |
A decision guide
- Do customers or auditors ask for it? Store it with each release.
- Do reviewers need to see dependency changes? Generate it on pull requests and show the diff, or commit it and fail the build if it is out of date.
- Is it only for your own scanning? Generate and discard, or keep the latest per branch.
- Do you need history for incident response? Keep every release SBOM, since you will want to ask which versions held a component.
Most teams end up with the first and third, and a CI check for the second.
If you do commit one
- Make the file reproducible, with stable ordering and no timestamps if your tool allows it, so diffs show only real changes.
- Add a CI step that regenerates and compares. If different, the build fails with a message to regenerate.
- Keep a short note in the README on how to regenerate.
- Never hand edit it.
If you generate in CI
- Pin the tool version, so output changes come from your code and not the generator.
- Run it in the same environment as the release build.
- Validate the file, then upload it as a build artifact.
- Name it with the product and version.
What to keep out of Git
Do not commit large merged SBOMs for many services into one repository, since they change on every release of any service. Do not commit SBOMs that contain internal package names you would rather not expose if the repository is public.
Try it yourself
Click through it at your own pace, or open it full screen.
Notice where in the pull request flow a check can block a merge. A dependency change check belongs at the same point.
Quick check
How long should I keep release SBOMs?
Keep them at least as long as you support that release, and check any contract or regulation that sets a longer period.
Is a committed SBOM a source of truth?
Only if CI proves it matches the current dependencies. Otherwise it is a snapshot.
Safeguard's policies and gates can check pull requests and SBOM and dependency scanning can run on each build, with a free scan at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
