Track components across a fleet with three linked records: one SBOM for every firmware release you ship, a record of which release each device runs right now, and a loop that re-checks those SBOMs against new advisories. You do not need an SBOM per device, because devices on the same release share the same contents.
The three records
Release SBOM. A bill of materials generated at build time for each firmware image. It lists the operating system packages, libraries, bootloader, and your own code with versions and identifiers. CycloneDX, for example, is described by its maintainers as able to represent software, hardware devices, and configurations, so one format can cover a firmware image and the board it runs on.
Device to release map. A table with one row per device: device ID, hardware model, current release, last check-in time, and update state. This is the record that turns a vulnerable component into a list of affected devices.
Refresh loop. Advisories arrive after you ship. Matching stored SBOMs against fresh advisory data on a schedule is what keeps the inventory useful after the build is done.
Why per release and not per device
A fleet of 200,000 devices on four releases needs four SBOMs, not 200,000. The device record only has to say which of the four each unit runs. That keeps storage small and makes a lookup a join between two tables.
| Question | Where the answer lives |
|---|---|
| What is inside release 4.2.1? | Release SBOM |
| Which devices run 4.2.1? | Device to release map |
| Is a new CVE in 4.2.1? | Refresh loop against the SBOM |
| Can those devices be reached to update? | Last check-in time and update state |
Steps to set it up
- Generate an SBOM in the firmware build for every release candidate, and keep the one that matches the signed image.
- Store each SBOM under the release identifier, unchanged, so a customer or auditor can retrieve it later.
- Have the update agent report its release identifier and hardware model at every check-in.
- Join the two in one place, even if that place is a database table to start with.
- Record the components that are not in the SBOM, such as a vendor binary blob, as explicit entries with an owner.
- Review the gaps: devices with no recent check-in, and releases with no SBOM.
What to watch for
Devices that were flashed at the factory with a release you no longer build need an SBOM too. If you cannot regenerate it, say so in the record and treat that release as unknown, not clean.
Also keep the hardware side. A fleet question is often "which modem module" or "which chip revision", and those belong in the same inventory as the software.
Try it yourself
Click through it at your own pace, or open it full screen.
Open the inventory view and look at how one component appears under several builds. That is the shape of a release SBOM list.
If your firmware build can emit an SBOM, Safeguard can ingest it, scan the dependencies, and keep matching it against new advisories. You can try a single SBOM or image with the free scan at gold.safeguard.sh/scan.
Quick check
Do I need an SBOM for each physical device?
No. Devices on the same firmware release share one SBOM. Keep a separate record that says which release each device runs.
What if a device runs a release I cannot rebuild?
Mark that release as having an unknown composition, assign an owner, and plan to move those devices to a release you can inventory.
Sources
Last reviewed: 19 October 2026.
