Most firmware SBOM mistakes come from a few false beliefs: that a scanner finds everything, that the vendor SDK is not your problem, and that an SBOM proves safety. Here are six, each with the fact that corrects it and what to do next.
Myth 1: A generator will find everything in my image
Fact: generators read what they can see. Package manifests and lockfiles are easy. Copied C source, closed blobs and renamed code are not. Review the output against your own knowledge of the image, and add missing entries by hand.
Myth 2: The chip vendor SDK is the vendor's problem
Fact: once you ship it, it is in your product. You may not control its fixes, but you still need to know its version, its bundled libraries and who to ask when an advisory lands.
Myth 3: An SBOM tells me which CVEs affect my product
Fact: it tells you what is in the product. Whether a CVE applies depends on the version, the build configuration and whether the code is reachable. The Linux kernel documentation, for example, states that large numbers of assigned kernel CVEs are not relevant to a given system. Use the SBOM to ask the question, then use evidence to answer it.
Myth 4: One SBOM per product line is enough
Fact: variants can differ in drivers, modules and build options. The document should match one shipped image. A shared document is fine only where the images are the same.
Myth 5: Hardware does not belong in an SBOM
Fact: an SBOM is about software, so physical parts belong in a hardware list, which CycloneDX supports through an HBOM capability. But the software that runs on each part, its firmware, belongs in the SBOM, and the CycloneDX schema says a device containing firmware should have a component for each.
Myth 6: Once published, the SBOM is done
Fact: a record describes a moment. New advisories arrive after release, and units stay in service for years. Keep the document, re-check it against new advisories, and update the status of findings through VEX statements as you learn more.
A short checklist to use today
| Check | Done? |
|---|---|
| Every shipped image has an SBOM | |
| Each SBOM names the image digest and version | |
| RTOS, bootloader and SDK libraries are listed | |
| Closed blobs are listed with supplier and version, contents marked unknown | |
| Copied libraries have name, version, origin and hash | |
| Unknowns are marked as unknown, not guessed | |
| You can search all SBOMs for one component in minutes |
What to fix first
If you can do only one thing, make the SBOM store searchable. Everything else gets easier once you can answer "which images contain this library" quickly. After that, tackle the unknown entries, starting with network facing code.
Where Safeguard fits
Safeguard generates SBOMs and scans dependencies from your repositories, with reachability analysis for application dependencies. It will not replace the manual work on closed blobs and copied code. A free scan is an easy first step.
Quick check
Does having an SBOM mean my firmware is secure?
No. It is an inventory. Security depends on how you act on what the inventory shows.
What is the first fix for a weak firmware SBOM?
Make every shipped image's SBOM exist, be tied to a digest, and be searchable.
Sources
- The Linux kernel documentation: CVEs
- CycloneDX Hardware Bill of Materials (HBOM)
- CycloneDX 1.6 JSON schema
Last reviewed: 19 October 2026.
