The Blind Spot Inside Your ICS Software
Most OT teams know what products they're running. Far fewer know what's actually inside them, and that gap has consequences.
2026-Snapshot-Volume6
⚠️This newsletter is for informational and educational purposes only. It is not a substitute for engineering judgment or site-specific analysis. Readers assume responsibility for adapting and applying this material to their environments.
This week I published a special free Insider Edition on AI cyber capability and the real risk to critical infrastructure, covering Anthropic’s Mythos, OpenAI’s GPT-5.4-Cyber, and what the OT-native research is actually showing. If you haven’t read it yet, it’s open to everyone and worth your time. This Snapshot picks up one thread from that piece that deserves its own conversation.
You Know the Product Name. Do You Know What’s Inside It?
Most OT teams can tell you exactly what software they’re running. The historian. The HMI platform. The engineering suite. The remote access tool. They know the product names, the versions, maybe even the vendor support contract renewal dates.
What they often can’t tell you is what’s actually inside those products.
Modern industrial software is built the same way most commercial software is built: with layers of third-party libraries and open-source components underneath the branded surface.
The product you bought from your automation vendor contains components your vendor didn’t write. Some of them are widely used. Some of them have had serious vulnerabilities disclosed in the past, and some of them will again.
A Software Bill of Materials, or SBOM, is essentially an ingredients list for software. It tells you what components are inside a product, what versions they’re running, and where they came from. CISA has described it exactly that way, and the concept has been gaining traction in IT security circles for several years now.
In ICS and OT environments, adoption is still early.
Many vendors don’t publish SBOMs at all.
Many asset owners have never asked for one.
And that gap, knowing the product name but not the components underneath, creates a specific kind of blindness that’s worth understanding.
When a serious vulnerability is disclosed in a widely used software component, organizations that have SBOMs can check immediately:
is this component included in anything we’re running?
Organizations that don’t have SBOMs have to wait. They have to ask their vendors. They have to hope the vendor has already inventoried their products and can give a timely answer.
Sometimes the answer comes quickly. Occasionally it takes weeks. Often times the answer is uncertain even after that.
In the meantime, you don’t know if you’re exposed.
The Quick Win
Pick two or three of your most critical ICS software vendors this week and ask them two questions:
Do you publish an SBOM for your products?
And if a component vulnerability is publicly disclosed, how quickly can you tell us whether your product is affected?
You don’t need a formal procurement process to ask. You don’t need a new policy. You can simply send an email or make a call.
The answers will tell you a great deal, not just about the SBOM itself, but about how mature your vendors’ internal software transparency practices actually are.
Vendors who can answer clearly and quickly have thought about the issue. Vendors who can’t are telling you something important too.
From the Field
In late 2021, a critical vulnerability was disclosed in a logging library called Log4j, which is used in an enormous number of software products across industries. The IT security community scrambled immediately to identify exposure. For most enterprise environments, the process of figuring out what was affected took days to weeks.
In ICS and OT environments, it took longer. Much longer in some cases.
The reason wasn’t that OT vendors were careless. It was that many of them had to manually audit their products to figure out whether Log4j was embedded somewhere inside them.
Some products were affected in ways that weren’t obvious, because the component was buried inside a dependency, inside another dependency. The visibility just wasn’t there.
I watched organizations wait for weeks to get clear answers from vendors about products sitting directly on their control networks.
Some vendors were excellent. They communicated quickly, clearly, and with specific version information. Others were slower, vaguer, and harder to pin down.
The organizations that fared best in that period weren’t necessarily the ones with the smallest attack surface.
They were the ones who knew their vendors well enough to push for clear answers, and they were the ones whose vendors had already done the internal work to understand what was inside their products.
That’s the SBOM problem made visible.
Not a compliance exercise.
Not a theoretical risk.
A real moment when not knowing what was inside your software had direct operational implications.
That moment will happen again. And if the AI cyber capability discussed in this week’s Insider Edition is pointing where I think it’s pointing, the next time won’t just be faster; it will move at a pace and scale that makes the Log4Shell scramble look manageable by comparison.
The question isn’t whether you’ll be waiting for answers. It’s whether your vendors will even be able to keep up with the pace of disclosure when it arrives.
Until next time,
Alana
Research Referenced CISA, Software Bill of Materials (SBOM) resources — cisa.gov/sbom