Tell customers which release the new SBOM belongs to, what components were added, removed or updated, and whether any known vulnerability was fixed or accepted. Keep it factual and tied to a version. Do not promise the software is secure, and do not hide changes that matter.
Why this communication matters
Customers who receive your SBOM may load it into their own tooling. When a new release arrives with a new file, they need to know how to read the change, and which of their findings should disappear. A short, regular note saves them questions and builds trust over time.
What to include
- Version mapping. Which SBOM goes with which release, with the generation date.
- Summary of changes. Counts of added, removed and updated components, with the notable ones named.
- Security relevant changes. Advisories fixed by updates, and any component that now has an open known issue.
- Accepted risks. Known issues you have assessed and chosen to keep, with the reasoning in plain words.
- Tooling changes. If the generator or format changed, say so, because it explains differences unrelated to the software.
- Contact. Where to send questions and corrections.
Message shape
| Part | Length |
|---|---|
| Opening line: release and SBOM version | One sentence |
| What changed | A short list |
| What it means for existing findings | Two or three sentences |
| What is unchanged | One sentence |
| How to reach you | One line |
Wording to avoid
Avoid "fully secure", "no vulnerabilities" and "complete" unless you can prove each claim. Say "scanned on this date with this tool" instead. A scan result describes a moment and a method. Customers who understand that trust you more than those handed an absolute.
Also avoid silent replacement. If you correct a mistake in an earlier SBOM, issue a new revision with a note on what was wrong. A file that changes under the same version confuses everyone who already stored the old one.
Vulnerability exchange
If a customer's scanner flags a component in your SBOM, a statement on whether the product is actually affected is more useful than a list of versions. A VEX statement is the standard way to say that. Publish them when you have assessed a finding, and link them to the release.
Cadence
Notify on every release that changes the SBOM, and on any out of cycle correction. For customers who want less, offer a digest. Decide this in advance with the account owner, not in the middle of an incident.
Check before sending
Make sure the diff you summarise came from files generated the same way, and confirm no internal names or paths leak. Have one person verify the counts against the tool output.
Safeguard produces SBOMs and scans dependencies, so release summaries can be built from the same data. You can look at a project on the free scan.
Quick check
Do I need to notify customers about every small update?
Notify on every release that changes the SBOM, but offer a short digest for customers who prefer it.
What if I find a mistake in a sent SBOM?
Issue a corrected revision with a note describing the error, rather than replacing the file silently.
Last reviewed: 19 October 2026.
