Tell the customer in plain words what changed, why it changed, which SBOM version replaces which, and whether any earlier conclusion needs a second look. A correction handled openly builds trust. A file that silently replaces another does the opposite.
Why revisions happen
CISA's 2026 minimum elements say that when a component producer or SBOM author discovers new details about the underlying components, or corrects an error in existing SBOM data, they should issue a revised SBOM. The same text says SBOM authors should correct errors promptly, and that organizations should accommodate updates, including corrections.
The SBOM version element exists for this purpose. It identifies a change in the SBOM document from a previously identified version. The text says the SBOM version should be updated when editing data about the target component, and that each version of an SBOM carries a new timestamp.
What to put in the revision note
Keep it to four short parts.
- What replaced what. "Version 1.1 of the SBOM for Product X 4.2 replaces version 1.0."
- What changed. Name the components or fields. "Two components were added. Hash values were added for eleven components." Only give counts you have checked.
- Why. "The first file was generated before build and missed libraries added during build."
- What it means. "If you scanned version 1.0, please rescan. We have reviewed the added components and will send a status for any finding."
A simple versioning habit
The CISA text says that if an author uses semantic versioning, the major version of a published SBOM following these minimum elements should be 1, with minor and patch versions used to indicate changes to content as appropriate. You do not have to use semantic versioning. You do need a clear order so a customer can tell which file is newer.
| Change | Example version step |
|---|---|
| First release of the file | 1.0 |
| Added missing component data | 1.1 |
| Typo in a field | 1.0.1 |
The table shows one reasonable use of the scheme. The text does not prescribe these meanings, so write down your own rule and apply it consistently.
Re-open earlier conclusions
A correction can change an earlier answer. If you told a customer a library was not present and the revision adds it, say so first and give a status. If you sent VEX statements based on the old file, review them. The CISA VEX document says an under investigation status is expected to change once an investigation concludes, which is a good model for how to handle a corrected finding: say what you are checking and when you will report back.
Tone
Do not apologise at length and do not minimise. State the fact, the fix and the next step. The NTIA report asked consumers to welcome corrections without penalty when offered in good faith, while noting this tolerance does not apply to intentional obfuscation or willful ignorance. A prompt, clear correction fits the first category.
Keep the old file
Retain the original. The customer may have acted on it and you may need to show what you sent. Store both with their hashes. See correcting a mistake in a shared SBOM.
Try it yourself
Open the demo and note the component versions listed. A revised SBOM changes entries like these, so look at what you would point to in a revision note.
Click through it at your own pace, or open it full screen.
Quick check
Should the revised file overwrite the old one at the same link?
Avoid it. Give the new file its own version and keep the old one retrievable.
Do we have to tell customers who did not ask?
If they received the file and the error matters to their risk decisions, yes. Use your request log to find them.
Safeguard's SBOM and dependency scanning can help engineering regenerate and compare inventories, and the free scan is a way to try it.
Sources
- 2026 Minimum Elements for a Software Bill of Materials (SBOM), CISA and partners, 29 July 2026
- The Minimum Elements For a Software Bill of Materials (NTIA, 2021)
- Minimum Requirements for Vulnerability Exploitability eXchange (VEX), CISA, April 2023
Last reviewed: 19 October 2026.
