Software Bill of Materials documents have been a compliance topic for a few years now. The NTIA minimum elements, Executive Order 14028, and EU CRA Article 13 all require them. Most software development teams have tooling that can generate an SBOM from a package manifest or a lockfile. You point it at your package.json or go.sum and you get a CycloneDX document.
Firmware teams cannot do that. And this is where a lot of SBOM projects for IoT and connected devices run into trouble.
Why Firmware Is Different
When you write a web application, you have a package manager. Every dependency is declared somewhere, with a version. The build system knows what went into the binary. An SBOM tool can read those declarations and produce an accurate component list without ever looking at the compiled output.
Firmware does not work this way. Embedded Linux images are often built with Buildroot or Yocto, and while those build systems do maintain a package list, the relationship between that list and the final firmware image is not always clean. Vendor SDKs add pre-compiled binaries that were never in your build recipes. Board support packages include closed-source libraries. Custom patches are applied without updating version strings. The binary shipped to devices may not match any declared dependency.
More fundamentally, firmware often contains components that were never declared as dependencies at all. A library statically linked into a custom binary. A utility copied in during the build process. A kernel module from a hardware vendor. These are invisible to any tool that reads manifests rather than analyzing actual binaries.
What a Firmware SBOM Needs to Capture
A complete firmware SBOM needs to include:
All binaries in the extracted filesystem. Not just declared packages, but every ELF binary, every shared library, every executable in the firmware image. This requires actually extracting the filesystem from the firmware format (SquashFS, JFFS2, cramfs, and so on) and enumerating what is there.
Component identification from binary content. For each binary, the SBOM generator needs to identify the upstream component it was built from. This means looking at strings embedded in the binary, symbol names, version strings in ELF metadata, and package manager databases (if any are present in the extracted filesystem). When a vendor SDK ships a pre-compiled libcrypto.so.1.0.2, the SBOM tool needs to recognize it as OpenSSL 1.0.2, even though no package declaration says so.
Static analysis of linked libraries. Binaries that statically link third-party code need to be decomposed to identify those components. A custom binary that statically links a vulnerable version of zlib is a vulnerability even though zlib is not listed as a runtime dependency.
Kernel and driver components. The Linux kernel version and loaded modules are components. Kernel CVEs are real and regularly exploited. An SBOM that covers userspace but misses the kernel is incomplete.
The Source Code SBOM Problem
Some teams try to generate firmware SBOMs from source. They take their Yocto recipes or Buildroot configs and produce a component list from build declarations. This is better than nothing, but it has a known gap: pre-compiled vendor blobs.
Virtually every hardware platform includes some vendor-supplied binary components. WiFi firmware blobs, proprietary GPU drivers, closed-source codec libraries. These do not appear in your source recipes because they are not built from source. If a CVE is found in a vendor blob that you are shipping, a source-derived SBOM will not contain the affected component and your vulnerability scanner will not flag it.
This is not hypothetical. CVE-2021-22543, CVE-2022-0185, and various vendor-specific vulnerabilities in closed-source components have affected products where the manufacturer’s SBOM listed only their own open-source build ingredients.
CycloneDX vs SPDX for Firmware
Both formats are required or accepted under various regulations. EU CRA Article 13 does not mandate a specific format; it requires that the SBOM follow a machine-readable format and contain at minimum the NTIA minimum elements. Both CycloneDX and SPDX satisfy this.
CycloneDX has the edge for firmware because it integrates with VEX (Vulnerability Exploitability eXchange). Your SBOM and your VEX document use the same component identifiers, which makes it straightforward to attach exploitability statements to specific components. CycloneDX also has a more developed ecosystem for firmware-specific properties.
SPDX has broader adoption in the Linux Foundation community and in software supply chain contexts. If your procurement process requires SPDX, that is a valid reason to use it. FDIE generates both.
What Makes Binary-Based SBOM Generation Hard
The hard part of binary-based firmware SBOM generation is not extracting the filesystem. Binwalk and similar tools handle that reasonably well. The hard part is accurately identifying components from binary content.
String-based version detection is noisy. ELF binaries contain many strings, and version strings are often formatted inconsistently. A naive approach produces false matches, wrong versions, and components that do not actually correspond to known upstream packages. The quality of the component identification determines the quality of the CVE correlation. A poorly identified component maps to the wrong CVE entries, producing either missed vulnerabilities or false positives.
Good binary SBOM generation requires multiple signals combined: version strings, symbol names, build ID hashes, library metadata, and cross-reference against known binary signatures. The false-positive rate on CVE correlation is directly tied to how accurately the component was identified.
How FDIE Handles This
FDIE’s extraction engine unpacks the firmware image, enumerates every binary in the resulting filesystem, identifies each component using combined binary analysis, and generates CycloneDX and SPDX SBOMs from the result. Pre-compiled vendor blobs are identified through binary signatures, not just package declarations. The CVE correlation runs against the identified components, not against declared dependencies.
The output SBOM includes confidence metadata per component, so you can see how each identification was reached. Components identified through strong binary signatures get higher confidence ratings than those identified through version string pattern matching alone.
Binary-identified components, exposed network services, and malware scan status, generated from the firmware image itself - not declared dependencies.
SBOM generation is available on Pro and above, in both CycloneDX and SPDX formats.
Frequently Asked Questions
Can I generate a firmware SBOM using Syft or Trivy? Syft and Trivy can analyze extracted firmware filesystems and pick up package manager databases if they exist. They struggle with pre-compiled vendor blobs and statically linked components because they rely on declared package metadata rather than binary analysis. They are useful tools but not complete solutions for firmware SBOM generation.
Does my SBOM need to cover third-party vendor blobs? Yes, if you ship them. EU CRA Article 13 requires the SBOM to cover the product as shipped. If you ship a firmware image that contains a vendor-supplied WiFi blob, that component must appear in your SBOM. The fact that it is closed-source does not exempt it.
How do I handle components I cannot identify? CycloneDX allows components with incomplete metadata. You can include a binary’s hash in the SBOM even when the upstream package identity is unknown. This at least creates a traceable record of what was present in the firmware, which satisfies the audit trail requirement even when the component cannot be fully identified.
How often should I regenerate the firmware SBOM? With every firmware release. The SBOM is a snapshot of a specific firmware version. If you update a component, patch a library, or change the build configuration, the SBOM for the previous version is no longer accurate for the new release. Version your SBOMs alongside your firmware releases.
What is the difference between a firmware SBOM and a VEX document? The SBOM lists what components are in the firmware. The VEX document states which CVEs against those components actually affect this specific product and why. They work together: the SBOM identifies the exposure surface, the VEX document tells auditors and customers which exposures are real. See our VEX guide for details.