SBOM

What is an SBOM?

An SBOM (Software Bill of Materials) is a formal, machine-readable list of all software components, libraries and their dependency relationships in a software product, firmware or embedded system, recording for each component the supplier, name, version and a unique identifier. An SBOM is comparable to the ingredients list on food packaging or the bill of materials of a machine: it does not describe what software does, but what it is built from. In OT environments, where a PLC, HMI panel or gateway often stays in service for ten to twenty years, that insight is needed to know quickly which installations are affected when a new vulnerability appears.

Modern software consists largely of reused open-source and commercial components. Without an SBOM, you do not know which of them run in your industrial systems.

🧠 Why is an SBOM important?

Vendors rarely build their products from scratch. An HMI runtime easily contains an operating system, a web server, a cryptographic library such as OpenSSL, a database and a third-party TCP/IP stack. When a vulnerability is found in one of those components, you need to know which products contain it. Some well-known examples:

The benefits of an SBOM at a glance:

• Transparency - insight into all open-source and commercial components in use
• Rapid vulnerability analysis - matching CVEs to known libraries and dependencies
• Supplier risk management - understanding where third-party software comes from, including sub-suppliers and high-risk suppliers
• Faster incident response - when a flaw such as Log4Shell becomes public, determining within hours rather than weeks whether your assets are affected
• Licence management - visibility of open-source licences and the obligations that come with them

🔧 What data does an SBOM contain?

On 12 July 2021 the US NTIA published the Minimum Elements for a Software Bill of Materials, following Executive Order 14028 of May 2021. That document defines seven minimum data fields and has become the global starting point:

Besides these fields, NTIA specifies automation support (a machine-readable format) and fixed practices and processes: a new SBOM for every new software version, a clearly stated depth and honest disclosure of known gaps. In August 2025 CISA published a draft update that adds, among other things, a hash per component, licence information, the tool used and the generation context.

CISA also distinguishes six SBOM types by when they are created: Design (planned design), Source (from source code), Build (during compilation), Analyzed (derived afterwards from a binary), Deployed (what is installed on a system) and Runtime (what is actually loaded). For OT firmware you will mostly see Build SBOMs from the manufacturer and Analyzed SBOMs that an asset owner creates itself.

🧩 Which formats and standards exist?

Vendors usually deliver an SBOM as a JSON or XML file in SPDX or CycloneDX format. The German BSI guideline TR-03183-2, often used as a reference for the Cyber Resilience Act, has required at least CycloneDX 1.6 or SPDX 3.0.1 since version 2.1.0 (August 2025).

🏭 What does an SBOM look like in an OT context?

OT has some specific challenges. Firmware often contains compiled code without a package manager, so an Analyzed SBOM produced by binary analysis can be incomplete. Many field devices pre-date the SBOM era, and a manufacturer’s SBOM describes a product version, not your specific installation with its own firmware level. Always link the SBOM to the exact firmware and software version in your asset inventory.

🔐 How do you use an SBOM for cybersecurity?

An SBOM on its own often produces a long list of CVEs, most of which cannot be reached in the product. Only with VEX information from the manufacturer and context from your own network do you get a workable priority list. An SBOM also does not prevent an attack: it shortens the time between the disclosure of a vulnerability and your response.

⚖️ Which laws and regulations require an SBOM?

Under the CRA, the manufacturer does not have to make the SBOM public; market surveillance authorities can, however, request it. The European Commission may specify the format and minimum content further through an implementing act. For buyers in the Netherlands the value lies mainly in procurement: organisations within the scope of the Cyberbeveiligingswet must manage supply chain risks, and an SBOM is a concrete means of doing so. In September 2025, 21 cybersecurity agencies from fifteen countries, including CISA, the NSA, the German BSI and the Dutch NCSC, published a shared vision of SBOMs for cybersecurity.

✅ How do you introduce SBOMs step by step?

1. Include SBOM requirements in procurement - ask every new supplier for an SBOM in SPDX or CycloneDX format with each release, plus VEX or CSAF advisories; record this in your Third Party Risk Management and in contracts based on IEC 62443-2-4 and ISO 27036.
2. Link SBOMs to your inventory - store them next to the asset and version data in your Asset Inventory or CMDB, so you know which components run in each installation.
3. Automate the comparison - let a tool such as the open-source OWASP Dependency-Track compare the SBOMs against vulnerability databases daily.
4. Prioritise with context - combine the result with VEX, the KEV catalogue and the network position of the device before planning a patch or compensating measure.
5. Fill the gaps - for older equipment without an SBOM, have an Analyzed SBOM produced or ask the supplier for a component overview.
6. Safeguard integrity - combine SBOMs with Code Signing, Secure Boot and controlled updates to keep a grip on the entire supply chain.

❓ Frequently asked questions

Is an SBOM mandatory?

An SBOM is mandatory for manufacturers of products with digital elements under the Cyber Resilience Act from 11 December 2027, and in the US for medical cyber devices under the FDA rules. NIS2 and the Dutch Cyberbeveiligingswet do not oblige buyers to obtain an SBOM, but they do require supply chain risks to be managed. Many organisations therefore include the SBOM as a requirement in their purchasing terms.

What is the difference between SPDX and CycloneDX?

SPDX is an SBOM format from the Linux Foundation, standardised as ISO/IEC 5962, that originated in licence management. CycloneDX is an SBOM format from OWASP, standardised as ECMA-424, that has focused on security from the start and also supports VEX. Both formats are accepted by most tools and by the German BSI guideline TR-03183-2.

What is the difference between an SBOM and VEX?

An SBOM tells you which software components a product contains, but not whether a vulnerability in such a component can actually be exploited in that product. A VEX document from the manufacturer states for each vulnerability whether the product is affected or not. Together, SBOM and VEX prevent you from wasting time on false positives.

Does a manufacturer have to publish its SBOM?

Under the Cyber Resilience Act a manufacturer does not have to make the SBOM public; it belongs in the technical documentation and must be provided to market surveillance authorities on request. Buyers therefore usually only receive an SBOM if they agree on it contractually. Some manufacturers offer SBOMs through a customer portal.

How do you create an SBOM for existing OT equipment?

For existing OT equipment without an SBOM from the manufacturer, you can derive an Analyzed SBOM from firmware images using binary analysis tools. Such a derived SBOM is often incomplete, because statically linked or modified code is hard to recognise. Always ask the supplier for a component overview first.

How often should an SBOM be updated?

An SBOM should be updated with every new software or firmware version, because each release can contain different components or versions. The list of known vulnerabilities changes daily, however, so existing SBOMs should be compared against vulnerability databases continuously or at least daily. The SBOM itself only changes when the product changes.

📌 In summary

An SBOM is the machine-readable ingredients list of software and firmware: it makes visible what really runs in your industrial systems, so that you know within hours which installations are affected by a new vulnerability.

SPDX and CycloneDX are the common formats, the NTIA minimum elements define the basic content and the Cyber Resilience Act makes the SBOM mandatory for manufacturers from December 2027. Combined with VEX, an up-to-date asset inventory and vulnerability management, the SBOM forms a foundation for supplier transparency, cybersecurity and compliance in OT.