Notify customers when an SBOM change affects their risk or their records: a new release they are running, a correction to an earlier file, or a component that now carries a serious issue. Do not notify for formatting changes. A short, consistent message with a changelog entry is enough.
The balance
Too few notices and customers work from stale data. Too many and they stop reading. The goal is a signal worth acting on.
An SBOM can change for many reasons. Some matter to a customer, such as a library replaced after a vulnerability. Some do not, such as a field reordered by a tool update.
A notification rule
| Change | Notify? | Message focus |
|---|---|---|
| New product release the customer is entitled to | Yes | New SBOM attached or available, what changed |
| Correction to a previously shared SBOM | Yes | What was wrong, which revision replaces it |
| Component with a serious new vulnerability, and it is reachable | Yes, through your vulnerability process | Impact, fix, timeline |
| Component updated for routine reasons | Optional, in a periodic digest | Changelog link |
| Formatting or tooling change only | No | None |
Be honest about corrections. If an earlier file missed components, a customer who ran analysis on it deserves to know. See correcting a mistake in a shared SBOM revision policy.
Choose the channel
- Security advisories for urgent items, using the contact the customer gave you.
- A periodic digest, for example monthly, listing SBOM revisions since last time.
- A changelog page or portal feed that customers can watch without receiving email.
Ask customers which they prefer. Some want email, others want an API or a feed.
What a good notice contains
- Product and version affected.
- SBOM revision number and date. See version numbers for shared SBOMs.
- One sentence on what changed and why.
- Whether the customer needs to act, and if so what.
- Where to get the new file and how to verify it. See verify a shared SBOM was not altered.
- A contact for questions.
Keep it under 150 words. Put detail in the changelog.
Avoid creating an obligation you cannot meet
If you promise to notify on every change, you must be able to detect every change. Automated generation on each release helps. Check how often you really regenerate, and promise accordingly. See how often to refresh an SBOM you share with customers.
Also decide who in the customer's organisation receives notices. A departed employee's address will quietly absorb your messages. Ask customers to confirm contacts annually.
Try it yourself
Continuous monitoring watches components for new issues as they appear. This demo shows how a change in the vulnerability picture can trigger a notice even when the code has not changed.
Click through it at your own pace, or open it full screen.
Safeguard's SBOM and dependency scanning and continuous monitoring support detecting changes in what you ship. Try a free scan to see an inventory.
Quick check
Do customers expect a notice for every release?
Not usually. They expect notices that change their risk. A digest or feed covers routine releases.
Who should send the notice?
The security or product security contact, using a consistent sender address, so customers recognise and trust it.
Last reviewed: 19 October 2026.
