SBOM

An SBOM, or Software Bill of Materials, is a structured list of all software components that make up a system, application, device, or equipment. It typically includes information about each component’s name, version, supplier, and dependency relationships.

In industrial and regulated manufacturing environments, SBOMs are applied to OT assets such as PLCs, HMIs, data historians, gateways, and embedded systems inside OEM equipment, as well as to supporting IT applications like MES, historians, and integration middleware. The SBOM is maintained across the asset lifecycle so that security, quality, and engineering teams can identify which systems may be affected when a software vulnerability or defect is disclosed.

What an SBOM includes

While formats and depth vary, an SBOM commonly includes:

• A list of software components (first-party and third-party, including open-source libraries and firmware modules)
• Component versions and, where available, unique identifiers
• Component supplier or origin information
• Dependency relationships (which components are built on top of others)
• Basic metadata such as creation date and SBOM authoring tool

In an OT or OEM equipment context, SBOMs may cover embedded operating systems, runtime environments, drivers, protocol stacks, and pre-installed applications that ship as part of the machine control system.

Operational use in manufacturing environments

In industrial operations, SBOMs are used to:

• Support vulnerability management by mapping public vulnerability disclosures to affected assets
• Inform cybersecurity risk assessments for new equipment or software deployments
• Support change control when components are updated, replaced, or removed
• Provide transparency in OEM and supplier contracts for software content inside equipment
• Assist with incident response by quickly identifying where a vulnerable component is deployed across sites

SBOMs may be requested from OEMs as part of equipment procurement and are often referenced alongside requirements for patching, hardening baselines, remote access control, and logging expectations.

What an SBOM is not

• It is not a configuration baseline of running system settings or policies.
• It is not a detailed design document or source code repository.
• It is not a vulnerability report, although it supports vulnerability analysis.
• It is not a parts list for physical components; that role is handled by a traditional Bill of Materials (BOM).

Common confusion

• SBOM vs BOM: A traditional Bill of Materials lists physical parts, materials, and assemblies. An SBOM lists software components and their relationships. Many complex products need both.
• SBOM vs asset inventory: An asset inventory tracks systems and devices (for example, specific PLC models, servers, and workstations), often with location and owner. An SBOM describes the software content inside those assets.
• SBOM vs vulnerability scan results: Vulnerability scan reports show detected weaknesses on a system at a point in time. An SBOM is a structural description of software components that scanners and other tools can use as input.

Tie to OEM equipment contracts

In OEM equipment contracts for regulated manufacturing, SBOMs are often referenced when defining cybersecurity responsibilities. Contracts may specify whether the OEM must provide an SBOM for delivered equipment, how it will be updated over time, and how it will be used to notify the site of vulnerabilities in included components. This supports clearer expectations for patching, change control, lifecycle support, and incident response.