Somewhere in your document management system, there’s probably already a PDF called something like “Vendor_SBOM_2024.pdf” that nobody has opened since the day it was filed. That’s the default fate of software bills of materials in OT environments right now: a compliance artifact collected because a customer or auditor asked for it, not a tool anyone actually uses. CISA’s continued push toward mandatory SBOMs for industrial control system suppliers is about to make that habit expensive, because the volume of these documents is going up and the expectation that you can act on them is going up with it.
The thesis here is simple and a little uncomfortable: an SBOM that sits in a folder is worse than useless, because it gives you the feeling of visibility without the substance of it. If you’re not mapping vendor SBOMs to CISA’s Known Exploited Vulnerabilities catalog and your own compensating-controls posture, you don’t have an SBOM program. You have a filing cabinet.
Why this is happening now
NIST and CISA have spent the last several years building out the machine-readable plumbing for software transparency — formats like SPDX and CycloneDX, the VEX (Vulnerability Exploitability eXchange) standard for stating whether a known vulnerability in a component actually affects the product it’s bundled into, and secure-by-design guidance that increasingly names SBOM delivery as a baseline expectation rather than a nice-to-have. Executive-branch software supply chain requirements pushed this hard in IT first. OT vendors — PLC, HMI, drive, and industrial networking suppliers — are catching up, partly because their customers in critical infrastructure sectors are now contractually requiring it, and partly because CISA has been explicit that ICS is a priority area for supply chain transparency.
The reason this matters to you, specifically, is that the OT patching problem has always been a visibility problem before it’s a scheduling problem. You can’t triage a vulnerability in a third-party TLS library or a compression codec if you don’t know your HMI runtime is using it. SBOMs are supposed to fix that. Most of the ones currently landing in plant IT inboxes don’t.
The checkbox SBOM, and how to spot one
A checkbox SBOM is easy to produce and easy to recognize once you know what to look for. It typically has some combination of these traits:
- It’s a PDF or a static spreadsheet, not a machine-readable file. If you can’t ingest it into a vulnerability management tool without manual transcription, it was built to satisfy a contract clause, not to support ongoing risk analysis.
- It lists top-level components only. You’ll see the operating system and maybe a database engine, but not the transitive dependencies — the open-source libraries those components pull in — where most real-world exploited vulnerabilities actually live.
- No version pinning, or stale versions. A component list without specific version numbers tells you almost nothing. A component list with version numbers that haven’t been updated in several release cycles tells you the SBOM isn’t tied to your actual firmware revision.
- No VEX statements. This is the tell that separates a mature program from a paperwork exercise. Without VEX, every CVE that touches a listed component reads as “affected,” which either buries you in false positives or trains your team to ignore the document entirely.
- No update cadence commitment. A one-time SBOM delivered at product launch is a snapshot of a product that no longer exists by the time you’re running it. Ask when the vendor regenerates and reissues it — tied to firmware releases, ideally, not to an annual calendar reminder.
A real SBOM, by contrast, comes in SPDX or CycloneDX format, enumerates transitive dependencies, is versioned to a specific firmware or software build, and is paired with (or supersedes into) a VEX feed that tells you which known vulnerabilities in those components are actually exploitable in the context of that product — because plenty aren’t. A vulnerable logging library that’s compiled in but never invoked on an attacker-reachable path is a very different problem than one sitting on the network-facing service.
Wiring it into procurement, not just security review
The mistake most plants make is treating SBOM review as a security team task that happens after the purchase order is signed. By then you have no leverage. SBOM requirements belong in the RFQ.
Practical asks to put in front of PLC, HMI, drive, and networking vendors before you buy:
- Machine-readable format (SPDX or CycloneDX), delivered per release, not per contract signature.
- A committed SBOM refresh cadence tied to firmware or software versions, not an arbitrary schedule.
- VEX statements or equivalent exploitability guidance alongside the raw component list.
- A named channel — not a generic support inbox — for reporting a component vulnerability you found in their SBOM before they’ve disclosed it.
- Clarity on how the vendor handles end-of-life components still present in shipped SBOMs, since ICS gear often runs a decade or more past when its embedded Linux distro or crypto library stopped getting upstream patches.
If a vendor can’t answer these in a sales cycle, that’s useful information. It doesn’t necessarily disqualify them — a lot of respected OT suppliers are mid-transition on this — but it tells you what your compensating-controls burden is going to look like for the life of that asset, which should factor into total cost of ownership the same way spare parts availability does.
Turning the SBOM into patch triage, not patch panic
Once you have real SBOMs, the workflow that makes them worth the effort looks like this: when a new CVE lands, or CISA adds something to the KEV catalog, you search your SBOM inventory for the affected component and version — not the product name. Product-level vulnerability tracking misses the fact that three different HMI models from three different vendors all embed the same vulnerable image-parsing library. Component-level tracking catches it.
From there, cross-reference against KEV status specifically. A CVE with a high CVSS score but no evidence of active exploitation is a scheduling problem — patch it in your normal maintenance window. A CVE on the KEV list touching a component you’ve confirmed is present, on a device you can’t take offline this week, is a compensating-controls problem right now: network segmentation, tightened firewall rules on that VLAN, disabling an exposed service, adding detection rules on the OT network monitoring tool you already own. The SBOM is what tells you which of those two buckets you’re in, instead of guessing based on a vendor’s vague security bulletin.
What to actually do this quarter
You don’t need a mature software supply chain security program to start getting value out of this. You need three things: a place to store SBOMs that supports search and version comparison rather than a shared drive folder, a standing procurement requirement that SBOMs be machine-readable and versioned, and a triage habit that checks new KEV entries against your component inventory instead of waiting for a vendor bulletin to tell you you’re exposed. None of that requires new headcount. It requires deciding that the SBOM is a working document instead of a receipt.
CISA tightening the mandate is not going to change your risk posture by itself. Vendors sending you better files changes nothing if the files still go straight into the same folder. The plants that actually get safer from this shift will be the ones that make the SBOM somebody’s job.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
