How to Generate a Firmware SBOM: Open Source Tools and Workflows

When a critical vulnerability like Log4Shell or OpenSSL's Heartbleed dropped, every software team scrambled to answer one question: are we affected? For firmware manufacturers, that question is almost impossible to answer without a Software Bill of Materials. A container deployment can query its package manager in seconds. A firmware binary sitting in production devices across a factory floor cannot. Without a firmware SBOM, you have no inventory, and without an inventory, you cannot know what you need to patch, report, or replace.

This guide covers the three practical paths to generating a firmware SBOM using open source tools, the challenges that make firmware harder than software, and how to operationalise the result for ongoing CRA compliance.

What Is a Firmware SBOM?

A firmware SBOM is a structured inventory of all software components contained in a firmware image: OS packages, shared libraries, bootloaders, kernel modules, drivers, and any vendored binary blobs. The same NTIA minimum elements apply as for any software SBOM (supplier name, component name, version, unique identifier, dependency relationships, author of SBOM data, and timestamp), but they are substantially harder to populate for firmware than for a web application.

CycloneDX 1.6 defines firmware as a distinct component type alongside device hardware, which means you can model the entire product (hardware, firmware, and software layers) in a single CycloneDX document. This is relevant to CRA product classification: a router classified as a product with digital elements must have its firmware components tracked and monitored for the full support period.

CRA Link: The EU Cyber Resilience Act (Annex I) requires manufacturers to handle vulnerabilities across the full product lifecycle. An SBOM is the practical foundation: you cannot patch what you haven't catalogued. See SBOM requirements under the CRA for the full regulatory context.

A firmware SBOM is not a Hardware Bill of Materials (HBOM). The HBOM documents physical components: PCBs, chips, connectors. A firmware SBOM documents the software running on that hardware.

Why Firmware SBOMs Are Harder Than Software SBOMs

Generating an SBOM for a web application means running npm list --json or pip list. Generating one for firmware means reconstructing a manifest from artifacts that were never designed to be inventoried.

The core insight: firmware SBOM generation is reverse engineering under uncertainty. You are reconstructing a manifest from artifacts, not generating one from inputs. This distinction shapes which tool and workflow you should choose.

The Two Fundamental Approaches

Every firmware SBOM workflow falls into one of two categories:

1. Build-time SBOM. Generated during the build process from the build system's exact inputs. Highest accuracy. Requires access to the source build. Works with Yocto and Buildroot.
2. Post-build / analyzed SBOM. Reverse-engineered from a firmware binary image. Lower confidence, but often the only option when you receive firmware from an ODM or are auditing a device you didn't manufacture.

The right choice depends entirely on whether you control the build.

Approach 1 — Build-Time SBOM with Yocto or Buildroot

When to use: You own the firmware build. This is the gold standard for accuracy.

Yocto: create-spdx class (built-in)

The create-spdx bbclass is included in recent Yocto releases and inherited by default via Poky's distro configuration. No additional tooling is required. After a normal build, three files are generated:

# After a normal Yocto build
ls tmp/deploy/spdx/
# IMAGE-MACHINE.spdx.json         ← main SPDX document
# IMAGE-MACHINE.spdx.index.json   ← per-recipe component index
# IMAGE-MACHINE.spdx.tar.zst      ← full archive with all component SBOMs

The generated SBOM includes all software components, exact versions, licenses, source URLs, applied patches, and dependency relationships. There is no extraction uncertainty: the SBOM is derived from the same inputs that produced the binary.

To also perform CVE analysis at build time:

# Add to local.conf
INHERIT += "cve-check"
CVE_CHECK_REPORT_PATCHED = "1"

See the Yocto SBOM documentation for full configuration options.

Buildroot: make legal-info + CycloneDX generator

# Step 1: Generate the component manifest
make legal-info
# Output: output/legal-info/manifest.csv

# Step 2: Convert to CycloneDX SBOM
pip install cyclonedx-buildroot
cyclonedx-buildroot output/legal-info/manifest.csv -o sbom.cdx.json

# Optional: scan for CVEs at build time
python support/scripts/cve-check --nvd-path ./nvd-data/

The cyclonedx-buildroot converter produces a CycloneDX JSON output from Buildroot's legal manifest, making it immediately usable for CRA compliance.

Known limitation: Third-party binary blobs added to the build (Wi-Fi firmware, GPU blobs) are tracked only if you manually add them as Yocto or Buildroot packages. If your build system doesn't know about a blob, neither will the SBOM.

Approach 2 — Analyzing an Existing Binary

When to use: You received firmware from an ODM or OEM, or you are auditing a device you don't build yourself.

Step 1: Extract the firmware with binwalk

binwalk v3, the Rust rewrite of the original tool, provides faster extraction and improved format support for modern firmware images:

# Install binwalk v3
pip install binwalk

# Extract all embedded filesystems
binwalk -eM firmware.bin

# Check what got extracted
ls _firmware.bin.extracted/

# Check for encrypted partitions before proceeding
binwalk -E firmware.bin
# High entropy above 0.9 indicates encrypted content

Step 2a: Identify the Linux distribution and run Syft

If the extracted filesystem contains a standard embedded Linux distribution (OpenWRT, Debian-based, Alpine-based):

# Check for package manager databases
ls _firmware.bin.extracted/squashfs-root/var/lib/dpkg/    # Debian-based
ls _firmware.bin.extracted/squashfs-root/lib/apk/db/      # Alpine/musl-based
ls _firmware.bin.extracted/squashfs-root/var/lib/opkg/    # OpenWRT/opkg

# Run Syft on the extracted filesystem
syft dir:./_firmware.bin.extracted/squashfs-root/ \
  -o cyclonedx-json=sbom.cdx.json \
  -o spdx-json=sbom.spdx.json

Syft reads package manager databases and generates an SBOM with high confidence for packaged components. It does not see custom-compiled C/C++ libraries that were compiled directly into the binary. For those, you need step 2b.

Step 2b: Scan binaries for known vulnerable libraries with cve-bin-tool

# Install Intel's cve-bin-tool
pip install cve-bin-tool

# Scan extracted binary directory
cve-bin-tool ./_firmware.bin.extracted/ \
  --output-file cve-report.json \
  -f cyclonedx

cve-bin-tool uses string pattern matching against signatures for 447+ known embedded libraries: OpenSSL, libpng, libxml2, expat, zlib, curl, and more. It covers what Syft misses: libraries compiled and stripped into the binary with no package database entry.

Step 2c: Deep firmware analysis with EMBA

For a comprehensive analysis that combines extraction, SBOM generation, and a full security review in a single workflow:

# Clone and set up EMBA
git clone https://github.com/e-m-b-a/emba.git
cd emba && sudo ./installer.sh -d

# Run EMBA with SBOM output
sudo ./emba.sh -f /path/to/firmware.bin -l /tmp/emba-log/ -p SBOM

EMBA handles extraction internally, identifies components through multiple parallel strategies (string matching, binary hashing, filesystem analysis, CVE database lookups), outputs a CycloneDX SBOM with VEX data, and generates a full vulnerability report. It is the most comprehensive open-source option for black-box firmware analysis and is particularly useful for third-party firmware audits.

Tool Reference — Quick Comparison

SPDX vs CycloneDX: Both formats are widely accepted. CycloneDX has a native firmware component type and built-in VEX support, making it the better choice for CRA compliance. SPDX is preferred in open-source license compliance contexts and is Yocto's native output. For CRA, generate CycloneDX. If you use Yocto, generate both.

Managing Your Firmware SBOM Over Time

A one-time SBOM is a snapshot. For CRA compliance, you need an operational SBOM that evolves with your product.

Build → SBOM (CycloneDX) → Dependency-Track → CVE alert → VEX statement → ENISA report (if exploited)

Four steps to make this operational:

1. Regenerate on every firmware build. Hook Yocto or Buildroot SBOM generation into your CI/CD pipeline so every release produces a fresh SBOM automatically.
2. Push to Dependency-Track. OWASP's Dependency-Track monitors your SBOM against live CVE feeds (NVD, OSV, GitHub Advisory) and alerts you when new vulnerabilities affect existing components.
3. Issue VEX statements. When a CVE is found in a component, document whether the product is affected, not_affected, fixed, or under_investigation. CycloneDX VEX is the format; Dependency-Track manages the workflow. See the VEX guide for details on the process.
4. Report to ENISA. From September 2026, the CRA requires reporting actively exploited vulnerabilities to ENISA within 24 hours. See the ENISA reporting guide for the exact workflow. Dependency-Track combined with VEX is the operational foundation you need to be ready.

Common Mistakes to Avoid

1. Trusting Syft alone on firmware. Syft only sees package-managed components. Any library compiled directly into the binary, without a package database entry, will be invisible. Always combine Syft with cve-bin-tool or blint.

2. Ignoring high-entropy regions. binwalk silently skips encrypted partitions. Run entropy analysis before extraction (binwalk -E); document any gaps explicitly in the SBOM.

3. Forgetting the bootloader. U-Boot, coreboot, and GRUB are firmware components with real CVEs. They live outside the OS filesystem and are missed by most tools unless explicitly targeted. Your SBOM must include the bootloader.

4. Treating analyzed SBOMs as authoritative. A post-build reverse-engineered SBOM is an approximation. Mark components with confidence levels. Use CycloneDX's evidence field to document how each component was identified: string match, package database, binary hash, or manual entry.

5. No lifecycle plan. One SBOM at a single point in time satisfies no compliance requirement. New CVEs are published daily. Without ongoing monitoring via Dependency-Track or equivalent, your SBOM becomes stale within weeks.

6. ODM blob gap. If your hardware ships with firmware from an ODM or chip vendor, you cannot analyze what you didn't build. Fix this contractually: require SBOM delivery from your firmware suppliers. This is not optional under the CRA: you are responsible for the full product.

CRA Compliance Checklist for Firmware Manufacturers

Deadline: CRA main obligations apply from December 11, 2027. Vulnerability reporting to ENISA begins September 11, 2026. You need an operational SBOM pipeline before September 2026, not December 2027. See the CRA implementation timeline for the full picture.

□ Identify all firmware components in your products (the SBOM)
□ Choose your approach: build-time (Yocto/Buildroot) or post-build (EMBA/Syft/cve-bin-tool)
□ Generate SBOM in CycloneDX JSON format (use SPDX as well for open-source license compliance)
□ Include bootloader, kernel, all userspace packages, and any vendor blobs (or document them as gaps)
□ Ingest SBOM into Dependency-Track (or equivalent) for ongoing monitoring
□ Establish a VEX workflow for documenting exploitability status of CVEs
□ Set up reporting pipeline ready for ENISA from September 2026
□ Require SBOM delivery from all firmware component suppliers (ODMs, chip vendors)
□ Regenerate SBOM on every firmware build and track changes over time
□ Document your SBOM generation methodology for audit purposes

How CRA Evidence Helps

CRA Evidence tracks your firmware SBOMs alongside Digital Product Passports, conformity assessments, and technical documentation in a single compliance workspace. Upload your CycloneDX SBOM directly to a product version: it becomes the live component inventory for that release, linked to your vulnerability reports and VEX statements. When ENISA reporting is required, the data is already structured and accessible.

Upload your first SBOM or start a free trial to see how it integrates with your firmware workflow.

Firmware SBOMs are not optional under the CRA: they are the foundation of everything the regulation requires. Knowing your components, monitoring vulnerabilities, and reporting incidents all start here. The tools exist, the workflows are proven, and starting now gives you both a compliance advantage and documentation you can share with customers and authorities. Pick the right workflow for your situation: build-time if you can, binary analysis if you must. Operationalise it before the September 2026 reporting deadline.