If you work in application security, SBOM generation is largely a solved problem. Run Syft, Trivy, or cdxgen against your project and you get a comprehensive inventory of your dependencies in seconds. The tools understand package managers, lockfiles, and container layers. The output is reliable.
Firmware is different. Firmware SBOM generation is where application security tooling was five years ago — immature, inconsistent, and full of gaps. And unlike application security, the stakes in firmware are often physical: medical devices, industrial controllers, automotive systems, and critical infrastructure.
This post covers why firmware SBOMs are hard, what approaches work today, and what needs to improve.
Why Firmware Is Hard
No Standard Package Manager
Application-level SBOMs work because dependencies are declared in a manifest file — package.json, requirements.txt, Cargo.toml. The SBOM tool reads the manifest and resolves the dependency tree.
Firmware does not have this luxury. Components are often compiled from source, vendored into the build tree, or integrated as binary blobs. There is no manifest file that lists everything. The build system might use Yocto, Buildroot, a custom Makefile, or a proprietary IDE, each with different conventions for declaring dependencies.
Binary Blobs
Many firmware images include binary components provided by chip manufacturers — bootloaders, radio firmware, hardware abstraction layers. These components are delivered as pre-compiled binaries with no source code and no accompanying SBOM. You literally cannot determine what is inside them without reverse engineering.
Some chip manufacturers are beginning to provide SBOMs for their binary components, but adoption is spotty. Until it becomes universal, firmware SBOMs will have gaps.
Vendored and Forked Libraries
Application developers generally use libraries as-is from a package registry. Firmware developers frequently fork, patch, and vendor libraries into their source tree. A firmware project might include a modified version of OpenSSL with custom patches for a specific hardware platform.
This creates an SBOM accuracy problem. Is this component OpenSSL 1.1.1t, or is it a derivative that only partially overlaps with the upstream release? If a CVE is reported against OpenSSL 1.1.1t, does it affect this fork? The answer depends on which patches were applied and whether they touch the vulnerable code path.
Long Lifecycles
Enterprise software gets patched continuously. Firmware often does not. A medical device might run the same firmware for ten years. An industrial controller might never receive an update after deployment.
This means firmware SBOMs need to account for the entire lifecycle of the device, not just the point of manufacture. A component that was vulnerability-free at build time may accumulate dozens of CVEs over a decade. Tracking this drift is a continuous monitoring problem that most firmware vendors have not invested in.
Approaches That Work Today
Build System Integration
The most reliable approach to firmware SBOM generation is integration at the build system level. If you control the build process, you can instrument it to track every component that goes into the final image.
Yocto/OpenEmbedded has built-in SPDX generation support. The create-spdx class produces an SBOM that reflects the actual build — every recipe, every patch, every configuration option. It is the gold standard for Linux-based firmware.
Buildroot has community-contributed SBOM tooling, though it is less mature than Yocto's. The legal-info target provides dependency and license information that can be transformed into a standard SBOM format.
Custom build systems require custom integration. The approach is the same: hook into the build process at the point where dependencies are resolved and compiled, and emit SBOM data for each component.
Build system integration produces the most accurate SBOMs, but it requires access to the build environment and understanding of the build process. For third-party firmware that you do not build yourself, this approach is unavailable.
Binary Analysis
When source code and build system access are not available, binary analysis is the alternative. Tools like FACT (Firmware Analysis and Comparison Tool), binwalk, and commercial solutions from companies like Finite State and Cybellum can decompose firmware images and identify components through:
- String analysis — extracting version strings, copyright notices, and build identifiers embedded in the binary
- Hash matching — comparing binary segments against databases of known library binaries
- Function signature matching — identifying known library functions through their binary signatures
Binary analysis is imprecise. It cannot reliably identify custom or modified components. It misses vendored code that has been heavily modified. And it produces confidence scores rather than definitive identifications. But for third-party firmware analysis, it is often the only option.
Supplier SBOMs
The most scalable approach is requiring your firmware suppliers to provide SBOMs. This shifts the burden to the party with the most knowledge — the entity that built the firmware.
The FDA now requires SBOMs for medical device premarket submissions. This regulatory pressure is driving adoption among medical device manufacturers. Similar requirements are emerging in automotive (UN R155) and industrial controls (IEC 62443).
The challenge is validation. How do you verify that a supplier-provided SBOM is accurate and complete? Partial validation through binary analysis — checking that the SBOM's listed components are consistent with what binary analysis finds in the firmware image — provides a trust-but-verify approach.
The Vulnerability Tracking Problem
Generating a firmware SBOM is step one. Tracking vulnerabilities across the device lifecycle is step two, and it is arguably harder.
When a new CVE is published for a component in your firmware, you need to:
- Determine whether the vulnerable version is present in any deployed firmware
- Assess whether the vulnerability is exploitable given the firmware's configuration and deployment context
- Determine whether a firmware update is feasible
- If not, identify compensating controls
For devices that cannot be updated — and there are millions of deployed IoT devices in this category — the answer to step 3 is "no," and the security posture depends entirely on compensating controls: network segmentation, monitoring, and access restrictions.
Emerging Standards
Several standards efforts are addressing the firmware SBOM gap:
NIST IR 8413 provides guidance on SBOM formats and minimum elements specific to IoT devices.
The Cyber Resilience Act includes firmware-specific provisions, requiring manufacturers to maintain SBOMs for the expected lifetime of the product.
IEC 62443-4-1 addresses secure development lifecycle for industrial automation, including software composition requirements that effectively mandate SBOMs.
These standards are converging on a common set of expectations: firmware vendors must produce SBOMs, update them throughout the product lifecycle, and make them available to device operators.
How Safeguard.sh Helps
Safeguard supports firmware SBOM workflows through build system integration (with Yocto and Buildroot plugins), binary analysis for third-party firmware, and continuous vulnerability monitoring for deployed device fleets. Our platform can ingest supplier SBOMs, validate them against binary analysis results, and track vulnerability drift across the device lifecycle. For organizations navigating FDA, CRA, or IEC 62443 requirements, Safeguard provides the tooling to produce, manage, and monitor firmware SBOMs at scale.