Issue a corrected SBOM, tell everyone who received the old one, keep the old version on record, and note what changed. The NTIA minimum elements report says suppliers should issue a revised SBOM when they learn new details or want to fix an error, and that good faith corrections should be welcomed.
What the guidance says
The NTIA report says a new SBOM must be created whenever a component is updated with a new build or release. It adds that if the supplier learns new details about the underlying components, or wants to correct an error in existing SBOM data, the supplier should issue a new, revised SBOM. In its section on accommodating mistakes, it says consumers should be explicitly tolerant of occasional incidental errors and should welcome supplements and corrections without penalty when offered in good faith. It also says this tolerance does not extend to intentional obfuscation or willful ignorance.
A revision policy in six steps
- Triage the error. Is it a missing component, a wrong version, a wrong supplier, or a format problem? Missing and wrong versions affect customer risk decisions the most.
- Fix at the source. Correct the build configuration or the generator settings, then regenerate. Do not hand edit the output.
- Version the SBOM. Use your format's version and timestamp fields so recipients can tell the new file from the old one. The NTIA minimum elements include a timestamp for exactly this reason.
- Notify recipients. Use your delivery log to find who received the old file, and send them the new file with a short change note.
- Keep the old file. Customers may have made decisions from it. Archive both.
- Review why it happened. If the same class of error can recur, add a check to your pipeline.
What the change note should say
| Item | Example content |
|---|---|
| What changed | Component added, version corrected |
| Why | Generator missed a vendored library |
| Impact | Which known vulnerabilities, if any, are now relevant |
| Action for the customer | Replace the earlier file |
Keep it short and factual. The tone matters. The point is to show a working correction process, which builds more trust than a spotless first attempt.
When the error changes risk
If a correction reveals a vulnerable component that was missing before, follow your vulnerability process too. Send a VEX or advisory status for the newly visible component rather than only a new SBOM file.
Try it yourself
Open the demo and look at how monitoring flags a change in a component set over time. Corrections are one cause of such changes.
Click through it at your own pace, or open it full screen.
Quick check
Will customers hold an honest error against us?
The NTIA guidance asks consumers to be tolerant of incidental errors corrected in good faith. Your contract may differ, so check it.
Should we delete the wrong file?
No. Archive it and mark it superseded so the history stays clear.
Safeguard's continuous monitoring and SBOM and dependency scanning can help you notice component changes sooner, and the free scan is a way to start.
Sources
Last reviewed: 19 October 2026.
