The problem: A new firmware release is ready. You need to explain to a customer or an auditor what changed in the software inventory, without reading two thousand-line JSON files.
The method
- Pick the baseline: the last shipped build for that product, not the last SBOM file someone uploaded.
- Make sure both documents use a supported format and version. CycloneDX 1.5 against CycloneDX 1.6 is fine; CycloneDX against SPDX is only partially comparable.
- Compare component identity and version, not file paths or array order.
- Read the result in three buckets: added, removed, updated. Treat “unchanged” as a coverage check, not as reassurance.
- Record the review decision with the release, so the next person does not repeat it.
How to read the result
| Change | What it usually means | What to review |
|---|---|---|
| Added | A new dependency or a newly discovered component | Identity quality, licence, whether it belongs in the release at all |
| Removed | A dependency dropped or declarations lost | Distinguish a real removal from under-declaration |
| Updated | Same identity, different exact version | The advisory state of the new version and whether the change was intended |
| Unchanged | Same identity and exact version in both documents | Coverage: a component that should have changed but did not |
Treat a large removal count as a data-quality signal before treating it as good news. An SBOM that loses 300 components between releases has usually lost declarations, not dependencies.
Identity is the hard part
Matching is only as good as the identifiers. Two builds of the same library with and without a namespace produce two identities, which the diff reports as one removal and one addition. That is honest behaviour, but it will confuse a reader who expects an update.
- Require a purl on both sides before you trust a component-level diff.
- For components with only a name, the comparison falls back to the declared name and version, and flags the weaker identity.
- Duplicated identity-plus-version occurrences are collapsed into one comparison row; the count of collapsed duplicates is reported separately.
- Keep the SBOM tool and version stable across releases so identity rules do not change between the two documents.
Wire it into the release
Run the comparison as part of the release checklist, next to the risk review. Export the result with the release record so the change list survives the email thread it was discussed in.
release: HG-100 firmware 1.4.3
baseline: HG-100 firmware 1.4.2
added: 2 removed: 2 updated: 4
reviewed-by: [email protected]
decision: ship / hold
notes: libcurl updated 8.4.0 -> 8.5.0 (advisory review attached)What a diff does not prove
- It does not tell you whether a changed component is exploitable on your device.
- It does not verify that the firmware image matches the SBOM.
- It does not prove the release was authorised or signed.
- It does not detect components that were never declared in either document.
Scope and limits
- Comparison is limited to declared components and their identifiers.
- No vulnerability, exploitability or authorisation conclusion is derived from a diff.