Yes, list it. A radio module's firmware is software that ships in your product, even if you cannot read it. Record the supplier, the module part number, the firmware version and a hash of the blob, and mark the contents as unknown rather than leaving the entry out.
Why it belongs
Customers who ask for an SBOM want to know what runs on the device. Radio firmware handles untrusted traffic from the air and has had its share of advisories across the industry. If your SBOM skips it, a buyer's security team will notice the gap, and so will you the day an advisory names your module.
What you can and cannot say
You may not be able to list the libraries inside a closed blob. That is acceptable if you say so. A truthful entry reads: firmware from this supplier, for this module, at this version, with this hash, contents not disclosed by the supplier.
CycloneDX models this naturally. A hardware device with firmware should have a component for the device and another of type firmware for the software on it, per the 1.6 schema. In SPDX, a package purpose of FIRMWARE exists for the same idea.
What to collect from the supplier
- The exact firmware version and how to read it from a running unit.
- A list of open source components inside, if they will give one.
- Their security contact and advisory process, including how fast they usually respond.
- How firmware updates are delivered, and whether you control timing.
- Whether they will sign a statement about components at each release.
If a supplier refuses all five, record that. It is useful information for your risk review.
Where the blob lives
Blobs reach a product in different ways. Some are loaded by the host driver at boot from a file in your image. Some are burned into the module at the factory. Some are updated separately by the supplier tool. Each path changes who can update it and how you inventory it.
| Delivery | Inventory approach | Update owner |
|---|---|---|
| Loaded from your image at boot | Hash the file in your build | You |
| Programmed at the module factory | Read version from the unit | Supplier, or you through a tool |
| Updated by a separate tool | Track tool and blob versions | Shared |
Steps
- Identify every module that contains firmware.
- Add a device and a firmware component for each.
- Record the version you actually ship, read from a sample unit.
- Store the supplier answers next to the SBOM.
- Review at each release, since module firmware changes with supplier batches.
Limits
A listed blob is not a verified blob. The SBOM records the fact; it does not assure the contents. Treat unknown contents as a risk to track.
Where Safeguard fits
Safeguard generates SBOMs and scans dependencies from your repositories. Closed module firmware has to be added from supplier information, so keep that in your release checklist. A free scan shows how entries appear.
Quick check
What if the supplier will not share contents?
List the blob with what you know, mark the contents unknown, and record the refusal in your risk register.
Do I hash the blob?
Yes, where you can access the file. It lets you prove which blob you shipped.
Sources
Last reviewed: 19 October 2026.
