Engineers with a laptop at automation test rigs in a bright production hall

SBOM

Firmware SBOM: how to build one when you only have the binary

Last updated:

A firmware SBOM (software bill of materials) — which the Cyber Resilience Act's Annex I Part II point (1) requires — lists every software component inside a device image: bootloader, kernel, libraries, daemons, vendor SDK modules and their versions. When you do not have the source code, you build it by binary analysis of the firmware image. Export it as CycloneDX or SPDX, pair it with VEX statements so only real issues remain, and keep one per release: the Cyber Resilience Act requires a machine-readable SBOM covering at least top-level dependencies.

By SoftWSP Firmware Security Desk5 min read

Key takeaways

  • Most connected products are built along a chain: chip vendor → SDK or board support package → ODM → brand.
  • Statically linked or stripped code is harder to identify; versions may be ranges.
  • Both qualify as "commonly used and machine-readable" in the sense of CRA Annex I.
  • An old embedded Linux image can match hundreds of CVEs.

Why do device makers often have no source code?

Most connected products are built along a chain: chip vendor → SDK or board support package → ODM → brand. The brand that sells the product under its name is the CRA "manufacturer", but often receives only a finished binary. Other common reasons:

  • the chip vendor's SDK is frozen on an old kernel and toolchain;
  • the original build environment is lost or the engineer has left;
  • dozens of SKUs each ship a slightly different image.

You still need to know what is inside. Article 13(5) of the CRA requires due diligence on third-party components, and Annex I Part I (2)(a) requires shipping without known exploitable vulnerabilities.

How binary SBOM generation works

Step What happens Typical output
1. Unpack Identify the image format, decompress, extract file systems (for example SquashFS, UBIFS, JFFS2, CPIO) and nested archives Directory tree of the device root file system
2. Inventory Find executables, shared libraries, kernel modules, scripts, certificates and configuration files File list with hashes
3. Identify Match files to components using package databases if present, version strings, symbols, build IDs and known signatures Component name, version, supplier, confidence
4. Relate Link binaries to the libraries they load to show dependencies Dependency graph
5. Export Write a CycloneDX or SPDX document with hashes and identifiers (CPE, purl) SBOM file per firmware version
6. Match vulnerabilities Look up each component and version in vulnerability databases Candidate CVE list
7. Triage Decide per CVE whether the product is actually affected VEX statements

Limits you should state openly

  • Statically linked or stripped code is harder to identify; versions may be ranges.
  • Vendor patches (backports) can fix a CVE without changing the version string, which produces false positives.
  • Proprietary blobs may be identified only by supplier and hash.

Record a confidence level per component. A transparent, partial SBOM is more useful, and more defensible, than a "complete" one that is silently wrong.

CycloneDX vs SPDX for embedded firmware

Aspect CycloneDX SPDX
Standardisation Ecma International ECMA-424 (1st edition June 2024 = CycloneDX 1.6; 2nd edition December 2025 = CycloneDX 1.7) ISO/IEC 5962:2021 = SPDX 2.2.1; SPDX 3.0 in development at ISO
Origin OWASP, security-focused Linux Foundation, licence-compliance-focused
Vulnerabilities and VEX Native fields in the same document Typically via separate VEX documents or SPDX 3 security profile
Hardware and firmware Supports hardware and firmware component types Package, file and snippet level detail
Formats JSON, XML, Protocol Buffers JSON, tag-value, RDF and others

Both qualify as "commonly used and machine-readable" in the sense of CRA Annex I. Germany's BSI technical guideline TR-03183-2 accepts both formats and asks for more depth than the CRA minimum. The Commission may also specify SBOM format and elements by implementing act (CRA Art. 13(24)); no such act had been adopted at the time of writing.

Practical advice: generate CycloneDX if your main use is vulnerability management and customer exchange; add SPDX if customers or licence audits ask for it. Converters exist, but check that hashes and identifiers survive conversion.

VEX: turning a CVE list into a decision

An old embedded Linux image can match hundreds of CVEs. Many are not exploitable because the vulnerable function is not compiled in, the service is disabled, or the attack path does not exist on the device. VEX records that decision in machine-readable form.

According to CISA's VEX documents, each statement gives one product status:

Status Meaning
Not affected The product is not affected; a justification is given
Affected The product is affected; actions are recommended
Fixed The product contains a fix
Under investigation Still being assessed; the document will be updated

Justifications for "not affected" include: component not present, vulnerable code not present, vulnerable code cannot be controlled by an adversary, vulnerable code not in the execute path, and inline mitigations already exist.

VEX is also your evidence for Annex I Part I (2)(a): it shows you checked known vulnerabilities and why the remaining ones are not exploitable.

How an SBOM supports the CRA

CRA requirement How the SBOM helps
Annex I Part II (1): identify components, SBOM of top-level dependencies The SBOM itself
Annex I Part I (2)(a): no known exploitable vulnerabilities Basis for the pre-release vulnerability check
Annex I Part II (2): fix without delay Tells you within minutes which products a new CVE hits
Article 14: 24-hour early warning Lets you confirm affected versions fast; see CRA 24h reporting
Annex VII: technical documentation The SBOM is part of the vulnerability-handling description; authorities can request it
Annex II (9): user information If you choose to share the SBOM, tell users where to find it

Machine builders face a similar duty under the Machinery Regulation: section 1.1.9 of Annex III requires the machine to identify its safety-relevant software at all times. See Machinery Regulation cybersecurity.

A workable process for firmware teams

  1. One SBOM per released build, stored with the image hash.
  2. Prefer build-time SBOMswhere you control the build (Yocto, Buildroot and Zephyr can emit them), and use binary analysis to verify and to cover vendor blobs.
  3. Re-scan continuously: new CVEs appear daily for old components.
  4. Publish VEX with advisoriesso customers' scanners show the same picture as you.
  5. Ask suppliers for SBOMsin your contracts, including chip-vendor SDKs and ODM firmware.

SoftWSP builds SBOMs from firmware images without source code, triages vulnerabilities with VEX, and monitors each release afterwards: see device firmware security. For the regulation itself, start at the Cyber Resilience Act hub or the CRA checklist for device makers.

This guide is general information, not legal advice.

Put this guide to work

ServiceMachine BuildersMachine SBOM and vulnerability report per line.See the service
SBOM & VEXSBOM viewerOpen a CycloneDX or SPDX JSON SBOM and browse its components in a table. Parsing happens in your browser only.Free

Frequently asked questions

How do you generate an SBOM for embedded firmware to meet the EU Cyber Resilience Act?

Unpack each released firmware image, identify its file systems, binaries and libraries with binary analysis, match them to component names and versions, and export the result as CycloneDX or SPDX. Annex I Part II point (1) of the CRA requires a machine-readable SBOM covering at least top-level dependencies, kept in the technical documentation; produce one per firmware version and pair it with VEX statements.

Can you create an SBOM without source code?

Yes. Binary analysis unpacks the firmware image, identifies file systems, executables and libraries, and matches them to known components and versions using strings, symbols, signatures and package metadata. The result is less complete than a build-time SBOM and should state its confidence.

Should I use CycloneDX or SPDX for firmware?

Both are accepted machine-readable formats. CycloneDX is standardised as ECMA-424 and has built-in support for vulnerability and VEX data; SPDX 2.2.1 is published as ISO/IEC 5962:2021 and is strong on licensing. Pick the one your customers and tools consume; many teams produce both.

Does the Cyber Resilience Act require an SBOM?

Yes. Annex I Part II point (1) requires an SBOM in a commonly used, machine-readable format covering at least the top-level dependencies. It is part of the technical documentation, and market surveillance authorities can request it. Publishing it to users is optional.

What is VEX and why does it matter for firmware?

VEX (Vulnerability Exploitability eXchange) states whether a product is affected by a given vulnerability: not affected, affected, fixed or under investigation, with a justification for 'not affected'. It stops customers and scanners from flagging vulnerabilities in code your build does not use.

Sources

  1. Regulation (EU) 2024/2847 (Cyber Resilience Act), Annex I Part II and Annex VII, EUR-Lex
  2. Ecma International: ECMA-424 CycloneDX Bill of Materials specification
  3. ISO/IEC 5962:2021 – SPDX Specification V2.2.1
  4. CISA: Vulnerability Exploitability eXchange (VEX) – Status Justifications
  5. CISA: VEX Use Cases
Was this guide helpful?

All guides in this cluster: SBOM

AI-BOM for embedded AI devices: what it is, and what CycloneDX and SPDX actually defineA regular SBOM lists software components; it says nothing about a model baked into a device's firmware. What an AI-BOM / ML-BOM actually inventories, how CycloneDX's ML-BOM (since v1.5) and SPDX 3.0's AIPackage profile define it, and what a firmware or device maker should start recording.Cryptographic Bill of Materials (CBOM), explainedWhat a CBOM inventories that a regular SBOM doesn't, how CycloneDX standardized the format with IBM Research in 2024, and how Executive Order 14412 and OMB M-26-15 (June 2026) turned it into a dated federal and contractor requirement.CSAF 2.0 and VEX: machine-readable security advisories for device makersWhat OASIS CSAF 2.0 and the VEX profile are, how CISA's minimum requirements work, and how device makers can use them to automate PSIRT advisories.CycloneDX VDR: what a Vulnerability Disclosure Report is and how it differs from VEXCycloneDX's Vulnerability Disclosure Report (VDR) capability: what it contains, which schema fields it uses that VEX does not, and when a device maker needs a VDR instead of (or alongside) VEX.CycloneDX VEX: how the analysis state and justification fields workCycloneDX's own VEX capability: the analysis.state, justification and response enums a device maker's SBOM tooling actually reads, standalone vs embedded VEX, and which scanners act on it.CycloneDX vs SPDX: the two SBOM formats, comparedOWASP CycloneDX and Linux Foundation SPDX are the two SBOM data formats regulators actually name. What each covers, who maintains them, their standards-body status, and when device makers end up needing both.ENISA Guidelines for Securing the Internet of Things (supply chain), explainedENISA's November 2020 Guidelines for Securing the Internet of Things — the six-phase IoT supply chain reference model, its threat taxonomy, and the Actors/Processes/Technologies good-practice categories; reproduction authorised provided the source is acknowledged.ENISA's SBOM Technical Advisory, explainedENISA's October 2026 Technical Advisory for Software Bill of Materials: its lifecycle model, the STRIDE threat model it applies to the SBOM ecosystem, its CI/CD integration guidance, and why it is advisory rather than a legal reading of the Cyber Resilience Act.Executive Order 14028: Improving the Nation's Cybersecurity, explainedWhat EO 14028 actually mandated in 2021 — SBOM, critical software, zero trust, the attestation form — and what's changed by 2026: OMB's M-26-05 rescission of the government-wide attestation mandate.HBOM (Hardware Bill of Materials): CISA's framework explainedA software SBOM says nothing about the chips, boards and modules a device is actually built from. What CISA's September 2023 Hardware Bill of Materials Framework defines, how CycloneDX's device and firmware component types map to it, and what a device maker should start recording.in-toto, explained: supply chain layouts, links and attestationsThe in-toto framework for software supply chain integrity: layout and link metadata, the in-toto Attestation Framework's Statement/Predicate model, and how it underpins SLSA provenance.ISO/IEC 18974 (OpenChain Security Assurance Specification), explainedWhat ISO/IEC 18974:2023 actually requires: its four top-level clauses, the 18-month conformance window, how it differs from SBOM formats and ISO/IEC 5230, and why the full text is free.ISO/IEC 20243 (O-TTPS): mitigating maliciously tainted and counterfeit products, explainedWhat ISO/IEC 20243's two parts (requirements and assessment procedures) actually require, how The Open Group's O-TTPS standard became an ISO/IEC standard, its 2015-2023 revision history, and the accreditation program behind it.ISO/IEC 27036 (Cybersecurity — Supplier relationships), explainedWhat ISO/IEC 27036's four parts actually require: Part 2's certifiable requirements vs. Parts 1/3/4 guidance, the 2021-2023 revision wave, and how it ties to firmware SBOMs and NIST SP 800-161.NIST SP 800-161: Cybersecurity Supply Chain Risk Management (C-SCRM), explainedNIST SP 800-161 Rev. 1's three C-SCRM levels, its link to Executive Order 14028 and SP 800-53's supply chain control family, plus companion publications.NIST SP 800-218A (generative AI SSDF profile), explainedNIST SP 800-218A (July 2024): the EO 14110 mandate behind it, its three audiences, the new AI-specific PS.1.2/PS.1.3/PW.3 practices, its High/Medium/Low priority tags, and the EO 14110 definition of a dual-use foundation model.NIST SSDF (SP 800-218): the four practice groups, explainedNIST's Secure Software Development Framework, SP 800-218: its four practice groups, the link to Executive Order 14028, and the SP 800-218A AI profile.OpenSSF Best Practices Badge: the passing, silver and gold criteria, explainedThe OpenSSF Best Practices Badge (formerly CII Best Practices Badge) lets open-source projects self-certify against 67 passing-level criteria across 6 categories, with Silver and Gold tiers above it. What the project's own criteria document actually requires, and how OpenSSF Scorecard scores badge tier directly.OpenSSF Model Signing (OMS): Sigstore-based signing for ML models, explainedOMS v1.0, launched 4 April 2025 by the OpenSSF AI/ML Working Group with Google, NVIDIA and HiddenLayer: how Sigstore-based model signing works, who's using it, and how it relates to an AI-BOM and SLSA.OpenSSF Scorecard explained: how the 0-10 score is builtWhat OpenSSF Scorecard measures, its risk-weighted 0-10 scoring, the 20 checks it runs, and how to read a result before trusting a dependency.OpenSSF Security Baseline (OSPS Baseline): what it actually requiresWhat the OpenSSF Security Baseline is, its three maturity levels and control families, how it differs from OpenSSF Scorecard and the Best Practices Badge, and how it maps to the Cyber Resilience Act and NIST SSDF.OpenVEX: the minimal, embeddable VEX formatWhat OpenVEX is, its four status values and five not_affected justifications, how it meets CISA's Minimum Requirements for VEX, and how it compares to CycloneDX VEX and CSAF VEX.OWASP SCVS: the Software Component Verification Standard, explainedOWASP SCVS v1.0's three verification levels, its six control families totalling 87 requirements, and how NIST's SP 800-218 Secure Software Development Framework crosswalks specific SCVS requirement IDs into its own practices.OWASP Top 10 CI/CD Security Risks, explainedWhat the OWASP Top 10 CI/CD Security Risks project (CICD-SEC-1 through CICD-SEC-10) actually documents — flow control, pipeline identity, dependency chain abuse, Poisoned Pipeline Execution, PBAC and artifact integrity — and how it maps onto SLSA, in-toto and SBOM controls for a firmware build pipeline.Package URL (purl): the SBOM component identifier, explainedWhat a purl is, its pkg:type/namespace/name@version syntax standardized as ECMA-427, why CycloneDX and OSV require it, and how it differs from CPE.SBOM Minimum Elements: what a compliant SBOM must containWhat the 2026 CISA/NSA/FBI-led Minimum Elements for a Software Bill of Materials actually requires: the 17 data fields, 6 practices and processes, and what changed from the 2021 NTIA version.SLSA explained: supply-chain levels for software artifactsWhat SLSA v1.2's Build and Source tracks require at each level, who maintains the framework, and how it relates to firmware SBOM and secure build evidence.SPDX 3.0, explained: what changed for SBOMsWhat SPDX 3.0 (released April 2024) actually changed from SPDX 2.x — the nine-profile model, the RDF-based data graph, the new Security and AI profiles with built-in VEX relationships, and where it stands next to CycloneDX and ISO/IEC 5962.

Questions about this page?

hello@softwsp.com Chat with David on WhatsApp

Firmware SBOM: how to build one when you only have the binary

Try the SBOM viewerChat with David on WhatsApp