Every plant with a CISA ICS-CERT subscription knows the feeling: an advisory drops, it references a CVE in a PLC firmware version or an HMI runtime you’re pretty sure you’re running, and now someone has to decide, before lunch, whether this is a drop-everything problem or a note-it-for-next-shutdown problem. CISA has been pushing vendors harder on software bills of materials and faster, more structured vulnerability disclosure — and that’s a good thing. But it doesn’t solve the Monday-morning problem. It just changes what data lands on your desk when the advisory hits. The obligation that actually matters this year isn’t on the vendor. It’s on you, and it’s about whether you can do anything useful with the data once you have it.
What’s actually changing, in plain terms
CISA’s ICS advisory output has stayed elevated, and the agency has been more consistent about requesting or referencing SBOM and VEX (Vulnerability Exploitability eXchange) data from vendors as part of the coordinated disclosure process. This tracks with broader federal direction — NIST guidance, the sector-specific push under CISA’s own SBOM efforts, and procurement language that increasingly expects machine-readable component inventories from control system suppliers. None of this is a law that fines your plant. It’s a shift in vendor behavior and disclosure norms that changes the shape of the information you’re expected to consume.
Practically, that means two things are becoming more common in ICS advisories: a reference to an SBOM (in SPDX or CycloneDX format) describing the components inside a given firmware or software release, and a VEX statement telling you whether a known vulnerable component is actually exploitable in that product’s specific configuration. That second piece is the genuinely useful part — VEX exists specifically to stop you from chasing CVEs that are present in the code but not reachable in practice. The problem is that most plants have no process for pulling either document, let alone reconciling it against what’s actually bolted to the wall in Building 4.
Requesting and ingesting an SBOM from a PLC or HMI vendor
Start by assuming your vendor has an SBOM even if they’ve never handed you one. Most major automation suppliers now generate them as part of their internal build process for compliance reasons, even if they haven’t operationalized distribution to customers. Ask your vendor’s product security contact — not your local sales rep — for the SBOM tied to the exact firmware or software version you’re running, not just the product line. Version-specific matters enormously here; a component that’s vulnerable in one firmware branch may have been patched or removed in another.
When you get one, don’t expect a tidy PDF. SBOMs are meant to be machine-readable, typically CycloneDX or SPDX JSON. You don’t need a full SBOM management platform to get value from this — a handful of open-source tools (Dependency-Track is the most widely used free option) will ingest a CycloneDX file and flag known vulnerable components against the NVD automatically. If your team has no tooling budget for this yet, even a basic script that greps component names and versions against the CVE list in the advisory gets you further than eyeballing a PDF.
The VEX statement is what tells you whether to care. If the vendor says the vulnerable component is present but not exploitable — because it’s not network-reachable, not invoked in that product’s execution path, or mitigated by a compensating design choice — that’s a legitimate reason to stand down, provided the vendor’s VEX is specific about why, not just a blanket “not affected” with no rationale. Push back on vague VEX statements the same way you’d push back on a vague root-cause analysis after a line-down event.
Mapping a CVE to assets you don’t have a clean inventory of
This is where most plants actually get stuck, and it’s not a tooling problem so much as a discipline problem. Few OT environments have a CMDB with the fidelity of an IT shop — firmware versions drift, spare parts get swapped in during a breakdown without documentation, and the network diagram is three revisions behind reality. You cannot map a CVE to your fleet if you don’t know what’s in your fleet.
Short of a full asset inventory overhaul, there’s a pragmatic middle path. Passive network monitoring tools built for OT (Claroty, Dragos, Nozomi Networks, and similar platforms) can fingerprint device make, model, and often firmware version from traffic alone, without touching control logic. If you already have one deployed, it should be your first stop when an advisory lands — query it directly for the affected model and version string rather than trying to reconstruct the answer from spreadsheets. If you don’t have one, this is a legitimate argument for investing in one, but in the meantime a disciplined manual process works: maintain a living spreadsheet, by area or line, of controller make/model/firmware for anything internet-facing or connected to a level-2 network, and update it every time a controls tech touches a device. It’s not elegant. It’s what most plants actually have.
A realistic triage workflow
Not every advisory deserves the same response, and treating them all as fire drills burns credibility with operations and guarantees the next one gets ignored. A workable triage sequence looks like this:
- Confirm exposure first. Does the CVE apply to hardware or firmware you actually run, at the version named? If you can’t confirm, treat it as unknown-risk, not no-risk.
- Check exploitability and reachability. Is the affected function exposed to a network segment that’s actually reachable — remotely, or even from your own IT network? A vulnerability in a serial-only legacy protocol on an air-gapped cell is a different animal than one reachable from your business network.
- Check the CVSS score alongside CISA’s Known Exploited Vulnerabilities (KEV) catalog listing. A high CVSS score with no known exploitation and no network path is often a maintenance-window item. A lower score that’s on the KEV list, meaning it’s being actively exploited somewhere, jumps the queue regardless of severity number.
- Decide: patch now, compensating control now, or scheduled fix. Immediate action is warranted when the asset is network-reachable, the exploit is known to be active, and no compensating control already exists. Everything else — segment the device further, tighten a firewall rule, disable an unused service — can often buy you until the next planned downtime, provided you document the decision and the rationale, not just the deferral.
That documentation step matters more than it sounds like it should. When an auditor, insurer, or your own leadership asks why a CVE sat open for weeks, “we assessed it as not reachable from any external segment, applied a firewall rule as a compensating control, and scheduled remediation for the Q3 shutdown” is a defensible answer. Silence is not.
What to actually do this year
Don’t wait for a mature CMDB before you start using SBOM and VEX data — you’ll wait forever. Start with your highest-criticality assets: the PLCs and HMIs running your most exposed or most safety-relevant processes. Get their SBOMs on file now, ask your vendors directly what their VEX process looks like, and build the triage habit before the next high-profile advisory forces you into it under pressure. CISA tightening its expectations of vendors is only half the equation. The other half is whether your plant can actually turn that better data into a faster, saner decision on a Monday morning — and that part is entirely on you.
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.
