An SBOM platform audit log should record every import, edit, status change, approval, export, role change and sign in, with who did it, what changed, when, and from where. It should be tamper evident, searchable and exportable. A spreadsheet's cell history covers only part of this.
Why the log matters for SBOMs
SBOMs are used as evidence: to customers, to regulators and in due diligence. Evidence is only as good as its history. If a status flipped from affected to not affected, someone will eventually ask who decided and on what basis. NTIA lists accommodation of mistakes as a practice, which implies that corrections should be visible instead of silent.
Events to capture
| Event | Fields to record |
|---|---|
| SBOM imported | Uploader, source, file hash, format and version, product, release |
| Import rejected or warned | Reason, validator output |
| Component edited or annotated | Old value, new value, reason, editor |
| Vulnerability status changed | Old and new status, justification, approver |
| Revision created or superseded | Link between revisions, reason |
| Export or share | Who, what file, recipient or link, expiry |
| Access change | Role granted or removed, by whom |
| Sign in and failed sign in | User, time, source address |
| Integration or token created | Owner, scope, expiry |
| Retention or delete action | What, by whom, under which policy |
The common fields on every event: actor, timestamp with time zone, action, object, and result.
Qualities of a log you can rely on
- Append only. Entries cannot be edited by normal users or administrators.
- Complete. The API and the user interface write to the same log.
- Searchable. You can filter by user, product and date.
- Exportable. An assessor can receive it in a readable form.
- Retained. The log lives at least as long as the records it describes. See audit evidence retention.
- Time synchronised. Entries use a reliable clock so sequences make sense.
Related background is in audit log vs audit trail vs evidence.
What a spreadsheet gives you
Most sheet tools keep a version history showing that cells changed and who changed them. They typically do not capture exports of the data, downloads, or reasons for change, and history may be trimmed over time. Treat a change log tab as a manual supplement and accept that it relies on people remembering to write in it.
Test it in a trial
- Import a file, edit one component, change one status, export the SBOM.
- Open the log and find all four actions.
- Check each entry for actor, time, old and new values.
- Try to alter or delete an entry as an administrator.
- Export the log and open it outside the tool.
If any step fails, note it in your evaluation. A log that misses exports is a particularly common gap, and exports are the actions with outside consequences.
Privacy note
Logs hold names and addresses, so apply your own data protection rules to them. Keep only what you need and decide who may read the log.
Where Safeguard fits
Safeguard's compliance and evidence automation is built around producing records you can show an assessor, on top of SBOM and dependency scanning. Verify audit log specifics in a trial and try the free scan at gold.safeguard.sh/scan first.
Quick check
Is a version history the same as an audit log?
No. Version history shows content changes. An audit log also records access, exports, role changes and rejected actions.
Should the log record SBOM contents?
Record metadata and a file hash, not a full copy. Store the file in the SBOM record and link to it.
Sources
Last reviewed: 19 October 2026.
