Industrial systems worldwide share a common weakness in their software supply chains that most security strategies completely miss. Just ask Andy Kling, VP of Cybersecurity at Schneider Electric, one of the world’s leading industrial automation and energy companies.
Recently, Andy joined us for a discussion on defending against software supply chain risks and how Schneider Electric is tackling a hidden crisis in ICS/OT security. What he shared confirmed what many in the industrial security space have suspected but lacked the data to prove. While organizations focus heavily on perimeter security, the most dangerous threats are often already embedded within their systems.
Memory Safety: The Root of Industrial Software Supply Chain Attacks
Memory safety is a topic Andy has been interested in for awhile, but it came time to prove just how significant—or not—the issue really was. Looking at all of the publicly disclosed vulnerabilities Schneider Electric had across project lines, Andy found that “memory safety was easily the largest percentage of recorded security issues that we had.”
94% of these weaknesses come from third-party components. Though that number is eye-opening, it’s not as surprising as you might think. Products today contain a significant amount of third-party or open source code.
Now, it’s important to note that this isn’t just an isolated case. We know that motivated threat actors, like Volt Typhoon and Salt Typhoon, are targeting critical infrastructure. We also know that they are using both known memory-based vulnerabilities and zero days to do so.
Consider the infamous Urgent 11 vulnerabilities that affected countless industrial control systems. Six of those eleven vulnerabilities were memory-based, and they provided attackers with significant leverage to compromise devices across multiple industries and vendors.
Memory safety vulnerabilities are widespread in software, and they are in your software supply chain too.
The Asymptotic Security Problem
Andy Kling brilliantly articulated what I consider the fundamental challenge in securing industrial systems: “We have to shift left and find out where we can improve in our own processes. But it’s also asymptotic, meaning more and more effort is going to go in to find fewer and fewer of these things.”
This asymptotic security curve means that traditional approaches yield diminishing returns. You can invest millions in better static analysis, more thorough testing, and improved development practices, yet still miss critical vulnerabilities. This isn’t to say these practices aren’t valuable—they absolutely are—but they’re insufficient on their own.
For example, some reports suggest that static analyzers for C/C++ miss 47%–80% of real vulnerabilities. Think about that: the tools we rely on for security validation are missing a significant scope of potential vulnerabilities.
This challenge is compounded by the staggering scale of industrial software. During our panel, Andy revealed that just one Schneider Electric system contained approximately 20 million lines of code—and that doesn’t even include the operating system underneath. Across their entire product portfolio, they estimate half a billion lines of code. In such vast codebases, vulnerabilities are inevitable.
The traditional approach to this problem—finding bugs and patching them—breaks down in industrial environments for several reasons. First, patches take time to develop, test, and deploy. Second, many asset owners can’t afford downtime for updates or are running critical systems that simply can’t be taken offline. Third, equipment can remain in operation for decades, far beyond standard support lifecycles.
The reality is we can’t rewrite all legacy code, and we can’t patch our way out of this problem.
A Strategic Framework for Embedded Security
To address these challenges, we need a comprehensive approach that considers the entire lifecycle of embedded systems. Andy proposed a framework organized around “time windows” for security interventions:
- Design time: Making architectural decisions that prioritize security from the start
- Implementation time: Using secure coding practices and memory-safe languages where possible
- Compile time: Leveraging compiler tools and flags that enhance security
- Load time: Implementing protections as programs are loaded into memory
- Runtime: Detecting and preventing exploitation attempts in real-time
- Support time: Analyzing field data to identify and address potential security issues
This multi-layered approach acknowledges that no single intervention is sufficient. By considering security at each phase, organizations can build defense-in-depth strategies that significantly raise the cost and difficulty for attackers.
As Andy put it: “You have a strategy here today that allows you to achieve that vision that you have for 10 years from now. And that’s that’s the seat I’m sitting in right now, and that’s why I’m talking with RunSafe, and why I’m working on it on these other approaches.”
Innovation in Memory Protection
While addressing memory safety in the software supply chain is a challenge, we’re not without options. Several innovative approaches can help address memory safety issues without requiring complete code rewrites:
Memory-safe languages like Rust and Go offer significant security improvements, but adoption in embedded systems remains challenging due to legacy constraints, performance requirements, and the sheer volume of existing C/C++ code.
Hardware-based approaches such as ARM’s Memory Tagging Extension (MTE) and Intel’s Control-flow Enforcement Technology (CET) show promise, but implementation across diverse industrial hardware ecosystems will take time.
Load-time Function Randomization (the technology we’ve developed at RunSafe) moves code around in memory every time a program runs, preventing attackers from reliably exploiting memory vulnerabilities even when they exist in the code.
What’s particularly exciting about these newer approaches is that they change the fundamental economics of cyber warfare. Rather than playing an endless game of vulnerability whack-a-mole, these technologies make exploitation prohibitively difficult and expensive for attackers, even when vulnerabilities exist.
Action Plan for Industrial Organizations
So how should industrial organizations approach this challenge? Based on our work with clients across critical infrastructure sectors, here are key recommendations:
- Conduct a Risk Reduction Analysis to identify your most critical systems and components, focusing particularly on those with memory safety implications. Understand where your key vulnerabilities lie and prioritize protection efforts accordingly.
- Have frank conversations with vendors about their approach to memory safety and supply chain security. Ask specifically how they’re addressing vulnerabilities in third-party components and what runtime protections they provide.
- Implement a defense-in-depth strategy that includes both preventative measures (improved coding practices, memory safety) and runtime protections that can mitigate vulnerabilities even when they exist.
- Make the business case for memory safety investments by focusing on the consequences of compromise. As Andy explained: “You have to understand the likelihood is high, the potential is high. So let’s talk about consequences. And now you have an informed conversation where you can decide how to approach it.”
- Balance security with operational requirements. The best security solutions for industrial environments are those that provide protection without disrupting operations or requiring massive code rewrites.
ICS/OT Security That Gets Ahead of Supply Chain Risk
The security challenges facing industrial control systems and operational technology are significant, but they’re not insurmountable. By addressing memory safety as a root cause rather than just the symptoms, organizations can dramatically improve their security posture against both current and future threats.
As Andy showed, even organizations with massive legacy codebases can make meaningful progress by adopting a strategic, multi-layered approach to security. The key is understanding where your risks lie and implementing protections that work with, rather than against, the realities of industrial environments.
The attackers targeting our critical infrastructure are sophisticated, well-funded, and persistent. But by changing the economics of exploitation through innovations in memory protection, we can ensure that the cost of attacking these systems far exceeds any potential benefit.
That’s a future worth building—one where critical infrastructure is resilient by design, and where attackers seeking to disrupt essential services find themselves facing an insurmountable challenge. Securing embedded systems isn’t just about technology, it’s about protecting the systems that power our world.
