The world has changed, and software security has to change with it.
Artificial intelligence is changing the risk profile of software by accelerating vulnerability discovery and exploit development. Geopolitical tensions are rising, putting more critical systems into contested environments. Regulation is increasing the cybersecurity responsibility carried by manufacturers, OEMs, and operators throughout the life of their products.
All three forces are arriving at the same time, and they are hitting the hardest environments to change, including safety-critical and mission-critical systems that may remain in operation for decades.
On August 18, the United States released its new National Security Science & Technology Strategy, putting technological resilience at the center of U.S. national security. The strategy calls for maintaining the Golden Dome for America while protecting critical data, networks, assets, and infrastructure against cyberattack. It also identifies cybersecurity as an enabling technology across battlefield advantage, AI and autonomy, C5ISR, undersea superiority, missile defense, and other national security missions.
Every one of those missions increasingly depends on software.
As America builds the most advanced physical systems in the world, the software powering them has to become just as resilient.
Three Forces Are Changing the Operating Environment
AI is the most visible catalyst because it changes the speed of the problem. Lionfish Tech Advisors captures the issue in its new report, The Call for a Digital Golden Dome. AI-assisted analysis can find vulnerabilities in codebases faster than human teams can remediate them. Exploit development that once took significant time and expertise can increasingly be accelerated by AI as well.
The physical world still operates on engineering timelines. Aircraft, industrial systems, medical devices, energy infrastructure, autonomous platforms, and defense systems require testing, operational planning, maintenance windows, and often certification before software can change. AI can accelerate vulnerability discovery without accelerating any of those processes.
Geopolitical conditions add another level of urgency. Critical infrastructure is already an attractive target for nation-state actors, and future conflict will involve more software-defined systems operating in contested environments. The National Security Science & Technology Strategy explicitly recognizes adversary efforts to disrupt and exploit interconnected infrastructure and calls for stronger technological resilience across critical national functions.
Regulation is changing at the same time. The EU Cyber Resilience Act places continuing cybersecurity obligations on manufacturers of connected products, with vulnerability reporting requirements beginning September 11, 2026. Medical device, automotive, industrial, and other regulated sectors are moving in the same direction. The responsibility for software security increasingly follows the product throughout its life.
Technological, geopolitical, and regulatory change are converging on the same population of software. And much of that software is incredibly difficult to update.
You Cannot Patch Your Way Out of This
Safety-critical and mission-critical systems operate under a very different economic model than web applications.
A software company may push updates to a web service many times a day. An industrial controller, avionics system, medical device, weapons platform, or other certified system can require months of engineering and validation before a patch reaches the field. Lionfish cites embedded patch cycles ranging from three months to more than a year. Full rewrites of avionics, shipboard combat systems, or industrial firmware can take five to fifteen years.
Then there is distribution. A manufacturer can produce a patch, test it, validate it, and send it to customers, yet still have no guarantee that every deployed system will receive it. Long-lived products inevitably accumulate older versions, disconnected assets, maintenance constraints, and customers who cannot immediately take systems offline.
Every increase in vulnerability volume, therefore, carries a real economic cost. More findings mean more engineering, more testing, more validation, more distribution, and potentially more recertification. AI magnifies that equation.
I have thought about cybersecurity through that economic lens for a long time. My co-founder Doug Britton and I founded RunSafe around the economics of cyber risk as much as the underlying technology. The basic question has always been whether the security model can scale with the problem.
The patch-only model cannot scale with machine-speed vulnerability discovery in environments that still remediate at human and engineering speed.
There has to be a better way.
Operational Software Assurance Is Built for the Software Already in Operation
In the report by Lionfish, the firm defines an emerging category designed around challenging operational environments as Operational Software Assurance.
Its core principle is that “Assurance does not end when software ships.”
Operational Software Assurance (OSA) extends responsibility across the years software is actually operating. Lionfish organizes the category around three capabilities called Identify, Protect, and Comply.
Identify means understanding what is really present in deployed software and determining which vulnerabilities create meaningful risk. Protect means reducing the ability of attackers to exploit the binaries and firmware while they are running. Comply means continuously producing the evidence required by customers, regulators, certification authorities, and mission owners.
Those three capabilities become especially important as vulnerability volume grows. Security teams need to know whether a flaw is present in the build that actually shipped, whether an attacker can reach it, and whether exploitation can produce control of the system. Presence, reachability, and exploitability tell us far more about operational risk than a raw vulnerability count.
Operational Software Assurance puts those questions into the context where they matter most, while the software is actually performing the mission.
Runtime Protection Gives Defenders a Machine-Speed Advantage
Within OSA, the Protect pillar includes the capability that I believe will become increasingly critical in an AI-driven world.
Lionfish defines ERS as active protection applied to deployed binaries and firmware so an exploit attempt will fail when it runs without waiting for a patch. The technology is designed for environments including embedded, air-gapped, legacy, RTOS, safety-critical, and mission-critical systems.
The significance goes well beyond another technical control.
If AI can discover the next vulnerability at machine speed, defenders need protection that does not depend entirely on knowing the next vulnerability first.
Runtime protection can address classes of exploitation before the next CVE has been discovered, disclosed, triaged, patched, tested, and deployed. In Lionfish’s words, “Only a defense that operates at runtime can answer in kind.”
That is how protection starts moving faster than discovery.
The field evidence also shows why the capability deserves serious attention. An analysis of more than 2,000 vulnerabilities in a fielded medical device found that runtime protection mitigated 49 percent of vulnerabilities overall and 77 percent of critical vulnerabilities.
A separate analysis using a methodology developed at Linköping University measured more than a 98 percent reduction in usable return-oriented-programming attack chains in software containing 1.6 million candidate gadgets. Lionfish carefully separates those measurements because one measures vulnerability reduction while the other measures attack-surface reduction.
For an infrastructure operator, the meaning is much simpler. A vulnerability can remain in the software while becoming far less useful to an attacker.
Build the Software We Want While Protecting the Software We Have
I am a huge believer in memory-safe languages, modern software development, stronger software supply chains, and every effort underway to produce safer software.
We should move as quickly as possible on all of them.
We also have an enormous installed base of C and C++ software already operating in the physical world. Roughly 70 percent of serious vulnerabilities are memory-safety defects, with other field analysis putting memory-safety issues at roughly 75 percent of vulnerabilities used in zero-day exploits.
The government has been moving toward memory safety for years. NSA and CISA have encouraged memory-safe development while recognizing that existing C and C++ cannot simply be replaced. Congress has encouraged investment in technology that provides memory-safe protection for critical open-source software underpinning critical infrastructure.
The direction is right. Now the fielded base needs to be part of the strategy.
Aircraft still have to fly while modernization happens. Utilities still have to deliver power. Factories still have to produce. Medical devices still have to treat patients. Communications networks still have to connect people. Defense platforms still have to perform their missions.
We need to build the software we want while protecting the software we have.
That is the economic and operational case for Operational Software Assurance.
Critical Infrastructure Has to Run Safe
The ultimate goal for safety-critical and mission-critical systems is continued operation.
Power has to stay on. Aircraft have to stay in the air. Factories have to keep producing. Communications systems have to stay connected. Defense platforms have to remain mission capable.
Runtime protection improves mission survivability by reducing exploitability while allowing software-intensive systems to continue performing their intended functions.
The world is going to produce more software, more vulnerabilities, more autonomous systems, more regulation, and more contested environments.
Operational Software Assurance gives us a way to meet that world.
At RunSafe, we have spent years focused on the economic and operational challenges behind it. Know what is in the software. Protect it while it runs. Provide continuous assurance. Most importantly, make sure a vulnerability does not become a successful exploit.
America should build the most advanced technology in the world, and we should make the software powering it the most resilient in the world.
Let’s run fast and run safe.
Learn more about Operational Software Assurance and why Embedded Runtime Security is the answer in a world of AI-driven exploit development, geopolitical strife, and more stringent regulatory requirements.
