A platform should treat manual edits to an SBOM as annotations or new revisions that record who changed what, why and when, while keeping the original intact. Silent overwrites make an SBOM untrustworthy, because a reader cannot tell what the generator said from what a person decided.
Why people edit SBOMs
Generators make mistakes. A license is wrong, a supplier is missing, a component is a false match, or a version is unknown. Teams fix these by hand. That is reasonable. The problem is when the fix replaces the original data without trace. NTIA lists accommodation of mistakes as a practice, which supports correcting errors openly, not hiding them.
Annotation or revision
| Approach | Use for | Effect |
|---|---|---|
| Annotation | A note or override on one component, such as a license decision | Original value stays visible, note sits beside it |
| Revision | A correction that changes the SBOM as issued | New version, old one marked superseded |
| Regeneration | The generator was wrong or misconfigured | Fix the source, produce a new SBOM |
Prefer regeneration when the cause is repeatable. If a generator keeps mislabelling a library, correcting by hand each release is busywork. Fix the configuration and rerun. Compare outputs as described in comparing SBOM output after a scanner switch.
A policy you can adopt
- Never edit the original file. Keep it as received or generated.
- Every override has four parts: the field, the old value, the new value, the reason.
- Reasons need evidence. A link to the license text, the lockfile or the upstream project page.
- A second person approves overrides on license or supplier fields that appear in customer exports.
- Overrides carry the editor's name and a timestamp.
- Overrides expire or are re-checked when the component version changes.
- Exports state the difference. If an export includes overridden values, mark the file as edited, with the tool and author fields reflecting that.
The NTIA field author of SBOM data matters here. If a person edited the file, the author should not claim it came untouched from a generator. For correction notices to recipients, see correcting a mistake in a shared SBOM.
What to avoid
- Free text comments as the only record. They cannot be searched or exported reliably.
- Bulk find and replace on licenses or suppliers without review.
- Editing in a sheet and re-importing. The platform then sees new data with no history.
- Letting administrators delete overrides without a log entry.
Check it in a trial
- Override a license on one component.
- Look at the component view: can you see both values and the reason?
- Export the SBOM: is the override identifiable?
- Check the audit log for the action.
- Upgrade the component version: does the override flag for review?
The questions to ask about logs are in what an SBOM platform audit log should record.
Where Safeguard fits
Safeguard produces SBOM and dependency inventories from scans, and its compliance evidence automation is designed around keeping dated records. Regenerating from source with the free scan at gold.safeguard.sh/scan is often the cleanest way to correct an input.
Quick check
Is it acceptable to edit a supplier's SBOM?
Do not change their file. Record your own annotations next to it and ask the supplier for a corrected revision.
Should edited SBOMs be labelled?
Yes. A recipient should be able to tell which values were changed by a person.
Sources
Last reviewed: 19 October 2026.
