If you ship a container image or installer that a customer runs, include an evidence bundle with each release: an SBOM, a vulnerability scan summary, the image digest or file checksum, a way to verify the source, and your update and support policy. Customers inside enterprises will not deploy without them.
Why this changes the review
A pure SaaS buyer trusts your hosting. A customer who runs your code in their network trusts your artifact. Their security team will scan it, often before the first test install. If they find hundreds of issues and no explanation, the pilot stalls.
An evidence bundle gets ahead of that.
What to put in the bundle
| Item | Purpose |
|---|---|
| SBOM for the release | Lets the customer see components and check advisories |
| Scan summary, with exceptions | Explains what a customer scanner will find |
| Image digest or file checksum | Lets them verify they got the intended artifact |
| Build provenance, if you generate it | Shows how and where it was built |
| Base image statement | Names the base and how often it is refreshed |
| Update and support policy | Says how long versions get fixes and how to report issues |
| Contact for security reports | One address or form |
Make the bundle part of the release process, so it appears automatically.
Scan before they do
Run the same kinds of scans a customer will run, against the final image, not only the source. Container images include operating system packages that your dependency files never mention. Reconcile the results: fix what you can, and for what you cannot, write the reason.
Use a digest rather than a tag when you refer to an image. A tag can move, a digest identifies exact content. See container image digests versus tags.
Verification
Offer a simple way to verify: publish checksums on a page you control and, where you can, sign artifacts or provide provenance. The SLSA specification says that at its first build level provenance exists, showing how a package was built, and that it can prevent mistakes but is easy to forge. Higher levels run builds on hosted platforms that generate and sign provenance. Claim a level only when you can show how you meet it.
Update policy
State plainly:
- How often you release fixes.
- How long a version is supported.
- How customers learn about security fixes.
- How quickly you respond to a vulnerability report.
Do not promise timelines you cannot meet. Customers will hold you to the written policy.
Keep the bundle consistent
Generate everything from one build, so the SBOM, scan and digest describe the same artifact. A scan from last week attached to this week's image will be spotted.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how OS packages and application packages appear together in one report, the view your customer will have.
Safeguard scans container images and generates SBOMs, and you can run a free scan on an image before you ship it.
Quick check
Do we need to sign the image?
It strengthens trust, but a digest, SBOM and clear update policy come first.
Should the bundle go public?
Share with customers or under NDA. Public pages can carry the policy and checksums but not detailed scan results.
Sources
Last reviewed: 19 October 2026.
