Yes. An SBOM diff supplies the dependency section of release notes: what was added, removed and updated, and which known vulnerabilities each change cleared. Generate it from the two release SBOMs, edit for readers, and keep a machine readable copy alongside the prose.
Why bother
Customers and auditors increasingly ask what changed in the components you ship. Engineers also need the history when something breaks later. Writing it by hand after the fact is error prone. A diff produced by a tool during the release is accurate and takes minutes.
Steps
- Generate SBOMs for the previous and the new release the same way.
- Run the diff with version level reporting. The CycloneDX command line tool supports a component versions option that reports versions added, removed or modified, with text or JSON output.
- Convert the output into three lists: added, removed, updated.
- For each updated component, note whether the update fixed a published advisory.
- Keep the JSON beside the release as the full record.
A template
| Section | Content |
|---|---|
| Added | Component, version, reason for adding |
| Removed | Component, version, reason for removal |
| Updated | Component, old version to new version, advisory fixed if any |
| Unchanged risk | Known issues you accepted, with reason and expiry |
| Notes | Base image change, build tool change, generator version |
A short human sentence per direct dependency is worth more than a long raw list. Transitive changes can be summarised as a count with the full list attached.
What to leave out or handle carefully
Do not publish internal package names or private repository paths. Check the SBOM for fields that reveal internal details before copying anything into public notes. Do not claim a vulnerability is fixed unless the new scan confirms it. Do not describe a release as secure. State what changed.
If you are not sure a removed component is really gone, say so or verify first. Mistakes in release notes are easy to find later and hard to retract.
Audience versions
An engineering note can list every package URL. A customer note should summarise: how many components changed, the notable updates, any advisories addressed. A regulated customer may want the attached SBOM and diff as files. Produce the full version once and derive the others.
Make it routine
Add the diff step to the release pipeline and fail the pipeline if it cannot run, so a release never goes out without its record. Store notes and diffs under the version number so they can be found in a year.
Safeguard generates and stores SBOMs and scans dependencies, which provides the inputs for this kind of record. A quick look at a project is available on the free scan.
Quick check
Should release notes list every transitive change?
Summarise with a count and attach the full list. Direct dependencies deserve a sentence each.
Can I publish the raw diff?
Check it for internal names or paths first, then publish if it is clean.
Sources
Last reviewed: 19 October 2026.
