Keep one SBOM per image digest internally, because that is the unit that actually runs, and give customers a release level view that lists the digests and the SBOMs behind them. Customers think in releases. Your build system thinks in digests. Bridge the two with a manifest.
Why the digest is the true unit
A digest identifies exact content. A tag like latest or 2.4 can point to different images over time. An SBOM tied to a tag is ambiguous, because by the time someone reads it, the tag may have moved. An SBOM tied to a digest stays correct.
Internally this matters for incidents. When an advisory lands, you need to know which running digests contain the component, and you cannot answer from a tag.
Why customers want releases
A customer's questions are framed by the version they installed: "Is release 3.2 affected?" They do not want to learn your build topology. A release usually contains several images, such as an API, a worker and a web front end, and they want one answer.
| Reader | Natural unit | What to give them |
|---|---|---|
| Your security team | Image digest | SBOM per digest |
| Your incident responders | Running digest | Search across digests |
| A customer | Release | Release manifest plus linked SBOMs |
| An auditor | Release and date | Manifest, SBOMs, build records |
A release manifest
A manifest is a small file that ties a release to its images. It can list the release name and date, each image name and digest, and a link or file name for each image's SBOM. Add the build pipeline run for traceability.
Customers can read the manifest, and your own tools can walk from release to digest to SBOM.
Practical choices
- Generate and store SBOMs per digest at build time.
- Create the manifest as the final step of the release pipeline.
- Decide what customers receive: the manifest alone, or manifest and SBOMs. Share under whatever terms your agreements require.
- When you rebuild an image for a patch, issue a new manifest version, not a silent change. A revised release should say what was revised.
- Keep old manifests. Customers on older versions will ask.
Handling multi architecture images
A multi architecture image may have different contents per platform. Decide whether your SBOM covers each platform separately, and state which one you are sharing, so a reader does not assume the wrong one.
What to avoid
Do not hand customers a bundle of unlabelled files named by date. Do not merge SBOMs from several images into one list without saying which package came from which image, because you lose the ability to act on it.
Where Safeguard fits
Safeguard produces an SBOM for each container image and keeps the records searchable, so building a release manifest from per digest records is a lookup, not a hunt. You can try the free scan at https://gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Look at the component level detail that would sit behind each image in a release manifest.
Quick check
Do customers need our internal build stage details?
Usually not. They need to know what is in what you shipped. Keep deeper build detail for your own records and audits.
How often should the customer SBOM change?
When the release changes, which includes patch rebuilds. Say so in a new manifest version.
Last reviewed: 19 October 2026.
