What is an SBOM? A software bill of materials for firmware teams

01The short answer

An SBOM (software bill of materials) is a machine-readable list of the components inside a piece of software or firmware: which open-source libraries it contains, in which versions, where they came from and how they depend on each other. When a new vulnerability is published, it lets you answer "which of our products ship this library, and in which version?" in minutes. Under the CRA, products with digital elements placed on the EU market need one.

Think of it as the software counterpart of the bill of materials on a production line. The difference is that software components change with every release, so an SBOM is not a document you write once and file. It is a build output, produced again for every firmware version.

02What goes into an SBOM?

Whatever the format, a useful SBOM carries roughly the same facts for each component:

• Name and version: openssl and 3.0.13, for example. An entry without a version either matches nothing or pulls in every vulnerability the library ever had.
• Supplier: whoever wrote or delivered the component. For open source that is usually the project; for closed code, the company that shipped you the SDK.
• Unique identifiers: a PURL (pkg:generic/openssl@3.0.13) and a CPE. Vulnerability databases find components by these keys, not by name.
• Hash: the SHA-256 or SHA-512 digest of the file. It proves the entry describes the file that is actually in the image.
• Dependency relationships: which component uses which. This is how you trace how a vulnerability got into the product.

Here is a cut-down CycloneDX example for a router firmware. A real file has hundreds of components; the hash is shortened here:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "metadata": {
    "component": { "bom-ref": "fw", "type": "firmware",
                   "name": "router-fw", "version": "2.4.1" }
  },
  "components": [
    { "bom-ref": "busybox", "type": "application",
      "name": "busybox", "version": "1.36.1",
      "purl": "pkg:generic/busybox@1.36.1" },
    { "bom-ref": "openssl", "type": "library",
      "name": "openssl", "version": "3.0.13",
      "cpe": "cpe:2.3:a:openssl:openssl:3.0.13:*:*:*:*:*:*:*",
      "hashes": [{ "alg": "SHA-256", "content": "…" }] }
  ],
  "dependencies": [{ "ref": "fw", "dependsOn": ["busybox", "openssl"] }]
}

metadata.component is the product itself, the firmware. The dependencies block says the firmware depends on busybox and openssl. We gave openssl a CPE and busybox a PURL; in practice, writing both for every component improves the match rate.

03SPDX and CycloneDX

Both formats are mature, and both meet the CRA's "commonly used and machine-readable" condition. The choice is usually made by what your customers or your tooling expect, and converters between the two exist.

The file name often gives it away. SPDX JSON files usually end in *.spdx.json (Microsoft's sbom-tool writes manifest.spdx.json, for example), while CycloneDX files are typically called bom.json, bom.xml or *.cdx.json.

04Why SBOMs are hard for embedded devices

For a web application, the SBOM falls out of the lock file (package-lock.json, poetry.lock): the dependencies are already written down. Firmware rarely has such a file, and when it does, it tells only part of the story.

• What ships is the build output, not the source. A patch may have been applied during the build, a feature switched off, or a package left out of the image altogether. A list taken from the source tree drifts away from what is really in the image. The Yocto image manifest or Buildroot's make legal-info output is a good starting point because it lists what went into the image.
• Statically linked libraries. mbedTLS or zlib linked statically into a service is not a separate file on the filesystem and does not show up in any package list. Its vulnerabilities still ship with the product. Finding it takes binary analysis: version strings, signatures of known functions.
• RTOS and SDK components. Microcontroller firmware has no package manager. The RTOS kernel, the TCP/IP stack, the TLS library and the vendor HAL are copied into the project as source and compiled into one binary. The version often survives only in a header file or someone's commit message.
• Closed code from suppliers. The Wi-Fi driver, the Bluetooth stack or the modem firmware arrives as a binary. Only the supplier knows what is inside, which is why a machine-readable SBOM from the supplier is turning into a clause for the purchase contract.

In practice the most reliable result comes from combining two sources: the packages the build system knows about and what binary analysis finds in the image. Each catches what the other misses.

05What the CRA requires

Article 3(39) defines an SBOM as a formal record containing details and supply chain relationships of the components included in the software elements of a product with digital elements. The obligation itself is in Annex I Part II(1): the manufacturer identifies and documents vulnerabilities and components in its products, including by drawing up an SBOM in a commonly used and machine-readable format covering at the very least the top-level dependencies.

• The SBOM is part of the technical documentation (Annex VII, point 2(b)).
• A market surveillance authority can ask for it with a reasoned request, where it needs it to check compliance with Annex I (Annex VII, point 8).
• There is no duty to publish it; recital 77 says so explicitly. If you choose to make it available to users, the user information says where to find it (Annex II, point 9).
• The Regulation does not name a format. Article 13(24) allows the Commission to specify the format and elements of the SBOM by implementing act.
• The obligation applies from 11 December 2027, together with the rest of the Regulation.

BSI TR-03183-2 asks for more

TR-03183-2, the technical guideline from Germany's Federal Office for Information Security (BSI), goes well beyond "at the very least the top-level dependencies". Version 2.1.0, dated August 2025, sets out the following:

• A newly generated SBOM is JSON or XML, in CycloneDX 1.6 or later or SPDX 3.0.1 or later.
• Dependencies are resolved recursively along every path in the scope of delivery, at least down to the first component outside it.
• Required fields include the SBOM's creator and timestamp, and for each component its creator, name, version, filename, dependencies, distribution licences and the SHA-512 hash of the deployable file.

TR-03183 is not a CRA harmonised standard. It is, however, one of the few public documents that describe SBOM content in this much detail, and it works well as a checklist when you design your SBOM pipeline.

06The US 2026 SBOM minimum elements (CISA)

On 29 July 2026 the US Cybersecurity and Infrastructure Security Agency (CISA) published "2026 Minimum Elements for a Software Bill of Materials (SBOM)". It replaces the minimum elements NTIA published in 2021 and was written with 17 partner organisations, among them the NSA and FBI, Germany's BSI, France's ANSSI and the Netherlands' NCSC-NL. The document says the minimum elements create no new requirements; they refine how organisations should generate and request SBOMs.

The minimum elements come in two groups:

• Data fields (17): for the SBOM itself, the author, author signature, data format name and version, generation context, timestamp, tool name and version, and SBOM version; for each component, its name, version, producer, identifiers, hash value and hash algorithm, licence and dependency relationship.
• Practices and processes (6): accommodating updates and corrections to SBOM data, coverage, distribution and delivery, explicitly identifying unknown information, frequency (a new SBOM for every release) and machine-processable data (SPDX and CycloneDX being the widely used formats today).

The CRA does not refer to this document; the CISA document, for its part, names the CRA as an EU regulation that requires an SBOM in the technical documentation. The two approaches do not conflict, but they do not ask for the same depth. The CRA asks for an SBOM in a commonly used, machine-readable format covering at least the top-level dependencies. The CISA document asks for every component including transitive dependencies, sets no minimum depth, and counts the hash value, licence and author signature among the minimum fields. An SBOM built to the CISA document goes beyond the CRA's minimum in coverage and format; the reverse is not always true. On the EU market, what counts is still the CRA and any implementing act the Commission may adopt under Article 13(24).

07SBOM and VEX

An SBOM answers "what is inside?". Match it against a vulnerability database (OSV, NVD) and you get a raw list: openssl 3.0.13 is present, and these CVEs affect that version. Not every entry on that list affects your product; the vulnerable code may not be compiled in, or may never be called.

VEX (Vulnerability Exploitability eXchange) answers the second question: are we affected? Each vulnerability gets a status: affected, not affected (with a justification), fixed, or under investigation. CSAF 2.0 and OpenVEX are common ways to publish it, and CycloneDX can carry VEX in its own documents.

The two work as a pair. The SBOM is regenerated for every release; the VEX is updated as new vulnerabilities are published. A team without an SBOM cannot write VEX, and a team without VEX ends up answering every alert from every customer's scanner one by one.

08Common mistakes

• Generating the SBOM once and filing it. Every firmware version needs its own.
• Treating the list from the source tree as the truth about the image.
• Leaving versions empty.
• Skipping PURL and CPE; matching on similar names produces false alarms.
• Missing statically linked libraries and supplier binaries.
• Producing the SBOM and then not monitoring it. Components need watching for new vulnerabilities throughout the support period.
• Sending the raw vulnerability list to customers as it is. Without VEX it is mostly noise.

09Where to start

If you have lock files, a Yocto manifest or a Buildroot manifest.csv, our free SBOM scanner turns them into a CycloneDX or SPDX file and checks the components on OSV.dev. Files are read in your browser and never leave your computer. To try SBOM generation from the firmware image itself, VEX and continuous monitoring on your own image, see our pilot programme.

For where the SBOM sits among the other CRA obligations, see the CRA guide; for points specific to routers, modems and network devices, see network and telecom equipment.

10Frequently asked questions