An SBOM (Software Bill of Materials) is a machine-readable inventory of every software component in a product, including component names, versions, licenses, and identifiers. For firmware, an SBOM tells you exactly what is running on your devices: every open source library, every third-party binary, every kernel module, with version numbers that can be checked against vulnerability databases.
SBOMs have moved from “nice to have” to legally required. The EU Cyber Resilience Act mandates SBOMs under Article 13 from December 2027. The US NTIA established minimum SBOM elements in 2021 as part of the Executive Order on Improving the Nation’s Cybersecurity. Healthcare, defense, and federal procurement rules in multiple countries now require or strongly recommend SBOMs for connected products.
If you are making embedded systems, IoT devices, or any connected hardware product, understanding SBOMs is no longer optional.
What Is an SBOM?
An SBOM is a machine-readable list of every software component in a product. Think of it as an ingredient list for software: just as a food label tells you what’s in a product so you can check for allergens or additives, an SBOM tells you what software components are in a product so you can check for known vulnerabilities or license issues.
A complete SBOM for a firmware image includes:
- The name of every component (library, binary, kernel module, package)
- The version number of each component
- The supplier or source of each component
- A unique identifier (CPE, PURL, or SWID tag) that enables automated vulnerability matching
- The license under which each component is distributed
- The hash of each component file (SHA-256 or similar) for integrity verification
- Dependency relationships between components
Why Firmware SBOMs Are Harder Than Software SBOMs
Generating an SBOM for a web application or a mobile app is relatively straightforward: modern package managers (npm, pip, Maven, Cargo) already know every dependency. You can run a single command and get a complete list.
Firmware is different for several reasons:
Binary-only components. Firmware often includes pre-compiled binaries from chip vendors, ODMs, or proprietary sources without accompanying source code. You cannot use package manager metadata because there is none. Component identification requires binary analysis: reading ELF headers, parsing symbol tables, identifying strings that reveal version information.
No standard package manager. Unlike a Node.js project where every dependency is in package.json, a firmware image is a filesystem containing arbitrary binaries. There is no canonical manifest. You need to extract and analyze the filesystem to find what is there.
Embedded OS complexity. A typical embedded Linux firmware image includes a custom kernel, BusyBox utilities, numerous userspace binaries, and possibly several third-party libraries all compiled together into a single image. Each of those components has its own version, its own CVEs, and its own license.
Version obfuscation. Firmware vendors sometimes strip version strings from binaries to avoid disclosing their component versions. Identifying the exact version of an obfuscated library requires deeper analysis than just reading a string.
Third-party and ODM components. Many hardware manufacturers receive firmware from their ODM or chip vendor and do not fully know what is in it. This makes SBOM generation not just a technical challenge but also a supply chain transparency challenge.
What a Firmware SBOM Should Contain
A complete firmware SBOM should include all of the following fields for each component:
| Field | Description | Example Value | Required by EU CRA? |
|---|---|---|---|
| Name | Human-readable component name | OpenSSL | Yes |
| Version | Exact version string | 1.1.1w | Yes |
| Supplier | Who provides this component | OpenSSL Foundation | Yes |
| Identifier | Machine-readable ID (CPE or PURL) | pkg:deb/[email protected] | Yes |
| License | SPDX license identifier | Apache-2.0 | Yes |
| Hash | SHA-256 hash of the component file | sha256:abc123… | Recommended |
| Dependencies | What this component depends on | libcrypto.so | Recommended |
| Download URL | Where this component came from | https://openssl.org | Optional |
The EU CRA does not mandate a specific format, but requires that the SBOM be machine-readable and contain at minimum: component name, version, and unique identifier.
An extracted firmware SBOM: components, network services, and binary-level malware scan results in one report.
CycloneDX vs SPDX: Which Format Should You Use?
Both CycloneDX and SPDX are widely adopted SBOM standards. Both are supported by most SBOM tools and vulnerability management platforms. The choice between them depends on your use case.
| Feature | CycloneDX | SPDX |
|---|---|---|
| Governing body | OWASP | Linux Foundation / ISO |
| Primary format | JSON, XML | JSON, RDF, YAML, TV |
| VEX support | Native (CycloneDX includes VEX) | Via separate document |
| License focus | Secondary | Primary (originated for license compliance) |
| Vulnerability focus | Primary | Secondary |
| ISO standard | No | ISO/IEC 5962:2021 |
| Tool support | Excellent | Excellent |
| Best for | Security-focused firmware SBOMs | License compliance SBOMs |
Recommendation for firmware security: CycloneDX is the better choice for security-focused firmware SBOM programs. Its native VEX support means you can express vulnerability exploitability status within the same document format. Most vulnerability management platforms prefer CycloneDX.
For EU CRA compliance: generate both. The CRA does not specify a format, but having both CycloneDX and SPDX available ensures you can satisfy any procurement requirement.
What Is a VEX Document?
A VEX (Vulnerability Exploitability eXchange) document is a companion to an SBOM that communicates whether known vulnerabilities in your components are actually exploitable in your specific product.
When your SBOM lists a component with known CVEs, a VEX document lets you say:
- Affected: This CVE is present and exploitable in our product
- Not affected: This CVE exists in the component but is not exploitable in our product because [reason]
- Fixed: This CVE was present but has been fixed in version X
- Under investigation: We are investigating whether this CVE affects our product
This matters because raw CVE counts are often misleading. A firmware image might contain OpenSSL with 20 known CVEs, but only 3 of those CVEs are relevant to the way your product uses OpenSSL. A VEX document communicates this distinction, reducing the noise in vulnerability reports and helping your customers understand their actual exposure.
The EU CRA implicitly requires VEX-like documentation as part of the vulnerability handling process under Annex I.
How to Generate a Firmware SBOM Automatically
Manual SBOM generation for firmware is not practical at scale. A typical embedded Linux firmware image contains hundreds of components. Manually identifying each component’s name, version, and license would take days per image and would be error-prone.
The automated approach:
Extract the firmware filesystem. Parse the firmware image format (SquashFS, JFFS2, ext2, etc.) and extract the filesystem tree. This requires format-specific parsing tools.
Identify and enumerate binaries. Walk the extracted filesystem and find every ELF binary, shared library, and executable.
Component identification. For each binary, use a combination of: string analysis (version strings embedded in the binary), ELF header analysis (build IDs, SONAME), package database matching, and binary signature matching to identify the component and its version.
License identification. Match identified components against license databases using the component name and version.
CVE matching. Match identified components against CVE databases using CPE (Common Platform Enumeration) identifiers.
SBOM generation. Output the results in CycloneDX and/or SPDX format.
FDIE automates all of these steps. Upload a firmware image at /pricing/ and receive a complete CycloneDX and SPDX SBOM within minutes, without any manual component identification.
SBOM Quality: What Makes a Good vs Bad Firmware SBOM
Not all SBOMs are equal. A low-quality SBOM is worse than no SBOM, because it creates false confidence while missing real vulnerabilities.
Signs of a good firmware SBOM:
- Every component has a version number (not “unknown” or blank)
- Every component has a CPE or PURL identifier (enables automated CVE matching)
- Components include transitive dependencies (what each library depends on)
- The SBOM was generated from binary analysis, not just from a manifest file
- The SBOM is generated automatically on every firmware build (not manually, not quarterly)
Signs of a low-quality firmware SBOM:
- Many components with “unknown” version
- Missing CPE or PURL identifiers
- Only top-level components listed (dependencies of dependencies missing)
- Generated from a package manifest that may not reflect the actual firmware build
- Generated once and not updated when firmware changes
The gap between a good and bad firmware SBOM is usually the difference between automated binary analysis and manual component listing. Delta Intelligence in FDIE tracks SBOM changes between firmware versions, so you can see exactly which components were added, removed, or changed in each release. Read more at /platform/delta-intelligence/.
Frequently Asked Questions
Q: Is an SBOM required for EU CRA compliance? Yes. Article 13 of the EU Cyber Resilience Act requires manufacturers to prepare and maintain a Software Bill of Materials for each product with digital elements. The SBOM must contain at minimum the top-level dependencies of the product. The requirement applies from December 2027.
Q: What is the difference between CycloneDX and SPDX? Both are open standards for SBOM format. CycloneDX, governed by OWASP, is optimized for security use cases and includes native support for VEX documents. SPDX, governed by the Linux Foundation and also an ISO standard (ISO/IEC 5962:2021), originated for license compliance. For firmware security programs, CycloneDX is generally preferred. For license compliance, SPDX is the more established choice. FDIE generates both.
Q: How often should you generate a firmware SBOM? You should generate a new SBOM every time your firmware changes. Treat SBOM generation like a build artifact: it should be part of your automated firmware build pipeline, not a quarterly manual exercise. If you change a component, update a library, or patch a vulnerability, a new SBOM should be generated automatically. FDIE integrates via REST API to support this automation.