Write one SBOM per shipped firmware image, not per marketing product. If two hardware variants run the same image with the same components, one SBOM covers both. If a variant has a different driver, module or build option, it needs its own document.
The question behind the question
An SBOM describes a specific artifact. The useful test is simple: if a customer picks up a unit and reads its firmware version, can you point to one SBOM that matches exactly what is inside? If yes, you have the right granularity. If you would have to say "mostly this one, apart from the radio", you do not.
Where variants really differ
Variants usually diverge in a few places:
- Different radio, sensor or storage parts that need different drivers.
- Regional builds that enable different protocols or certificates.
- Different bootloader or board support code for a new chip revision.
- Optional features enabled only on premium models.
Each one changes what is compiled in. A vulnerability in a Bluetooth stack matters to variants that include it and does not matter to those that do not.
Three common approaches
| Approach | Strength | Weakness |
|---|---|---|
| One SBOM per firmware image | Exact match to what ships | More documents to manage |
| One SBOM per product line with variant notes | Fewer files | Readers must interpret the notes, and mistakes creep in |
| A base SBOM plus per variant overlays | Shows the shared core clearly | Needs tooling to merge, and customers may not use overlays |
Most small teams do best with the first. It is the easiest to explain and to verify.
Steps
- List every distinct firmware image your build produces, with its file name and version scheme.
- Map each hardware variant to one image. Several variants can map to one.
- Generate the SBOM from each image build, not from a shared source tree. The build knows which options were on.
- Name the file so it includes the image version, and store it next to the image.
- Keep a table that maps product names and hardware revisions to SBOM files. Customer support will use it.
Using the answer in a CVE response
When a new advisory lands, you want to say which products are affected within an hour. Per image SBOMs let you search all of them for the component and list the matching images, then map those to products with the table. A per product SBOM with variant notes makes this slower and more error prone.
When a shared SBOM is fine
If your variants differ only in labelling, packaging or colour, or the same image is flashed to all of them, a single SBOM is both accurate and simpler. Do not multiply documents for the sake of it.
Where Safeguard fits
Safeguard generates SBOMs and scans dependencies per repository or build. How you map images to products is an internal process. Start with a free scan on one image's source to see the output.
Quick check
Do two hardware revisions with the same firmware need two SBOMs?
Usually not. The SBOM describes the software image. Record hardware differences in your hardware records.
Should the SBOM change when the board changes but the code does not?
Only if the board change adds or removes software components, such as a new driver.
Last reviewed: 19 October 2026.
