Firmware SBOM diff between releases: components, CVEs, VEX and change documentation

A firmware SBOM diff compares two component inventories, while binary diffing compares two sets of executable code. The SBOM diff answers "which packages and versions changed"; binary diffing answers "which functions inside this binary changed".

The two methods sit at different depths and serve different readers:

This guide covers the inventory side. When you need to know whether a vendor silently fixed a vulnerability inside a library whose version string did not move, that is the job of firmware diffing and patch analysis. The two meet in one place: an SBOM diff often tells you which component to point the binary diff at.

The SBOM itself has to come from the shipped image, not from a design document. How to build one from a binary, including when the ODM supplies no source, is covered in the firmware SBOM pillar guide.

Regulators and customers ask what changed, and the SBOM pair is the only record that answers at component level. Release notes written by hand drift from what actually shipped; a diff of two SBOMs taken from the release images does not.

The NTIA minimum elements report sets the starting point under "Frequency": "If the software component is updated with a new build or release, a new SBOM must be created to reflect the new version of the software." Once you have one SBOM per release, the diff is the cheapest way to read them.

The Cyber Resilience Act adds several duties that a diff feeds directly. Annex I, Part II, point 1 requires manufacturers to identify and document components "including by drawing up a software bill of materials". Article 31(2) says the technical documentation "shall be continuously updated, where appropriate, at least during the support period", and Annex VII point 2(b) lists the SBOM inside that documentation. Annex I, Part II, point 4 requires manufacturers, once a security update is out, to "share and publicly disclose information about fixed vulnerabilities, including a description of the vulnerabilities". Point 2 of the same Part asks for security updates to be provided separately from functionality updates "where technically feasible", and a diff shows at a glance whether a security release also carried feature components.

For medical devices, the FDA premarket cybersecurity guidance issued on 3 February 2026 states that section 524B(b)(3) of the FD&C Act "requires manufacturers of cyber devices to provide an SBOM", and its section on modifications asks for an SBOM with a change submission as well. The same guidance asks, for each component, for its level of support and its end-of-support date, which a diff can track release by release.

Sources: NTIA report p. 12; Regulation (EU) 2024/2847; FDA guidance sections V.A.4 and VII.D (all retrieved 13 November 2026). For a release checklist across the whole regulation, see the CRA checklist for device makers; the FDA side is covered in FDA premarket cybersecurity for medical devices.

A release-to-release diff should report four kinds of component change and three kinds of vulnerability change. The component side is mechanical; the vulnerability side needs current CVE data and your own VEX records.

Two reading rules save time. First, a version that sorts lower in the new SBOM is more often a sign that someone attached the wrong SBOM than a real downgrade; confirm the image hash before you investigate. Second, a component that disappears and reappears under a different name usually reflects a change of cataloguer or naming, not a change in the image. Identify components by purl where you can; our SBOM minimum elements guide explains which fields have to be present for this matching to work.

Keep the two SBOMs, the image hashes and the diff output together in the release record. Without the hashes, nobody can later prove which image the diff described.

Compare the vulnerability matches of both SBOMs against the same data snapshot: a CVE matched on N and absent on N+1 was closed, a CVE matched only on N+1 was added. Using one snapshot for both sides keeps a database update from looking like a firmware change.

Each outcome has a natural home in a CSAF advisory. The OASIS CSAF 2.0 standard defines product status values per product version: fixed for versions that "contain a fix for the vulnerability", first_fixed for versions that "contain the first fix", last_affected for "the last versions in a release train known to be affected", and known_not_affected for versions "known not to be affected by the vulnerability".

Order the added CVEs the same way you order any finding: KEV first, then EPSS, then impact, as described in KEV and EPSS vulnerability prioritisation. A KEV entry that arrives with a new release is a reason to hold that release.

Only after someone checks them again. A VEX statement is a claim about specific product versions, and a component upgrade, a changed build option or a new service can make a "not affected" claim false.

Carry a statement forward when the diff shows that the component, its version and the evidence behind the justification are unchanged. Re-check it when any of these appears in the diff:

• the component's version changed, even by a patch release;
• the build configuration changed, for example a kernel or BusyBox option that decided whether the vulnerable code is compiled in;
• a new component now calls the affected code, or a new network service exposes it;
• the statement relied on a mitigation that the new release changed.

Write the result per version. In CSAF that means listing the new product version in the right status group; in CycloneDX, a VEX entry can point at a component in a specific SBOM through BOM-Link. Format choice, product trees and publishing are covered in CSAF VEX for device makers.

AI is useful for turning a verified diff into readable text, and has no place in producing the diff or deciding what it means for exploitability. The comparison itself is deterministic and should be reproducible from the two files.

Good uses: drafting release-note lines from the diff rows ("zlib upgraded from 1.2.13 to 1.3.1"), grouping changes by subsystem, and summarising added CVEs per component with a citation for every sentence. The CycloneDX Common Release Notes Format gives such text a machine-readable home, with fields for the issues a release resolved, including security updates. Poor uses: guessing a missing version, deciding a CVE does not apply, or describing a change that no diff row supports.

SoftWSP follows the same split. The device firmware security service scans each firmware image on its own: unblob and Syft build a CycloneDX 1.6 SBOM, components are matched against NVD, CISA KEV, FIRST EPSS and CISA ICS advisories, a fixed ruleset scores them, and AI drafts the report text, which is rejected if any claim sentence lacks a cited record; an engineer reviews it before delivery. The platform has no built-in comparison between two images, so the release diff runs on two exported SBOMs, for example in the diff tool above. SoftWSP writes no VEX statements. How the triage pipeline works end to end, and where AI must not decide, is set out in AI-assisted SBOM and vulnerability triage for device firmware.

One pass per release candidate, filed with the release record:

1. Build the SBOM from the release image with the same generator and version as last time; store it with the image hash.
2. Diff it against the SBOM of the last shipped release, not the last build.
3. Explain every added, removed and version-changed component in one sentence; investigate any downgrade.
4. Review every added licence and every licence change.
5. Re-match both SBOMs against one vulnerability data snapshot; list closed and added CVEs.
6. Triage added CVEs, KEV first; hold the release for unmitigated KEV entries.
7. Re-check every VEX statement whose component or evidence changed; write statements for the new version.
8. Update the technical documentation and the fixed-vulnerability disclosure from the same diff.
9. Draft release notes from the diff rows and have an engineer approve the text.