Ask a controls engineer to walk you through the PLCs, HMIs, and drives on a line and you’ll get a precise answer inside two minutes — vendor, model, firmware revision, maybe the panel drawing number. Ask that same engineer what open-source libraries are compiled into that firmware and you’ll get a shrug. That gap is the whole problem. A modern automation controller or HMI runtime is built on a stack of third-party and open-source components — TLS libraries, compression utilities, RTOS kernels, web servers for the embedded config pages — and any one of them can carry a CVE that has nothing to do with the vendor’s own code. Without a bill of materials, you find out about that exposure the way most plants still do: a CISA ICS advisory lands, and someone starts guessing.
That’s the gap CISA has been steadily closing since the secure-by-design pledge and the NIST CSF 2.0 update, and it’s why software bills of materials are moving from “nice-to-have vendor artifact” to an expected input in OT vulnerability management. The direction of travel is clear even where hard mandates aren’t yet in force everywhere: asset owners are going to be expected to ingest SBOMs, not just receive them as PDFs to file away.
Why CSF 2.0 changes the calculus
NIST CSF 2.0 added the Govern function and sharpened supply chain risk management language throughout the framework, explicitly pulling software provenance and component-level visibility into what “identify” and “protect” mean in practice. Combine that with CISA’s secure-by-design pledge — which asks participating vendors to make measurable progress on things like memory-safe roadmaps, default hardening, and providing SBOMs in standard formats — and the writing’s on the wall. Auditors and insurers are increasingly going to ask not “do you patch,” but “can you show me, for this specific controller, which CVEs affect which components, and how you knew.”
Most plants cannot answer that question today. Not because nobody cares, but because nobody built a pipeline for it. SBOMs, when they arrive at all, tend to land as static PDFs attached to a sales quote or a compliance questionnaire response — human-readable, unsearchable, and functionally useless for automated vulnerability correlation.
What a useful SBOM actually looks like
A machine-readable SBOM means one of two formats: CycloneDX or SPDX. Both are structured, both are supported by free tooling, and both let you do the thing a PDF can’t — programmatically match component names and versions against vulnerability databases. Pair that with a VEX (Vulnerability Exploitability eXchange) document, and you get something genuinely actionable: not just “this firmware contains OpenSSL 1.1.1,” but “this specific CVE in that OpenSSL version is not exploitable in our product because the vulnerable code path is never invoked.” VEX is what turns an SBOM from a inventory list into a triage tool — it tells you what to ignore, which is often more valuable than what to act on.
If a vendor sends you an SBOM without VEX data, you still have an inventory, which is worth something. If they send you a PDF with no structured data at all, you have a marketing document.
What to actually ask vendors for
- Format: CycloneDX or SPDX, not a PDF or spreadsheet. Say this explicitly in the request — vendors will default to whatever’s easiest for them unless pushed.
- Component-level depth: not just top-level libraries but transitive dependencies where feasible. A vulnerable component two layers deep is still a vulnerable component.
- VEX statements tied to advisories: when the vendor publishes a security advisory, ask that it reference the affected SBOM components and include exploitability status.
- A refresh cadence: SBOMs tied to firmware/software releases, not a one-time artifact from three product generations ago.
- A delivery mechanism you can automate against: an API endpoint or a predictable portal location, not an email attachment that a salesperson forwards when they remember.
Rockwell, Siemens, and Schneider Electric have all been publishing security advisories and increasing SBOM/VEX availability for parts of their portfolios as part of broader transparency commitments tied to secure-by-design participation. Coverage and format maturity varies by product line and is still uneven — don’t assume every controller family has an equally polished SBOM program just because the vendor’s flagship platforms do. Ask per product line, not per vendor.
Building the ingestion workflow, realistically
You don’t need a full software composition analysis platform to start. You need three things working together: an asset inventory with firmware versions, a place to store SBOMs tied to those assets, and a way to cross-reference component versions against the National Vulnerability Database or CISA’s known-exploited-vulnerabilities catalog when a new CVE drops. Open-source tools like Dependency-Track can ingest CycloneDX SBOMs and do that correlation automatically, flagging which of your assets contain a newly disclosed vulnerable component. That’s the difference between a fire drill and a filtered list.
The practical sequencing that works in most plants:
- Inventory OT assets by vendor, model, and firmware/software version — you likely already have most of this in a CMMS or asset register.
- Request SBOMs for your highest-criticality assets first — the controllers and HMIs on safety-relevant or production-critical lines, not the whole plant at once.
- Stand up a lightweight SBOM repository (even Dependency-Track’s free tier) and load what you get.
- When a CVE or ICS advisory drops, query the repository for affected components before anyone touches a line — this replaces the “does this affect us” all-hands scramble with a five-minute lookup.
- Push back on vendors who send PDFs. Document the request in writing and escalate through your account team; secure-by-design pledge participation gives you real leverage here.
What to do when you get the useless PDF anyway
It happens, and it’ll keep happening for parts of the OT vendor ecosystem that haven’t caught up. Don’t just file it. Extract what you can manually — component names and versions — into a spreadsheet or lightweight database, and treat it as a stopgap inventory rather than a dead end. More importantly, use it as documented evidence in your next vendor conversation: “we requested CycloneDX and received a PDF” is exactly the kind of gap that shows up in audit findings and vendor risk scorecards, and vendors respond to that pressure faster than to a general ask for “better security.”
The plants that get ahead of this aren’t the ones with the biggest security budgets — they’re the ones who started asking vendors the right question, in the right format, before the next advisory forced the issue. CVE disclosures aren’t slowing down, and neither is regulatory pressure on supply chain transparency. The choice isn’t whether you’ll eventually have an SBOM ingestion process. It’s whether you build it deliberately now or bolt one together during an incident.
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.
