A steel mill can ask each equipment supplier for a software bill of materials that lists the software components inside furnace controls, rolling line drives and monitoring systems. The SBOM will not secure the machine, but it lets you answer one urgent question quickly: does a newly announced flaw affect anything on our floor?
CISA describes an SBOM as a nested inventory, a list of the ingredients that make up software components. CISA's SBOM page does not address operational technology specifically, and directs OT and hardware questions to its SBOM mailbox and resources library. This post applies the general idea to a plant, and we are not citing any steel-specific standard.
Why do machines and firmware need this?
A mill runs equipment from many vendors across decades: programmable controllers, drives, human machine interfaces, vision systems, historians and engineering laptops. Each runs an operating system or firmware that bundles open source libraries. When a library flaw is announced, nobody at the mill wrote that code, and the vendor may not volunteer whether it applies.
NIST SP 800-82 Revision 3 notes that OT security must account for performance, reliability and safety. That means patching is slow and often impossible on short notice, so knowing exactly where exposure sits is the first step to choosing compensating controls.
What should you ask suppliers for?
- An SBOM for each product and firmware version, in a standard format such as SPDX or CycloneDX.
- A named contact and process for reporting vulnerabilities.
- A support period for the product and its software.
- A statement on how updates are signed and delivered.
- A way to learn when a component flaw does or does not affect their product.
The ISA/IEC 62443 series gives a shared structure for the conversation: asset owners, product suppliers, integrators and service providers each have defined responsibilities, and part 4-1 covers secure product development lifecycle requirements. Referencing it in procurement text sets expectations.
What do you do with an SBOM when you have it?
Store it with the asset record. Tie each SBOM to a specific machine and firmware version in your inventory.
Match it to known flaws. When a vulnerability is announced, search your stored SBOMs for the affected component and version. This is the step that turns a document into an answer.
Triage by exposure. A flawed component inside a machine on an isolated segment is lower urgency than one on a machine with remote access.
Ask the vendor. If the SBOM shows a flawed component, ask whether the vulnerable code is reachable in their product. Reachability analysis, which checks whether vulnerable code can actually be triggered, is part of how Safeguard assesses software you build, and the question is the same for a supplier.
Track changes. A new firmware version should come with a new SBOM, and you should compare the two.
What are the limits?
Suppliers may not provide an SBOM, or may provide an incomplete one. Format and depth vary. An SBOM lists components but not whether the product is configured safely. And you cannot generate one yourself for firmware you do not have.
For software your team writes, such as data collection or integration tools, Safeguard can generate SBOMs and findings directly.
See the inventory idea at /demos/sca-dependency-inventory.
What to do
- List the machines and systems with firmware or embedded software.
- Add SBOM and vulnerability contact requirements to purchasing terms.
- Send existing suppliers a standard request and track who responds.
- Store each SBOM against the asset record and firmware version.
- Practice a flaw announcement drill: find affected systems in under a day.
- Generate SBOMs for the software your own team builds.
Quick check
Is an SBOM the same as a vulnerability report?
No. An SBOM lists components. You compare it with vulnerability data to find what is affected.
What if the vendor will not provide one?
Record it as a risk, raise it in procurement, and use network isolation and monitoring as compensating controls.
Sources
Last reviewed: 18 October 2026.
