If you’ve worked in cybersecurity for even a short time, you’ve heard the term Secure by Design. It shows up in marketing decks, compliance checklists, and industry frameworks. But beneath the jargon is something real and increasingly urgent.

In our recent episode of Exploited: The Cyber Truth, RunSafe Security Founder and CEO Joe Saunders joined host Paul Ducklin to unpack what Secure by Design really means, how it aligns with national cybersecurity priorities, and what it looks like in practice.

The post Making Secure by Design Practical: How We’re Building Resilient Software appeared first on RunSafe Security.

From medical devices and aerospace systems to industrial controls and automotive ECUs, embedded systems are the unsung heroes of modern technology. But with that ubiquity comes risk. Threat actors increasingly target embedded software, like firmware, bootloaders, OS kernels, and middleware, because it often lacks runtime protections and memory safety controls.

Embedded software security is a frontline issue in national security, critical infrastructure resilience, and commercial device integrity. So how do you secure embedded systems in a way that’s proactive, scalable, and tailored to the unique constraints of these devices?

Here’s how to strengthen your embedded software security without slowing down innovation or compromising performance.

1. Harden Software at the Binary Level

Many embedded systems are written in C or C++, which are notoriously memory-unsafe. Memory safety vulnerabilities, such as buffer overflows and use-after-free errors, are common and can enable remote code execution and other malicious actions. Traditional defenses like ASLR or stack canaries help, but they’re not foolproof and can be bypassed with enough determination.

RunSafe Security addresses this problem at its root by applying binary hardening techniques that make it dramatically harder for attackers to exploit memory vulnerabilities. Instead of just detecting bugs, RunSafe’s Protect technology randomizes binaries at build time using techniques like Load-Time Function Randomization (LFR) to break exploit chains without changing the source code.

This approach prevents entire classes of attacks before they ever reach the device and works without adding runtime overhead or requiring source code access.

2. Treat SBOMs as a Living Security Asset

A Software Bill of Materials (SBOM) is now table stakes in embedded development. But many SBOM generators miss important dependencies or generate high rates of false positives and negatives.

RunSafe enhances SBOM generation by building SBOMs during compilation, reporting on file opens, to produce rich and accurate SBOMs, especially for C and C++ code on Linux, Windows, and RTOS environments. 

While regulators are pushing for more SBOM visibility in sectors like automotive (UN R155), medical devices (FDA), and the Department of Defense (DOD), SBOMs provide more than a compliance checkbox. They are your first line of defense in software security, offering visibility into your software’s risk profile. SBOMs for embedded systems are security-focused artifacts that show what third-party libraries are potentially risky and where vulnerabilities could propagate across systems.

With SBOMs, you have insight to defend what you ship.

3. Protect Legacy Systems Without Rewrites

Securing legacy embedded systems is one of the most persistent challenges in cybersecurity. Source code is often missing. Toolchains are outdated. Patching is notoriously difficult. Yet these systems continue to run critical infrastructure, defense platforms, and life-sustaining devices.

RunSafe Protect is built for this exact scenario. It disrupts cyber exploits by relocating software functions in memory each time software is run, eliminating 100% of memory safety vulnerabilities to maintain system integrity and security. It does not require access to source code or changes to the original software, preserving functionality while significantly reducing exploitability.

This capability is vital for sectors with long product lifecycles and stringent recertification requirements, especially aerospace and defense, industrial control, and medical device manufacturers. Protect makes it possible to defend aging systems without waiting for a redesign or rewrite.

4. Build Cyber Resilience, Not Just Perimeter Defenses

Traditional embedded security tends to prioritize perimeter protections like firewalls, secure boot, and encrypted communications. However, once an attacker breaches these defenses, systems are often left vulnerable to lateral movement, privilege escalation, and remote code execution.

RunSafe Security shifts the paradigm by embedding advanced cyber resilience directly into the device. Its patented Load-time Function Randomization (LFR) technology relocates software functions in memory each time the software runs, ensuring every binary image is functionally identical but logically unique. This granular randomization at the function level disrupts memory-based exploits—such as buffer overflows and return-oriented programming (ROP)—making attacks unpredictable and unreliable even if vulnerabilities exist.

RunSafe’s approach neutralizes not only known vulnerabilities but also unknown, zero-day threats, by eliminating entire classes of memory safety flaws—the root cause of nearly 70% of embedded system vulnerabilities.

By shrinking the attack surface and hardening the system from the inside out, RunSafe ensures attackers cannot reliably exploit vulnerabilities, even if they gain initial access.

5. Make Security a Build-Time Discipline

Security shouldn’t be an afterthought. It should be part of the build system. The RunSafe Security Platform integrates directly into your DevOps and build pipelines, providing automated vulnerability identification, authoritative SBOM generation, and patented memory relocation to harden software at build time.

This keeps your engineers focused on features and performance, while security happens behind the scenes.

A Smarter Path Forward for Embedded Software Security

Embedded software security isn’t just about patching CVEs or buying a next-gen firewall. It’s about making your systems fundamentally more difficult to exploit regardless of whether you’re building a satellite, an insulin pump, or a warship.

RunSafe Security gives you the tools to:

• Stop memory-based attacks in embedded systems
• Generate high-fidelity, actionable build-time SBOMs
  
• Secure legacy code without rewrites
  
• Embed resilience into your runtime environment
  
• Shift security left, without breaking builds or slowing delivery

Whether you’re designing a next-generation avionics stack or securing an IoT device fleet, RunSafe’s approach to embedded software security helps you deliver code that’s harder to hack and easier to trust.

See how it works

Run a Risk Analysis
Learn More About Runtime Protection
View the SBOM Comparison Chart

The post How to Strengthen Your Embedded Software Security appeared first on RunSafe Security.

The consequences reach beyond network disruptions: 75% of these incidents directly compromised patient care, with nearly half compelling organizations to revert to manual processes just to maintain operations. When a cyberattack necessitates transferring patients to other facilities, which occurred in 24% of cases, the situation creates serious medical emergencies.

The convergence of IT and OT security is putting medical devices at the center of cybersecurity strategy, the report shows. Healthcare organizations can no longer protect medical devices in isolation. Securing patient-critical systems now requires defending the entire interconnected ecosystem.

Because of this, we’re seeing a changing relationship between healthcare providers and medical device manufacturers. The findings of the 2025 Index show that for healthcare buyers, cybersecurity is becoming a gatekeeper to market access.

The post What Healthcare Buyers Expect from Medical Device Manufacturers: Security Is No Longer Negotiable appeared first on RunSafe Security.

Critical infrastructure and the embedded systems that underlie it are under attack. State-sponsored threat groups, like MISSION2025 and Volt Typhoon, are specifically targeting key sectors integral to national and economic security, like aerospace and defense, healthcare systems, telecom networks, and manufacturing operations.

Embedded systems are foundational to all of these sectors. While embedded systems offer clear benefits in terms of performance, power efficiency, and specialization, they also present a distinct set of cybersecurity challenges.

1) The Trillion-Dollar Code Problem

One of the most urgent issues in securing embedded systems is the sheer amount of legacy code that is vulnerable to memory-based exploits. Most embedded applications are written in memory-unsafe languages like C and C++, which are susceptible to common memory safety vulnerabilities such as buffer overflows and use-after-free errors. These vulnerabilities account for the majority of software exploits in the embedded space.

Although security experts and government agencies, such as CISA, advocate transitioning to memory-safe languages like Rust, a complete rewrite of legacy systems is often economically and logistically unfeasible. For many industries, this would mean years of recoding and recertification, impacting time-to-market and product reliability. Not to mention the expense. The cost to rewrite the code base for embedded systems could easily run into the billions for some companies, requiring extensive testing and diverting developer and engineering resources that would otherwise be allocated to innovation and further product development.

The best way to address this challenge includes taking a hybrid approach, selectively rewriting only the most critical components in safer languages while applying runtime protections to mitigate vulnerabilities in existing binaries. This dual approach enables continued innovation and field performance without requiring full-scale code replacement.

2) Expanding the Attack Surface with Connectivity

Recently, researchers at Georgia Tech demonstrated the ability to hijack industrial control systems through nothing more than a web browser. By exploiting embedded web servers in programmable logic controllers (PLCs), they showed how attackers could gain full control over motors, power relays, and water pumps—all while remaining virtually undetectable, even after hardware resets.

The rise of connectivity in embedded devices—through IoT, 5G, edge computing, and cloud integrations—has significantly expanded the attack surface. Devices that were once isolated and secure-by-default are now exposed to remote access, data exfiltration, and distributed attacks.

Many embedded systems were not designed initially with external communication in mind, and retrofitting them for connected environments often leaves security gaps. In addition, increased reliance on third-party software, open-source libraries, and supply chain components introduces additional risks.

Addressing this challenge requires a proactive cybersecurity approach throughout the device lifecycle. This includes secure software development practices (like threat modeling and SBOM generation), continuous vulnerability assessment, and runtime threat mitigation. Embedded systems must be protected not only at the perimeter but also internally—at the firmware and binary levels—to resist exploitation even when a network breach occurs.

3) Securing Legacy Systems

Another persistent challenge is securing legacy systems that remain in active use across industries. These systems often rely on outdated hardware and software stacks that lack compatibility with modern security technologies. They may no longer receive vendor support or security patches, and yet continue to perform critical functions in sectors like manufacturing, transportation, and healthcare.

Replacing these systems is often cost-prohibitive or operationally disruptive. As a result, organizations are left with the difficult task of securing systems that were never designed with today’s threat landscape in mind.

To improve the security of legacy embedded systems, organizations should enforce cybersecurity requirements during new development, conduct regular vulnerability assessments for systems already in operation, and deploy runtime protections that can harden binaries in-place without requiring changes to source code or hardware. These measures extend the safe lifespan of legacy devices while reducing overall risk exposure.

The post 3 Challenges in Embedded Systems Security appeared first on RunSafe Security.

What Makes OT Security So Hard to Fix?

Unlike traditional IT, OT systems power critical infrastructure like energy grids, water management, manufacturing floors, and more. These devices often run on low-powered hardware with long lifespans and were never designed for modern connectivity. They were secured by locked doors, not firewalls.

Fast forward to today, and these devices are increasingly connected to the internet—and exposed.

Memory Safety: Still the Achilles’ Heel

Many vulnerabilities in common OT products are caused by buffer overflows or memory corruption flaws. While systemic, these vulnerabilities can be proactively addressed with memory safety protections.

“If you can eliminate entire classes of vulnerabilities before software hits the field, you don’t need to play whack-a-mole with patches,” says Saunders.

RunSafe’s approach focuses on preventing exploitation at the binary level, effectively making vulnerabilities non-exploitable without requiring post-deployment patching.

The Growing Complexity of the OT Software Supply Chain

Even the simplest industrial device could include thousands of open-source software components. Without visibility into the Software Bill of Materials (SBOM), organizations are left guessing about what’s inside.

“If a vendor can’t tell you what’s in their product, chances are, they don’t know either,” says Saunders.

Knowing your software’s components—and their vulnerabilities—is critical for compliance. It’s also critical for managing risk across the supply chain, identifying attack surfaces, and making smart, prioritized decisions.

Why Patching Alone Isn’t Enough

Patching in OT isn’t like clicking “update” on your phone. It can require physical access to remote locations and months of planning. Worse, many vulnerabilities go unpatched for 180+ days, leaving critical infrastructure exposed for far too long.

This makes proactive protection methods—like RunSafe’s memory randomization techniques and runtime protection—essential tools in a modern OT defense strategy.

What Should Product Manufacturers and Asset Owners Do Now?

Joe Saunders outlines a simple yet powerful framework:

For OT Product Manufacturers:

1. Generate a complete SBOM for each product.
2. Identify known vulnerabilities.
3. Prioritize fixes based on impact and exploitability.
4. Adopt Secure by Design tools that eliminate entire classes of vulnerabilities at build time.

For Asset Owners:

1. Request SBOMs from all vendors.
2. Analyze vulnerabilities across all systems—from HVAC to power to physical access.
3. Demand security transparency and memory safety protections from suppliers.

This shift toward accountability and visibility reduces operational costs and futureproofs infrastructure.

Regulation, Risk, and the Path Forward

Fixing OT security won’t happen with checklists and wishful thinking. It’ll take:

• Regulation that incentivizes change, like the Cyber Resilience Act
• Automation that scales patchless security
• Shared responsibility across the ecosystem

“The real question isn’t whether we can fix OT security,” Saunders concludes. “It’s whether we want to—and who’s willing to lead the charge.”

The post Fixing OT Security: Why Memory Safety and Supply Chain Visibility Matter More Than Ever appeared first on RunSafe Security.

In a webinar hosted by Dark Reading, RunSafe Security CTO Shane Fry and VulnCheck Security Researcher Patrick Garrity discussed the rise of memory safety vulnerabilities listed in the KEV catalog and shared ways organizations can manage the risk.

Memory Safety KEVs on the Rise

Data from VulnCheck shows a clear increase in memory safety KEVs over the years, reaching a high in 2024 of around 200 total KEVs.

“We’re seeing the number of known exploited vulnerabilities associated with memory safety grow,” Patrick said. “If you look at CISA’s KEV list, the concentration is quite high as far as volume.”

Data from VulnCheck, Memory Saftey Known Exploited Vulnerabilities

Memory safety KEVs are also found across industries, including network edge devices, hardware and embedded systems, industrial control systems (ICS/OT), device management platforms, operating systems, and open source software.

Data from VulnCheck, Memory Saftey Known Exploited Vulnerabilities by Industry

Patrick emphasized the universal nature of the threat: “If you look at this list, there’s manufacturing impacted, medical devices, embedded systems, and critical infrastructure. Across the board from an industry perspective, you’re going to see these vulnerabilities everywhere.”

There’s A Lot of KEVs, So What?

Not only are memory safety KEVs widespread, many are also classified as critical, with high CVSS scores. Six memory safety weakness types are now included in MITRE’s list of the top 25 most dangerous software weaknesses for 2024.

Data from VulnCheck, Memory Saftey Known Exploited Vulnerabilities by CVSS Criticality

Memory safety vulnerabilities—like buffer overflows, use-after-free bugs, and out-of-bounds writes—have long plagued compiled code. “About 70% of the vulnerabilities in compiled code are memory safety related,” explained Shane Fry. 

When attackers exploit these bugs, the results can be severe. Organizations may face:

• Arbitrary code execution
• Remote control of devices
• Denial of service
• Privilege escalation
• Data exposure and theft

Real-World Exploits: What the Data Tells Us

Ivanti Connect Secure (CVE-2025-0282)

This KEV, an out-of-bounds write (CWE-787), affected several Ivanti products and was linked to the Hafnium threat actor group. Patrick called out the speed at which this vulnerability moved from discovery to exploitation: “The vendor identifies there’s a vulnerability, there’s exploitation, they disclose the vulnerability, they get it in a CVE, and then CISA adds it—all in the same day.”

Typically, the disclosure process does not flow so quickly, but in this case it was a good thing as the exploit targeted a security product. Shane observed: “One of the very interesting philosophical questions that I think about often in cybersecurity spaces is how impactful a security vulnerability in a security product can be. Most people think that if it’s a security product, it’s secure. And off they go.”

Siemens UMC Vulnerability (CVE-2024-49775)

A heap-based buffer overflow flaw (CVE-2024-49775) in Siemens’ industrial control systems exposed critical infrastructure to risks of arbitrary code execution and disruption. The vulnerability exemplifies the widespread impact memory safety issues can have across product lines when they affect common components.

Global Recognition of the Growing Risk

The accelerating growth of memory safety KEVs has not gone unnoticed by global security organizations. In 2022, the National Security Agency (NSA) issued guidance stating that memory safety vulnerabilities are “the most readily exploitable category of software flaws.”

Their guidance recommended two approaches:

• Rewriting code in memory-safe languages like Rust or Golang
• Deploying compiler hardening options and runtime protections

Similarly, CISA has emphasized memory safety in its Secure by Design best practices, advocating for organizations to develop memory safety roadmaps.

The European Union’s Cyber Resiliency Act (CRA) takes a broader approach, emphasizing Software Bill of Materials (SBOM) to help organizations understand vulnerabilities in their supply chain. As Shane noted, “We saw a shift in industry when the CRA became law that, hey, now we have to actually do this. We can’t just talk about it.”

Practical Steps: What Organizations Can Do Now

Given the growing threat landscape, organizations need practical approaches to address memory safety vulnerabilities.

1. Prioritize Critical Code Rewrites

For most companies, a full rewrite in Rust or another memory-safe language isn’t realistic. Instead, start by identifying high-risk, externally facing components and consider targeted rewrites. Shane suggested starting with software or devices that most often interact with untrusted data.

2. Adopt Secure by Design Practices

Implementing secure development practices can help prevent introducing new vulnerabilities.

“There’s a lot of aspects of Secure by Design, like code scanning and secure software development life cycles and Software Bill of Materials, that can help you understand what you’re shipping in your supply chain,” Shane said.

3. Use Runtime Protections

Runtime hardening is an effective defense for legacy or third-party code that can’t be rewritten. Runtime protections prevent the exploit of memory safety vulnerabilities by randomizing code to prevent attackers from reliably targeting vulnerabilities.

RunSafe accomplished this with our Protect solution. “Every time the device boots or every time your process is launched, we reorder all the code around in memory,” Shane said. 

It also buys time, allowing organizations to avoid having to ship emergency patches overnight because their software is already protected.

Memory Safety Is Everyone’s Problem

Memory safety vulnerabilities are becoming more common across industries. The risks are serious, especially when attackers can use these flaws to take control of systems or steal data.

Organizations need to take action now. By rewriting the highest-risk code, following secure development practices, and using runtime protections where needed, companies can reduce their exposure to memory safety threats.

Memory safety problems are widespread, but they can be managed. Secure by Design practices and runtime protections offer a path forward for more secure software and greater resilience.

The post Memory Safety KEVs Are Increasing Across Industries appeared first on RunSafe Security.

What Is the CRA and Who Does It Affect?

“Software Bill of Materials is actually an essential point to help share across the ecosystem, across the value chain. It’s a new journey to elevate your security posture even higher by really knowing exactly what’s in all those components in your final product.” — Joseph M. Saunders

New Liabilities and the Cost of Non-Compliance

The CRA introduces substantial new liabilities for non-compliance, including fines of up to €10 million or 2.5% of global turnover. These penalties aim to ensure organizations take cybersecurity seriously. While some may view this as a burden, Saunders argues these “sticks” are necessary to promote best practices, improve code quality, and enhance organizational resilience.

How Are Organizations Preparing?

Forward-looking companies are already taking action to align with EU CRA requirements:

• Cross-functional planning: Security is being embedded across legal, development, marketing, and product teams.
• SBOM adoption: Organizations are building workflows to generate and update SBOMs throughout the lifecycle.
• Supply chain scrutiny: Greater transparency is being demanded from vendors and partners.
• Incident response readiness: Detection, reporting, and remediation capabilities are being strengthened.

The Role of Cyber Insurance in a Post-CRA World

Even with the best Secure by Design development practices in place, vulnerabilities will still surface. No software is flawless, and the complexity of modern digital ecosystems—particularly those reliant on third-party and open-source components—means that gaps in security are nearly unavoidable.

The EU Cyber Resilience Act (CRA) raises the stakes, holding manufacturers and developers accountable for the entire lifecycle of their products. This makes cyber insurance not just a smart investment but a strategic imperative. 

“Cyber insurance for products is a great idea,” Saunders said, explaining how you can set up engineering processes to follow certain steps to reduce risk. If you can demonstrate that you are taking steps to avoid an attack, then an insurer can provide coverage.

As compliance obligations expand and the consequences of non-conformance grow more serious, organizations need robust risk transfer mechanisms to safeguard against the financial fallout of cyber incidents and regulatory breaches.

In the post-CRA environment, insurers may begin requiring evidence of strong cybersecurity hygiene—such as regular vulnerability assessments, real-time monitoring, SBOM documentation, and incident response readiness—as prerequisites for coverage or lower premiums. By combining proactive security practices with the safety net of cyber insurance, companies can create a more resilient posture while minimizing exposure to emerging risks.

Preparing to Compete in the Cyber Resilience Economy

The EU CRA signals a fundamental shift in how security is expected to be built, managed, and demonstrated across connected products. It’s a wake-up call for organizations that have deprioritized security in favor of speed or cost savings.

By embracing Secure by Design principles, adopting Software Bill of Materials (SBOM) practices, and building security into every stage of the product lifecycle, forward-thinking organizations can prepare for regulatory compliance and gain a competitive edge. These efforts increase stakeholder trust, improve software quality, and reduce time-to-remediate when issues arise.

Rather than viewing the CRA as a burden, it should be seen as a blueprint for building trust in the digital age. Organizations that act now will not only avoid fines and reputational damage, they’ll also be better positioned to lead in a marketplace that increasingly rewards transparency, security, and resilience.

The post The EU Cyber Resilience Act (CRA) Exposed: What You Need to Know Now appeared first on RunSafe Security.

The numbers reflect a growing and dangerous trend of attackers shifting their focus from data-rich IT systems to mission-critical OT environments where the consequences of downtime can be catastrophic.

“Ransomware attacks are on the rise, and most discussion revolves around recovering from ransomware—either paying the ransom or hiring a recovery firm,” said Shane Fry, CTO at RunSafe Security. “Unfortunately, those approaches are just band-aids addressing the symptoms. The better approach is prevention. If an attacker can’t gain code execution on a system, they can’t run their ransomware in the first place.”

A prevention mindset is urgently needed to defend OT systems.

Ransomware’s OT Evolution

A report from Dragos found an 87% increase in ransomware attacks against industrial organizations over the past year and a 60% rise in ransomware groups affecting OT/ICS (operational technology/industrial control systems) in 2024.

OT networks were historically “air-gapped” or isolated, but the rise of Industrial IoT (IIoT) and convergence with IT systems has opened the floodgates to cyber threats. Legacy systems, outdated firmware, insecure protocols, and unpatched vulnerabilities make OT a soft target that attackers are paying more attention to.

Not only that, but changes in the geopolitical landscape are likely attributable to the rise in attacks. “With the changing geopolitical landscape and the changes in cyber priorities, it is no surprise to see an increase in attacks and reports of ransomware,” said Joe Saunders, Founder and CEO of RunSafe Security.  “Attackers are testing the fault lines and seeking ransom payouts.”

Additionally, OT systems aren’t designed to be restored overnight like cloud servers and require manual resets, specialized hardware, and physical technician access. Downtime from an ICS/OT ransomware attack costs an average of $4.73 million per incident and results in public safety risks. Because of the costs and risk involved, OT organizations may be more inclined to pay a ransom to restore operations, and bad actors and threat groups are taking notice.

“We must implement straight solutions now to make critical infrastructure safe in an efficient way,” Joe said. “Otherwise, China and other adversaries will, at a time of their choosing, disrupt operations.”

Where OT Ransomware Attacks Originate

Ransomware doesn’t need to originate in OT to impact OT. If your supply chain includes IT/OT integration, third-party maintenance tools, or remote access services, your OT is exposed.

The SANS 2024 State of ICS/OT Cybersecurity report found that 20.3% of ICS/OT leaders reported supply chain compromise as the initial attack vector involved in OT/control systems incidents.

We can see this growth in a few notable ransomware incidents involving OT.

Kaseya Ransomware Attack (2021) – IT/OT Convergence Breach

In 2021, the REvil ransomware gang compromised Kaseya’s VSA remote management tool used by MSPs, which had clients across various sectors, including manufacturing and industrial facilities. It’s estimated that 200+ companies were compromised as a result. The attack is an example of how software supply chain attacks can create a domino effect for companies further down the chain, including how IT-focused supply chain tools can cascade into OT disruption through shared access.

The Colonial Pipeline Incident (2021) – Indirect OT Disruption via Ransomware

The Colonial Pipeline incident in 2021 is a good reminder to take ransomware seriously. DarkSide ransomware hit Colonial Pipeline’s IT systems. Although the OT environment wasn’t directly compromised, operations were proactively shut down due to uncertainty and risk. The incident revealed how ransomware can indirectly cripple OT via compromised IT systems that manage or monitor critical infrastructure.

Strategies for OT Ransomware Defense

The best defense against ransomware is a proactive approach that prevents attackers from ever gaining code execution on a system. Below are several measures to defend OT software.

• Network Segmentation: Isolate critical OT systems from IT networks to limit lateral movement.
• Strong Credential and Access Management: Enforce multi-factor authentication, rotate credentials, and use allowlist-based access controls.
• Regular, Offline Backups: Maintain encrypted, offline backups and test them regularly to ensure rapid recovery without paying ransoms.
• Incident Response Planning: Develop and rehearse OT-specific incident response plans, including procedures for isolation and recovery.
• Continuous Monitoring: Stay updated on indicators of compromise and integrate threat intelligence into monitoring practices.
• SBOMs and Supply Chain Security: Generating and maintaining a Software Bill of Materials (SBOM) enhances transparency, helps identify vulnerable components, and is rapidly becoming a regulatory requirement.
• OT-Specific EDR: Deploy endpoint detection and response solutions tailored for OT, minimizing operational impact while detecting malicious behaviors.
• Memory Safety and Software Hardening: Tools like RunSafe Security’s Protect proactively defends against memory-based vulnerabilities and zero-day exploits by hardening software at build time, reducing the risk of code execution by attackers.

Prevention Is the Only Real Cure

The surge in ransomware attacks on OT environments is a wake-up call for critical infrastructure operators. Relying solely on reactive measures is no longer sufficient. As Shane Fry notes, preventing initial access and code execution is the most effective way to stop ransomware before it can cause harm. 

By adopting proactive, OT-specific security measures, such as memory safety hardening, software supply chain transparency, and robust incident response, organizations can build resilience and protect the systems that keep our world running.

Learn how an industrial automation leader automated software hardening and vulnerability identification for their products.

FAQs:

Why are ransomware attacks on OT environments increasing?

The convergence of IT and OT networks, reliance on legacy systems, and recent geopolitical tensions have made OT environments prime targets.

Are ransomware attacks against OT systems increasing?

Yes. In 2025, the FBI reported that ransomware attacks on US infrastructure rose 9% and that ransomware attacks on critical infrastructure accounted for almost half of all ransomware complaints received in 2024.

How do attackers typically infiltrate OT systems?

Through phishing, exploiting unpatched vulnerabilities, abusing trusted tools, and moving laterally from IT to OT networks.

What is the most effective ransomware protection for OT?

Proactive prevention, such as memory safety hardening, virtual patching, OT-specific EDR, and supply chain transparency, offers the best defense against modern ransomware threats.

The post Ransomware in OT Environments: A 2025 Perspective appeared first on RunSafe Security.

“Automotive companies have become software companies, and their software practices are essential to drive innovation,” said Joe Saunders, Founder and CEO of RunSafe Security, in a recent webinar with Automotive IQ. “When safety and security are combined, it means we can build innovation going forward.”

For modern vehicles, that will mean addressing common vulnerabilities in software to not only minimize security risk, but to maximize innovation and ensure safety overall.

The Growing SDV Market and Its Security Implications

The growth of Software-Defined Vehicles (SDVs) is remarkable, with projections suggesting the SDV market will exceed $650 billion by 2030, representing 15-20% of the entire automotive ecosystem. This growth is driven by both consumer benefits and industry innovation.

For consumers, SDVs offer enhanced connectivity, personalized services, and improved safety features. From the industry perspective, autonomous driving capabilities, electric vehicle technologies, and over-the-air (OTA) update functionality are creating new service models and revenue streams for manufacturers.

However, this software revolution comes with significant security challenges. Modern vehicles now contain upwards of 100 million lines of code across 40-70 different software packages or applications. This dramatic increase in code creates an extensive attack surface that needs addressing.

The Current State of Automotive Cyber Attacks

Recent industry reports paint a concerning picture of the vulnerability landscape:

• 92% of automotive attacks in 2024 were remotely executed
• 70% of attacks could potentially affect thousands or millions of devices across different manufacturers due to common software and architectures
• 35% of attacks involved car system manipulation

These statistics highlight the growing risk of cyber threats to connected vehicles. “In the automotive industry, if you think about autonomous driving and attack vectors that could affect car system manipulation, I think everyone would agree that security is really about safety,” Joe said. “With more software, it means we have a chance to find ways to generate more security for these applications.”

3 Common Vulnerabilities in Software-Defined Vehicles

Vulnerabilities are commonly found in three areas of SDVs: electronic control units, Advanced Driver Assistance Systems (ADAS), and infotainment systems. Infotainment systems in particular are becoming a bigger risk, due to new connectivity features.

Infotainment Systems

Hacks against vehicle infotainment systems were in the news in early 2025. Over a dozen vulnerabilities were discovered in a Mercedes-Benz infotainment system. Security flaws in Subaru’s Starlink-connected infotainment system allowed hackers to remotely control the vehicle, including turning it on and off, unlocking it, and more.

Hackers can gain access to data and location information through these systems, but more concerningly, as recent examples show, infotainment systems are often used as an on-ramp to access other critical vehicle systems.

“Not all vehicles today are segmented from a security perspective and people can jump from one component to the other,” Joe said.

Electronics Control Units (ECUs) in Automobiles

Vulnerabilities in real-time operating systems (RTOS) can be exploited once attackers gain access to a vehicle’s systems. “ECUs are an easy target once an attacker is on board,” Joe said.

Because ECUs are most commonly programmed in languages like C and C++, they are susceptible to memory safety vulnerabilities. An attacker who exploits a memory safety vulnerability in the ECU firmware could take runtime control and cause erratic vehicle behavior.

Advanced Driver-Assistance Systems (ADAS)

Advanced Driver-Assistance Systems (ADAS) are similarly susceptible to memory safety vulnerabilities. “In many cases, in the underlying software, like ADAS, we have seen that the vulnerabilities are related to memory safety vulnerabilities.” 

ADAS enhances safety using sensors, cameras, radar, and complex software. A successful attack could alter sensor data or decision-making algorithms, endangering the vehicle’s safety. For example, memory corruption in sensors could result in incorrect object detection, leading to collisions or other dangerous situations.

Case Study: Tesla Vulnerabilities

An example of a memory-based vulnerability in automotive software is CVE-2022-42431, a critical buffer overflow vulnerability discovered in Tesla Model 3 vehicles. A buffer overflow is a classic memory safety vulnerability that ultimately allows an attacker either to escalate privileges or even gain the ability to execute arbitrary code. 

The implications are severe: “What that means is they can ultimately leverage the existing code and do something that wasn’t originally intended by the original developer for that feature,” Joe said. “These kinds of vulnerabilities are very critical and ultimately get rated through the services as the highest severity scores.”

These examples illustrate how memory safety vulnerabilities—classic issues in software developed using “memory unsafe” languages like C and C++—pose significant risks to vehicle security and, by extension, passenger safety.

Best Practices for Securing Software-Defined Vehicles

1. Implement Software Development Lifecycle Practices

Over the past decade, the industry has seen dramatic improvements in the software development lifecycle. Automotive manufacturers should continue to enhance these practices by:

• Implementing secure coding standards
• Conducting thorough threat modeling
• Utilizing automated vulnerability detection tools
• Integrating security protections into the development process

2. Adhere to Automotive Safety and Security Standards

Standards like Automotive Safety Integrity Levels (ASIL), which define four levels of safety classification based on risk to passengers, play a crucial role in ensuring vehicle security. These standards, along with industry frameworks like ISO 26262 and AUTOSAR, provide essential guidelines for secure development.

3. Deploy Runtime Protection Systems

One of the most effective security strategies is implementing runtime memory protection at the software build stage. This approach eliminates the entire class of memory-based vulnerabilities, which account for 40-70% of all vulnerabilities in these systems, without requiring code rewrites or adding system overhead.

4. Leverage Over-the-Air Updates

OTA update capabilities provide a mechanism for addressing vulnerabilities and deploying security patches throughout a vehicle’s lifecycle, allowing manufacturers to continuously improve security posture even after vehicles have been deployed to customers.

5. Manage Software Supply Chain Risk

With the complexity of automotive software supply chains, addressing and mitigating third-party software risks and risks from open source software is crucial. Steps include:

• Requiring suppliers to provide Software Bills of Materials (SBOMs)
• Conducting security assessments of third-party components
• Establishing transparent communication channels with suppliers
• Proactively identifying and addressing vulnerabilities in the supply chain

The Road Ahead for Automotive Software Security

As the automotive industry continues its transformation toward software-defined vehicles, security must be a foundational consideration rather than an afterthought. By implementing secure development practices, adhering to industry standards, deploying runtime protections, and managing supply chain risks, manufacturers can create vehicles that are both innovative and secure.

The key takeaways for automotive manufacturers and OEMs:

• ECUs, ADAS, and infotainment systems are particularly vulnerable to memory safety vulnerabilities
• Software security is now an undeniable component of vehicle safety
• Focusing on safety and security today will enable innovation and resilience against future risks

By addressing these challenges head-on, the automotive industry can continue to drive innovation while ensuring the safety and security of the vehicles that consumers depend on every day.

The post Driving Innovation Safely: 5 Ways to Secure Software-Defined Vehicles appeared first on RunSafe Security.

TrustInSoft develops solutions for advanced software analysis that specialize in formal verification of C, C++ and Rust source code to ensure safety, security and reliability. 

Key Takeaways:

• High code coverage is crucial for minimizing vulnerabilities and improving software reliability.
• Combining exhaustive static analysis with runtime exploit prevention offers a  layered security strategy for 100% code coverage.
• TrustInSoft‘s tools and services offer exhaustive static analysis for early vulnerability detection, complemented by runtime protection tools like RunSafe Protect for comprehensive software security.

Introduction

Ensuring code reliability and security is paramount in software development today. Attackers actively look for vulnerabilities in code that can be exploited, leading to significant risks and potential damage. For example, in 2024, 768 CVEs were publicly reported as exploited in the wild for the first time.

Many security vendors work with independent testing institutions like AV-Test to validate the efficacy of their detection engines against malicious activity from bad actors that abuse known software vulnerabilities. The delta between the top vendors is typically only a few percentage points above 99% efficacy. However, though the top vendors achieve near 100% accuracy, bad actors continue to exploit known vulnerabilities within that small percentage gap. Early vulnerability detection using secure coding practices helps reduce the attack surface that bad actors often exploit.

Code coverage plays a vital role in mitigating these risks by measuring the extent to which source code is tested. This blog explores the role of code coverage in software security, the nuances of different code coverage metrics, and ways to address typical code coverage limitations by integrating exhaustive static analysis and runtime exploit prevention techniques to achieve resilient software that aligns with security standards and regulations. 

Code Coverage: Minimizing Vulnerabilities

Code coverage is a metric that measures the degree to which source code has been tested. The goal of achieving high code coverage is to reduce the number of undetected bugs and improve overall software reliability. While developers strive to test as much code as possible, attaining perfect coverage is rarely achieved.

Understanding Code Coverage Metrics

Several key metrics provide different perspectives on testing thoroughness:

• Statement Coverage: Measures whether each statement in the code has been executed.
• Branch Coverage: Measures whether each branch of control structures (e.g., if-else statements) has been executed.
• Condition Coverage: Measures whether each condition in a decision has affected all possible outcomes.
• Path Coverage: Measures whether all possible paths through the code have been executed.
• Modified Condition/Decision Coverage (MC/DC): Used in safety-critical systems to ensure each condition independently affects the decision outcome.

The type of coverage will usually be chosen in the project depending on its defined quality requirements. While aiming for 100% code coverage is ideal, it’s essential to recognize that it may not be achievable due to time constraints and complexity. Achieving high coverage doesn’t guarantee the absence of vulnerabilities, highlighting the need for additional security measures when full coverage cannot be attained. 

This is where TrustInSoft’s exhaustive static analysis solutions and RunSafe’s runtime exploit prevention technologies come into play, offering a more comprehensive approach to software security.

Benefits of High Code Coverage

Achieving high code coverage offers numerous benefits:

• Improved Software Quality and Reliability: Thoroughly tested code is less likely to contain bugs, leading to more reliable software.
• Early Error Detection: Identifying and fixing errors early in the development cycle reduces debugging costs and accelerates time to market.
• Reduced Maintenance Costs: High-quality, well-tested code requires less maintenance and fewer patches, reducing long-term costs.
• Compliance with Security Standards and Regulations: Many security standards and regulations require high code coverage as part of their compliance requirements.

Exhaustive Static Analysis for Early Vulnerability Detection

Static analysis involves evaluating code without the need for a target to run it on, allowing for the early identification of vulnerabilities and errors. Traditional static analysis tools using pattern-matching and rule-based scanning can identify potential issues, but they often produce false positives, slowing down the testing process and potentially overlooking critical vulnerabilities. 

TrustInSoft Analyzer utilizes a different technique that focuses on the behavior of C/C++ code, providing a more exhaustive analysis that reduces false positives and ensures no vulnerabilities are overlooked. 

Because the tool applies a formal methods approach internally, it can assert the absence of runtime errors and other critical software bugs. Besides the guarantee of finding all issues it searches for, the focus on the behavior means that TrustInSoft Analyzer keeps a trace of each reached part of the application and can produce a coverage report.

Runtime Exploit Prevention: Protecting Against Runtime Exploits

Runtime exploit prevention technologies protect applications by detecting and preventing attacks at runtime. Runtime protection is crucial because it addresses vulnerabilities that may not be discovered during the development phase without sufficient code coverage testing efforts. By monitoring application behavior and detecting anomalies, Runtime exploit prevention can prevent attackers from exploiting unforeseen weaknesses, ensuring the application remains secure even in the face of novel threats. RunSafe Security’s tools exemplify runtime exploit prevention, guarding against memory corruption using methods such as Load-time Function Randomization (LFR).

Runtime exploit prevention provides an additional layer of security against zero-day exploits and other sophisticated attacks that may bypass traditional testing methods. RunSafe’s solutions offer proactive runtime protection, complementing early vulnerability detection with exhaustive static analysis to create a comprehensive security posture.

Combining Exhaustive Static Analysis and Runtime Exploit Prevention

Integrating exhaustive static analysis and runtime exploit prevention creates a robust, layered defensive strategy. Static analysis using formal methods, like that offered by TrustInSoft Analyzer, focuses on early vulnerability detection, identifying potential issues before the code is ever executed. Where a hundred percent of code coverage is not attainable, runtime exploit prevention, such as RunSafe’s security measures, protects against runtime exploits by monitoring application behavior and preventing attacks in real-time.

These approaches are complementary, providing comprehensive protection throughout the software development lifecycle. By combining TrustInSoft Analyzer’s exhaustive static analysis with runtime protection tools like RunSafe, organizations can ensure their software is secure from development to even after deployment. This integrated approach ensures mathematically proven memory safety and regulatory compliance readiness. Combining these tools gives you assurance for all code covered through exhaustive code analysis with TrustInSoft Analyzer and a back up on unanalyzed code with RunSafe.

Conclusion

Achieving high code coverage is essential for developing reliable and secure software. Integrating exhaustive static analysis with runtime exploit prevention creates a comprehensive security strategy that protects against vulnerabilities at every stage of the software development lifecycle. Organizations should adopt a multi-faceted approach to security, combining tools like TrustInSoft Analyzer and runtime exploit prevention technologies like RunSafe to ensure robust and resilient software throughout the SDLC.

By prioritizing code coverage, leveraging exhaustive static analysis, and implementing runtime exploit prevention, organizations can deliver software that is not only functional but also secure and reliable through exhaustive code coverage on up to 100% of the code and runtime exploit mitigation for remaining code. 

TrustInSoft’s solutions provide mathematically proven memory safety, ensuring compliance and reducing the risk of costly vulnerabilities. For enhanced runtime protection, consider RunSafe’s innovative solutions. Both TrustInSoft and RunSafe offer valuable tools for creating a secure software ecosystem, request a demo of TrustInSoft Analyzer or deploy RunSafe’s tools for the ultimate protection against attacks.

The post Improving Code Coverage: The Benefits of Exhaustive Static Analysis & Runtime Exploit Prevention appeared first on RunSafe Security.

In 2024 alone, security researchers at Google tracked 75 zero-day vulnerabilities exploited in the wild. Particularly alarming is that 44% of these targeted enterprise products, highlighting how attractive zero-day vulnerabilities are to cybercriminals and nation-state threat actors. For example, we’ve seen how Volt Typhoon and Salt Typhoon have specifically targeted operational technology (OT) systems through unpatched vulnerabilities.

Whether we’re considering weapons systems, critical service providers, security vendors, or others, nation-states and other malicious actors have their eyes on zero-day flaws as a means to cause widespread damage and disruption.

What Are Zero-Day Vulnerabilities and Why Are They Exploited?

A zero-day vulnerability is a flaw in software that is unknown to the software’s developers or vendors. Because no patch exists to correct the flaw, attackers can exploit it to gain unauthorized access to systems, disrupt operations, or steal sensitive data. Zero-day attacks are especially dangerous because they target unsuspecting systems, leaving defenders without sufficient time to react until after the vulnerability is discovered and addressed.

Attackers exploit zero-day vulnerabilities for several reasons:

• Access to critical systems: Whether targeting enterprise networks or OT environments, attackers can exploit zero-day vulnerabilities to bypass security controls and gain unauthorized entry.
• Widespread impact: Exploiting a zero day in commonly used software or widely deployed systems can lead to mass compromise.
• Advantage in intelligence gathering: Nation-state threat actors frequently use zero days to extract sensitive intelligence, setting the stage for future attacks.
• Disruption: Threat actors utilize zero-day exploits as a weapon to disrupt operations, with the potential for significant financial and operational repercussions.

Recent Trends in Zero-Day Exploitation

The growing risk of zero-day vulnerabilities stems from several key factors, like the rise in interconnected devices and the wider use of open-source software. Here are some important trends to keep in mind.

1. Enterprise Software in the Crosshairs

Of the 75 zero days exploited in 2024, 44% targeted enterprise systems. Specific cases include:

• Ivanti VPN Zero Days: Ivanti’s Connect Secure VPN devices became a notable target for attackers, with seven zero days discovered, including CVE-2025-0282, which allowed remote code execution. Attackers used these vulnerabilities to inject malware into corporate networks.
• Palo Alto Networks PAN-OS: A command-injection exploit allowed attackers to bypass security controls in enterprise firewalls, exposing sensitive environments to intrusions.

Such examples underscore the need for enterprises, as high-value targets, to proactively address vulnerabilities across their technology stacks.

2. Supply Chain Attacks: The Multiplier Effect

Attackers increasingly target software supply chains, exploiting vulnerabilities at the development stage. For instance:

• MOVEit Transfer and Jenkins Vulnerabilities: A critical path traversal flaw (CVE-2024-23897) within Jenkins could result in arbitrary code execution. If exploited, attackers gain opportunities to insert malware into countless downstream applications.

Supply chains present an ideal target because a single vulnerability in shared components can impact thousands of users across industries.

3. Embedded Software Under Fire

Embedded systems used in everything from medical devices to automotive software share a unique risk in terms of zero-day vulnerabilities due to their reliance on C/C++ code. Research shows that 70% of vulnerabilities in compiled code are memory safety issues, such as buffer overflows and use-after-free errors. Attackers favor these flaws because they are difficult to detect and can cause major disruptions.

Key embedded-system sectors targeted include:

• • Industrial Control Systems (ICS) and Operational Technology: Attackers compromise OT environments in critical infrastructure, potentially causing large-scale service disruptions.
  • Automotive Software: Vulnerabilities found in connected vehicles could allow attackers to take control of core functions or extract user data.
  • Medical Devices: Unauthorized access to medical device software can compromise patient treatment and safety.

Ways to Defend Against Zero-Day Vulnerabilities

While it’s impossible to eliminate all vulnerabilities, organizations can take proactive steps to reduce their exposure to zero-day exploits. Below are actionable recommendations for enterprises and developers:

1. Adopt a Zero Trust Architecture

Zero trust assumes no implicit trust between systems. By applying strict access controls and continuously verifying users and devices, enterprises can minimize the impact of zero-day breaches.

2. Perform Dynamic and Static Analysis

Dynamic application security testing (DAST) and static application security testing (SAST) tools can identify vulnerabilities before they’re exploited. Automated testing provides invaluable insights into weak spots.

3. Deploy Runtime Protections

Solutions like runtime exploit prevention can defend applications against zero-day exploitation in live environments. For embedded systems, tools like RunSafe Protect are ideal for neutralizing memory safety vulnerabilities, providing real-time defense against exploits.

4. Strengthen Vulnerability Management Programs

A thorough vulnerability management program helps organizations prioritize high-risk systems, improve patch timelines, and reduce attack surfaces. An important starting point is to generate comprehensive SBOMs that provide visibility into software components.

5. Assess Total Zero-Day Exposure

The Google report found that use-after-free errors, command injection, and cross-site scripting (XSS) were the most frequently exploited vulnerability types. Deploying secure coding practices is one way to address these issues and minimize the number of zero-day vulnerabilities in code.

In the case of memory safety vulnerabilities, understanding potential zero-day exposure through tools like RunSafe’s Risk Reduction Analysis gives organizations unprecedented visibility into their vulnerability landscape. By analyzing return-oriented programming (ROP) chains, the analysis quantifies memory-based zero days and how much organizations can reduce risk when implementing targeted protections where they matter most.

Lessons Learned from Recent Zero-Day Incidents

The continued use of zero days by nation-state actors underscores the importance of adopting a proactive approach to security. Lessons include:

• • • Memory safety matters: With many recent exploits stemming from memory flaws, securing codebases in languages like C/C++ is paramount. Runtime protections defend new and legacy code to prevent attackers from taking advantage of these flaws.
    • Supply chain hygiene is critical: Minimizing risk in software supply chains requires vetting third-party code carefully and implementing Software Bills of Materials (SBOMs) to identify and address potential weaknesses.
    • No one is immune: Enterprises, operational technology vendors, and critical service providers alike must address their unique attack surfaces to avoid becoming the next victim of a zero-day exploit.

Gaining the Upper Hand Against Zero-Day Attacks

Nation-state actors and sophisticated criminal groups continue to leverage zero-day vulnerabilities because they consistently deliver results. The Ivanti exploits and other critical vulnerabilities throughout 2024 reinforce the need for secure coding practices and security solutions that take away attackers’ ability to exploit software flaws.

Visibility is also an important way to level the playing field. We know that memory safety flaws remain a predominant source of zero-day exploits. Tools like RunSafe’s Risk Reduction Analysis give organizations the ability to quantify their exposure to CVEs and memory-based zero days.

By analyzing an SBOM or binary, the tool gives organizations visibility into weak spots in their software and the ability to apply remediations before attackers exploit them, transforming their security posture from reactive to proactive. When it comes to zero-day vulnerabilities, knowledge isn’t just power. It’s protection.

The post Zero-Day Vulnerabilities: Exploitation Trends and Lessons Learned appeared first on RunSafe Security.

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:

1. 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.
2. 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.
3. 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.
4. 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.”
5. 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.                                     

The post Securing the ICS/OT Software Supply Chain: What Schneider Electric’s Discovery Means for Industrial Systems appeared first on RunSafe Security.

At RunSafe Security, I had the opportunity to lead the transition of our 30k lines of C++ codebase to Rust. Two things influenced our decision:

1. RunSafe wanted to address C++ memory safety concerns, and signed CISA’s Secure by Design Pledge, which includes transitioning to memory safe languages.
2. We believe that security software, which RunSafe provides, should be held to a higher level of scrutiny and correctness guarantees. For us, that meant choosing the right programming language was as important as the code itself.

The transition wasn’t without its challenges. Converting a large, established C++ codebase to Rust required careful planning, creative problem-solving, and plenty of patience. In this blog, I’ll walk you through why we chose to make the switch, the obstacles we encountered along the way, and the results we achieved. I hope these insights provide value to anyone considering a similar journey.

What Motivated the Conversion of C++ to Rust?

RunSafe chose the Rust programming language because of several advantages it offers.

1. No undefined behavior
2. Stronger type system
3. Memory safety guarantees
4. No data races

The most important advantages from our perspective were the combination of memory safety and lack of garbage collection.

Rust’s advantages extended beyond security. We also saw opportunities for:

• Cleaner, more reliable code
• Stronger compile-time guarantees
• Better performance optimization without the overhead of garbage collection

Challenges in Converting to Rust

Migrating a C++ codebase to Rust is not a decision without obstacles. For RunSafe, challenges stemmed from both technical limitations and philosophical differences in how C++ and Rust approach certain concepts.

Code and Library Compatibility Issues

• Templating vs. Generics: While C++ templates offer flexibility, they don’t cleanly map to Rust’s generic programming model, requiring manual adaptation.
• Standard Library Dependencies: Given RunSafe’s need to avoid libc dependencies for enhanced security, Rust’s #[no_std] environment became necessary. This stripped-down configuration added constraints, particularly for syscalls and memory allocations.

Dealing with Mutable State

C++ often permits unrestricted mutability, allowing developers to directly manipulate global state. Rust’s borrow checker, which enforces ownership rules, fundamentally rejects this assumption. Overcoming this required rewriting significant portions of the codebase to adhere to Rust’s stricter ownership principles.

Platform Support

C++’s compatibility with a wide range of platforms, including esoteric ones, is unmatched. Rust’s smaller ecosystem and more limited targets presented a hurdle when considering some low-level platforms that RunSafe’s software relied on.

Steps to Transition Your Code from C++ to Rust

If you’re considering converting a C++ codebase to Rust, I recommend taking a structured approach to cover all your bases. Here’s how RunSafe managed the transition:

Step 1. Evaluate and Prepare

• Review and improve test coverage to ensure consistent behavior after migration.
• Document core functionalities and interfaces clearly to plan the transition effectively.

Step 2. Plan the Conversion Approach

• Choose between manual or automated conversion. Tools like c2rust offer automated solutions, though the output may require significant refinement to fit idiomatic Rust.
• Implement an incremental conversion strategy where sections are rewritten piecemeal, avoiding wholesale changes that could introduce larger risks.

Step 3. Build a Skeleton in Rust

• Start by creating structural outlines (e.g., functions, modules) in Rust, leaving placeholders like unimplemented!() where details are pending.
• This early step helps identify ownership or mutability conflicts that need resolution.

Step 4. Refactor and Optimize

• Use Rust-specific tools like clippy to make your code cleaner and more idiomatic.
• Replace sentinel values with Rust constructs like Option or Result for better error handling.

Outcomes: What RunSafe Found

Overall, we found the transition to Rust to be successful. Key outcomes included:

• Timing: Took one engineer about 3 months of conversion time for 30k lines of code and an additional 3 months of ironing out integration bugs on esoteric platforms.
• Bugs: We found many bugs, including an incorrect argument type ported from a C++ syscall that caused visible stack corruption failures in Rust when optimized and C++ Case statements that “fell through” when they should have produced a value like Rust’s match statement.
• Size: We saw a 35% reduction in file sizes overall.
• Performance: Initially, we saw 2x slower than C++ implementation, but used profiling to lead us to targets that we would have otherwise not seen. After addressing these issues, Rust speed was roughly on par with C++.
• Safety: Required some unsafe code, which is now all behind safe abstractions.
• Good Surprises: We were confident in refactoring during this process. Moving, editing, and restructuring is substantially easier to verify when everything is more strictly checked, though it may require more effort upfront.

Should You Rewrite Your Code in Rust?

The answer depends on how critical memory safety is to your project and how often you find yourself chasing bugs caused by undefined or unreliable behavior in C++. The key question is: how much of your code actually needs rewriting?

Here are some critical factors to consider:

• Project Scope: How much of your codebase is critical enough to warrant the transition? Small, security-critical sections may provide the greatest ROI.
• Development Resources: Do your developers have experience with Rust, or will training be needed?
• Compatibility Needs: If your software targets esoteric platforms supported by C++, this may limit Rust’s viability.
• Cost and Timeline: Migration requires upfront investment, but the long-term benefits of reduced debugging and increased security often justify the effort.

Rewriting an entire million-line codebase isn’t realistic—it’s neither cost-effective nor time-efficient. However, you might identify smaller, high-risk sections of your codebase that are prone to memory safety issues. Even rewriting small portions of critical code can be enough to reduce your bug surface area.

The post Converting C++ to Rust: RunSafe’s Journey to Memory Safety appeared first on RunSafe Security.

Load-time Function Randomization (LFR), a type of runtime exploit prevention, defends software from memory-based exploits, providing much-needed protection for embedded software deployed across critical infrastructure.

How Does Load-time Function Randomization (LFR) Work?

Load-time Function Randomization (LFR) is a cutting-edge runtime application self-protection (RASP) technique specifically designed to counter memory-based exploits, which remain a persistent threat in modern software systems. By dynamically altering the memory layout of an application during its load time, LFR introduces a powerful layer of unpredictability that disrupts the strategies employed by attackers.

One of the core mechanisms of LFR is function relocation. When an application is loaded into memory, LFR systematically relocates its functions, ensuring that every runtime instance of the application features a unique memory layout. This process means that attackers cannot rely on static memory addresses to predict where specific functions are located. Instead, each execution becomes a fresh puzzle, making it nearly impossible for malicious actors to target the application with precision.

LFR also provides immunity to code exploits, particularly memory-based attacks such as buffer overflows and Return-Oriented Programming (ROP). These attacks depend on the ability to predict or manipulate the memory layout of an application. By introducing countless permutations through randomization, LFR undermines these exploit techniques, rendering them largely ineffective. This innovation raises the bar significantly for attackers, as they would need to account for an exponentially larger range of possibilities, making exploitation infeasible in most practical scenarios.

Importantly, LFR achieves all of this while ensuring the preservation of code logic. The underlying functionality and logic of the application remains unchanged, allowing developers to implement LFR without rewriting or reconfiguring their existing codebases. This seamless integration makes LFR a versatile and developer-friendly solution, offering protection without disrupting established workflows. As a result, LFR not only strengthens application defenses but also empowers development teams to focus on innovation rather than constantly reacting to emerging threats.

What Is ASLR and How Does LFR Differ?

Address Space Layout Randomization (ASLR) has been a key memory safety measure for over two decades. However, ASLR shifts entire programs or libraries as single units, leaving vulnerabilities within those layouts exploitable. One leaked memory detail can compromise the entire system.

LFR takes ASLR to the next level by offering granular protection. Instead of moving entire programs, it randomizes individual functions, creating far greater entropy and making memory corruption exploits exponentially harder to execute.

Applications of Load-time Function Randomization  

The versatility of LFR enables its application across a broad range of industries and systems.  

Proprietary Software Protection  

Organizations using C/C++ or proprietary code can protect sensitive systems from memory exploits, ensuring both performance and security remain intact.  

Embedded Systems Security  

Use cases include aerospace and defense, automotive, and medical devices with embedded software. By providing consistent memory protection, LFR reduces the need for constant patches and resource-intensive updates.  

Application Security Hardening  

DevSecOps pipelines can leverage LFR during build processes to safeguard applications from source to runtime, leading to fewer reactive fixes and enhanced customer trust.

Benefits of RunSafe’s Implementation of LFR

RunSafe Security’s solution, RunSafe Protect, integrates LFR to deliver unmatched memory protection across software systems.

1. Comprehensive Security  

LFR eliminates vulnerabilities related to memory corruption, such as buffer overflows and use-after-free attacks, protecting organizations from the most critical attack vectors.  

2. No Performance Impacts  

Unlike some security approaches that come at the cost of system speed or efficiency, LFR achieves protection with very little overhead. This makes RunSafe Protect an ideal solution for resource-constrained environments.

3. Developer-Friendly Deployment  

LFR integrates seamlessly into CI/CD pipelines without requiring changes to existing frameworks or development workflows. Its ease of use ensures minimal disruption for teams.  

4. Broad Compatibility  

LFR is effective across a range of operating systems, architectures, and industries. RunSafe Protect supports Linux, VxWorks, ARM, and Intel environments, among others.

Learn more about RunSafe Protect in our deep dive into the technology that powers it. Get the white paper: Tech Deep Dive: RunSafe Security’s Protect Solution.

Why LFR Is Essential for Software Security

Proactive defense mechanisms like LFR are no longer optional in addressing the most prevalent software weaknesses. With advanced threat actors refining their exploitation techniques and targeting critical systems, defending against memory-based vulnerabilities quickly and efficiently is a must. 

By introducing LFR, organizations can harden their systems against adversaries while preserving efficiency and reliability.

Want to explore how RunSafe Protect can elevate your software security? Request a consultation to learn more about deploying LFR.

The post What Is Load-time Function Randomization? Beyond ASLR appeared first on RunSafe Security.

Embedded systems in these industries often run on legacy devices and have lengthy lifespans, making patching and regular security scanning and vulnerability identification and mitigation difficult. Runtime Exploit Prevention, also known as Runtime Application Self-Protection (RASP), offers a powerful way to secure these devices in real time, maintaining safety and reliability. 

RASP has evolved over the years from traditional Address Space Layout Randomization (ASLR) to more modern solutions like Load-time Function Randomization (LFR), which provides an ideal solution for protecting embedded systems, effectively stopping both known and unknown threats. 

What Is Runtime Application Self-Protection (RASP)?

Runtime Exploit Prevention involves measures designed to dynamically neutralize attacks while an application is live. Instead of relying solely on pre-deployment defenses like code reviews or penetration testing, these measures work during execution to detect, block, and adapt to threats in real time.

At the heart of this concept is Runtime Application Self-Protection (RASP). Unlike traditional security methods, RASP directly integrates into the application, constantly monitoring and protecting it from inside. It doesn’t rely on external tools or hardware, making it uniquely positioned to detect suspicious behaviors like unexpected input or exploitative code patterns at runtime.

RASP is particularly effective against memory corruption exploits, such as buffer overflows and Return-Oriented Programming (ROP) attacks, which are challenging to address with conventional security solutions.

Why Is Runtime Exploit Prevention Critical?

Runtime exploit prevention addresses vulnerabilities that emerge after deployment, where traditional preemptive measures fall short. Some of the key reasons RASP has grown in importance include:

• Proactive Defense: It identifies and mitigates attacks as they occur, preventing breaches before they cause damage.
• Adaptability: RASP solutions, such as Load-Time Function Randomization (a RASP technique used in tools like RunSafe Protect), make systems dynamic by altering code layouts during runtime. This frustrates attackers and neutralizes memory-based exploits.
• Reduced Cost and Downtime: By providing built-in defenses, RASP reduces the need for costly patches and emergency fixes after deployment.

Commonly, RASP is used in critical applications where downtime or breaches are unacceptable, including healthcare systems, ICS/OT environments, and military infrastructure.

How Does Runtime Exploit Prevention Protect Embedded Systems?

Embedded systems, like those found in vehicle control systems or industrial control units, are central to modern technology and are incredibly vulnerable. In particular, memory-based vulnerabilities are one of the biggest weaknesses in embedded software.

Runtime exploit prevention, like LFR, secures embedded systems without requiring code rewrites. For example, LFR provides advanced runtime protection by randomizing individual functions within a program to create a unique memory layout every time the software loads, creating a moving target for attackers.

More importantly, LFR can operate even in resource-constrained environments—making it ideal for low-power devices, mission-critical military systems, or embedded vehicle software. RunSafe’s Protect solution, for instance, integrates seamlessly into existing DevSecOps pipelines, ensuring that embedded systems are protected during runtime without sacrificing performance or requiring significant engineering effort.

Vulnerabilities Runtime Exploit Prevention Addresses

Runtime exploit prevention is specifically effective against various high-risk vulnerabilities, including:

1. Memory Corruption Exploits: Prevents buffer overflows, heap overflows, and stack-based attacks.
2. Return-Oriented Programming (ROP): Disrupts attackers’ ability to exploit pre-existing instructions within an application.
3. Use-After-Free Exploits: Mitigates common vulnerabilities by randomizing memory layouts, rendering leaked addresses useless.
4. Code Injection Attempts: Detects and blocks malicious instructions before execution.
5. Zero-Day Vulnerabilities: Provides protection for memory-based zero days even when the vulnerability is unknown at the time of deployment.

These capabilities are essential at a time when memory safety vulnerabilities account for nearly 70% of all exploitable software flaws, as highlighted by the National Security Agency (NSA).

What Types of RASP Tools Are Available?

The market for runtime application self-protection tools is expanding rapidly. These tools offer unique features tailored to the needs of different industries. Here’s a look at common types of RASP tools:

• Function-Level RASP Solutions: These tools randomize memory layouts of individual functions or processes. For example, RunSafe Protect’s Load-Time Function Randomization (LFR) offers unparalleled memory diversification.

• Behavioral Analysis-Based Tools: Tools like Imperva RASP actively monitor and analyze application behavior, blocking threats based on unusual input patterns or system calls.

• Language-Specific RASP Solutions: Some tools are designed for specific programming languages. For instance, Checkmarx offers RASP capabilities targeted at Java and .NET applications.

• Integrated DevSecOps Platforms: Solutions such as Veracode integrate RASP directly into CI/CD systems, providing protection throughout the development lifecycle.

How RunSafe’s RASP Solution Stands Out

RunSafe Security’s Protect solution takes runtime exploit prevention to the next level. By implementing advanced RASP techniques and innovative Moving Target Defense (MTD) mechanisms, it provides comprehensive protection against memory-based attacks. 

Here’s what sets RunSafe apart:

1. Function Randomization: RunSafe’s patented LFR technology scrambles memory layouts each time software runs, creating billions of possible configurations. This makes reliable exploitation nearly impossible for malware.
2. Seamless Integration: Protect integrates directly into existing DevSecOps workflows, requiring no changes to codebases or build systems.
3. Low Overhead: Unlike traditional runtime security tools, Protect has minimal impact on performance—less than 1% overhead in most use cases. This makes it suitable for real-time and embedded systems.
4. Broad Applicability: Protect supports an extensive range of platforms, including Linux, Windows, and embedded architectures like ARM. This flexibility makes it ideal for securing applications across industries.
5. Resilient to Zero Days: Protect reduces the exploitability of memory-based zero-day vulnerabilities, ensuring applications remain secure even against unknown threats.

RunSafe’s unique focus on runtime memory protection solves one of the biggest risks to embedded software, addressing both known and unknown memory-based vulnerabilities to safeguard critical systems.

Final Thoughts on Adopting Runtime Exploit Prevention

Whether you’re a medical device manufacturer or developing military systems, runtime exploit prevention is an essential layer of defense. RASP represents a shift from reactive to proactive cybersecurity, addressing risk not just at deployment but throughout a device’s lifecycle.

Learn more about RunSafe Protect in our deep dive into the technology that powers it. Get the white paper: Tech Deep Dive: RunSafe Security’s Protect Solution.

The post What Is Runtime Exploit Prevention? Securing Embedded Software with RASP appeared first on RunSafe Security.

RunSafe Security and Lynx are partners in securing embedded software platforms.

For too long, open source vulnerability management has been treated as a reactive game of whack-a-mole: identify vulnerabilities, patch them, and repeat. This approach often leaves teams overwhelmed and constantly playing catch-up. 

What if we flipped the script? Vulnerabilities aren’t just problems—they’re signals. They reveal weaknesses, highlight opportunities, and guide better decisions. By treating vulnerabilities as feedback rather than failures, you can rethink how embedded systems in industries like aerospace, automotive, industrial automation, and medical devices are designed and secured. 

In this article, we explore five transformative strategies for addressing open source vulnerabilities that go beyond traditional practices, helping you move from firefighting to future-proofing your systems.

1. Redefine Your Relationship with Vulnerabilities

Most teams view vulnerabilities as failures, reacting only when an issue is discovered. But vulnerabilities are more than just bugs—they’re data points. When properly analyzed, they offer insight into design choices, team processes, and system architecture, providing an opportunity for improvement. 

How to Leverage Vulnerabilities as Feedback 

• Refine your software architecture: Use your SBOM (Software Bill of Materials) as a diagnostic tool. Are recurring vulnerabilities tied to a particular library or dependency? Consider switching to better-maintained or less vulnerable alternatives. 
• Understand system dynamics: Track patterns across projects and teams to identify development blind spots. 

Real-World Application:
Imagine an automotive team that regularly identified vulnerabilities in a third-party diagnostic library. By switching to an open-source alternative with a more active community, they reduced vulnerabilities by 40% and enhanced system reliability. 

This proactive approach fosters confidence in your processes, ensuring continuous improvement. 

What is an SBOM (Software Bill of Materials)? SBOMs are a list of all components in a software build, including libraries and dependencies, which helps teams identify and track vulnerabilities systematically. 

Understanding the full scope of an SBOM enables more informed decisions about system modifications and vulnerability management strategies, leading to more secure software architectures.

2. Embed Resilience Instead of Chasing Compliance

Compliance frameworks like DO-326A (aerospace cybersecurity), ISO/SAE 21434 (automotive cybersecurity), and NIST Cybersecurity Framework provide a baseline for secure systems. But achieving compliance shouldn’t be the end goal—it’s the beginning. Resilience is about building systems that remain secure even as threats evolve, ensuring compliance is naturally met as a byproduct. 

How to Build Resilience That Meets Compliance 

• Design with failure scenarios in mind: Use threat modeling to identify potential attack vectors early during development. 
• Automate compliance reporting: Tools like Lynx Vigiles simplify audit preparation, allowing teams to focus more on security instead of documentation. 

Pro Tip:
Treat compliance as a checkpoint, not a destination. Teams that embed cybersecurity into their workflows achieve compliance faster and with fewer reworks. 

Threat modeling: Identifying potential security threats to the system and developing countermeasures to prevent or mitigate these threats.

3. Focus on Vulnerability Paths, Not Just Individual Flaws

Attackers don’t exploit single vulnerabilities in isolation; they look for exploit paths—chains of vulnerabilities that can lead to system failure. Addressing how open source vulnerabilities interact within your system can stop attacks before they start. 

How to Identify and Break Exploit Paths 

• Map dependencies: Visualize how different components interact and assess how vulnerabilities in one might expose others. 
• Prioritize by context: What may be a low-severity issue in an industrial control system could be critical if it enables lateral movement to safety-critical functions. 

Example:
In an industrial automation system, a minor flaw in a third-party networking library allowed attackers to bypass authentication. Fixing this vulnerability preemptively protected safety-critical systems. While the flaw might not have drawn much attention in isolation, its potential impact within a chain of vulnerabilities highlighted its true risk. 

Power Move:
Integrate RunSafe Security’s memory address randomization to protect against memory-based attacks, common in exploit paths. This technique, applied during the software compilation process, randomizes the layout of memory addresses within a program. By making the memory structure unpredictable, it significantly impedes attackers’ ability to craft exploits that rely on known memory locations, thereby neutralizing a substantial portion of memory corruption vulnerabilities. 

Mapping dependencies and breaking exploit paths: This strategy involves visualizing the interconnections between software components to identify and disrupt sequences of vulnerabilities that could be chained together by an attacker, thereby preventing a single weakness from compromising the entire system.

4. Shift Vulnerability Ownership Across the Organization

Vulnerability management is often confined within security or DevSecOps teams. However, for a system to be secure, everyone—developers, product managers, and leadership—must share responsibility. Security is a business-critical priority, not just a technical concern. 

How to Foster Organizational Ownership 

• Set team-level goals: Include vulnerability remediation and time-to-resolution as part of team OKRs and KPIs. 
• Invest in security training: Equip all team members with the knowledge to identify and mitigate vulnerabilities early. Think of it as the equivalent of educating your team not to plug in random USB sticks found in the wild, except for open source vulnerabilities. 

Pro Tip:
Make vulnerability metrics visible across the organization to encourage collaboration. Teams that understand their impact on overall security are more motivated to act. This shared responsibility leads to a quicker resolution of vulnerabilities, reducing the window of exposure and enhancing overall system security.

5. Use Automation to Do the Heavy Lifting, but Keep Humans in the Loop

Automation is essential for managing the sheer volume of vulnerabilities in modern embedded systems. But tools alone aren’t enough. Strategic oversight ensures that fixes align with business goals, technical feasibility, and long-term resilience. 

How to Combine Automation with Expertise 

• Automate triage: Use tools like Vigiles to filter out non-applicable vulnerabilities, focusing your team on critical issues. 
• Enable smarter decisions: Human judgment is critical for balancing security with operational needs, especially in safety-critical industries. 

Example:
An aerospace company used automated scanning with basic filters and faced over 1,000 vulnerabilities. Enhancing these filters with additional context and capabilities, such as with Vigiles, they saw half automatically marked as non-applicable. This effective triage cut their potential workload in half and allowed them to thoroughly assess high and critical severity vulnerabilities impacting system safety, saving weeks of manual effort and unnecessary remediation. 

Including RunSafe Security’s runtime memory protection during the compilation process drastically lowers the risks associated with common memory vulnerabilities, allowing security teams to focus on more complex threats. 

These approaches not only optimize resource allocation but also enhance the accuracy and relevance of vulnerability management efforts, leading to a more resilient system. 

The Cost of Inaction: Addressing Open Source Vulnerabilities 

Neglecting to adopt proactive strategies for open source vulnerability management comes at a high cost: 

• Missed deadlines: Vulnerabilities discovered late disrupt production schedules. 
• Compliance failures: Inadequate processes expose teams to regulatory penalties. 
• System compromises: Unchecked exploit paths can lead to catastrophic consequences. 

Every delay in addressing vulnerabilities isn’t just a technical risk—it’s a threat to your mission, your reputation, and your bottom line.

Conclusion: Security as a System 

Rethinking open-source vulnerability management is about more than fixing issues—it’s about designing systems that are secure by default. By redefining your relationship with vulnerabilities, embedding resilience, focusing on exploit paths, fostering organizational ownership, and leveraging automation, you can move from firefighting to future-proofing your embedded systems. 

Take the next step today: 

• Don’t wait for open source vulnerabilities to disrupt your operations. Cut through the noise with Lynx Vigiles and focus on the vulnerabilities that matter most. 
• Discover RunSafe Security’s runtime protection to neutralize vulnerabilities before attackers can take root.

The post Rethinking Open Source Vulnerability Management: 5 Strategies to Build Resilience in Embedded Systems appeared first on RunSafe Security.

Software Bills of Materials (SBOMs) are a detailed inventory of all the components—open source, proprietary, and third-party—used within a software application. SBOMs play a key role in ensuring software integrity, managing security risks, and strengthening software supply chain security. 

As SBOM requirements expand around the globe, organizations need to be able to generate SBOMs quickly and efficiently to minimize development lifecycle overhead. Depending on the type of software projects you develop and maintain, there are different types of SBOM generation techniques that will work best in different scenarios. Additionally, the way an SBOM is generated affects its accuracy and completeness and your visibility into software vulnerabilities.

Here, we break down the three main types of SBOMs, why SBOMs are important for vulnerability identification and management, and special considerations for C/C++ projects.

Binary-Based SBOMs: The Pre-Packaged View

Binary-based SBOMs are generated by analyzing compiled software, focusing on the final product rather than the source code or build process. The approach works by examining the binary to identify its components and dependencies. 

Binary-based SBOMs are useful for legacy software and older systems where source code is either unavailable or inaccessible. They also enable the analysis of third-party software components without requiring access to their source code. 

However, relying solely on binary analysis often results in SBOMs that lack critical details that can only be captured during the build process, the most notable example being the existence of statically linked libraries. Some auxiliary data is also lost during compilation, making it difficult to trace the origin and history of certain components due to limited provenance information. 

The lack of visibility often leads to a high rate of false positives, as accurately determining the contents of a binary without insight into the actual build is inherently challenging. While valuable in specific scenarios, binary-based SBOMs are less precise compared to other SBOM generation methods.

Key takeaway: Binary-based SBOMs provide a practical solution for managing legacy systems or third-party components. However, they typically lack the depth and accuracy of SBOMs generated from source code or during the build process, often resulting in less detail and a higher likelihood of false positives.

Build-time SBOMs are considered the most accurate and efficient method for tracking software components because they are generated during the compilation process, providing a detailed and reliable view of all the components included in the final software build.

Build-time SBOMs execute against the precise components that will be in the build and only contain the relevant libraries and the specific sub-components used in said libraries during the building of the compiled output. Build-time SBOMs are also able to capture all external or linked resources that are only included at build time.

The precision of build-time SBOMs reduces alert fatigue and saves engineering teams time by minimizing false positives and eliminating the need to investigate reported vulnerabilities on components that will not be in the final build and that do not present a risk to production.

When implementing build-time SBOMs, look for solutions that easily integrate into your CI/CD pipeline and existing development workflows. For them to be useful, they must fit smoothly into automated workflows without adding extra complexity or causing delays. Also consider performance. Build-time SBOMs increase accuracy, but should not come at the cost of slowing down build times significantly.

Key takeaway: Build-time SBOMs offer the most precise and comprehensive tracking of software components, making them essential for strengthening software supply chain security and minimizing false positives. They can also be created for legacy software where the source code is readily available. To maximize their impact, choose solutions that seamlessly integrate into your CI/CD pipeline.

 

Choosing Your SBOM Generation Tool: Implications for Vulnerability Identification

The type of SBOM you choose can significantly impact your software security efforts. When selecting an SBOM generation tool, consider your specific needs, access to source code, and desired accuracy level. For most modern development environments, build-time SBOMs will provide the most value and the clearest picture of your software’s actual composition. A complete and accurate picture of your software’s composition enables more effective vulnerability identification and risk management, allowing you to:

• Maintain strong software supply chain security
• Efficiently identify and address vulnerabilities
• Deliver more secure products
• Meet SBOM regulatory compliance requirements

SBOM Generation for C/C++ Projects

Generating SBOMs for C/C++ projects is challenging because of the complexity and legacy nature of these ecosystems. It is not simple to gather the data and information needed to create comprehensive and accurate SBOMs.

The typical approach is to use package-based component mapping. However, unlike modern languages like Python or Rust, C/C++ doesn’t have a widely adopted package manager, making it difficult to automatically track dependencies.

Without the availability of package managers, each C/C++ SBOM generator has to take an unorthodox approach to SBOM generation, whether it’s by relying on the compiler’s use of files during the build process, the generation of symbols during compilation, or methods yet to be developed. However, each method provides absolute clarity into the build process as it is happening, resulting in high fidelity with no package manager required.

A build-time approach is ideal for real-time and embedded software, giving visibility into your software components with a full dependency tree.

Build-Time SBOMs Lead the Way in Modern Software Security and Compliance

Selecting the right SBOM generation method is vital for ensuring secure and compliant software products. The key to success is choosing an SBOM generation strategy that fits your specific needs, factoring in elements like source code accessibility, development processes, and desired accuracy. 

No matter the approach, adopting strong SBOM practices is essential to meet regulatory standards, effectively manage vulnerabilities, and deliver secure, resilient software.

The post What Is a SBOM? Binary vs Build-Time vs Source Code appeared first on RunSafe Security.

Memory safety vulnerabilities remain one of the most persistent and exploitable weaknesses across software. From enabling devastating cyberattacks to compromising critical systems, these vulnerabilities present a constant challenge for developers and security professionals alike.

Both the National Security Agency (NSA) and the Cybersecurity and Infrastructure Security Agency (CISA) have emphasized the importance of addressing memory safety issues to defend critical infrastructure and stop malicious actors. Their guidance highlights the risks associated with traditional memory-unsafe languages, such as C and C++, which are prone to issues like buffer overflows and use-after-free errors.

In February 2025, CISA drilled down even deeper with their guidance, issuing an alert on “Eliminating Buffer Overflow Vulnerabilities.”

Why do memory corruption vulnerabilities still exist, how do they manifest in practice, and what strategies can organizations implement to mitigate their risks effectively? Let’s take a look.

What Are Memory Safety Vulnerabilities?  

Memory safety vulnerabilities occur when a program performs unintended or erroneous operations in memory. These issues can lead to dangerous consequences like data corruption, unexpected application behavior, or even full system compromise. Common Weakness Enumeration (CWEs), a body of knowledge tracking software vulnerabilities, highlights these as some of the most severe weaknesses in software today.

Memory safety issues are inherently tied to programming languages and runtime environments. Languages like C and C++ offer control and performance but lack built-in memory safety mechanisms, making them more prone to such vulnerabilities.

Attackers leverage memory corruption vulnerabilities as access points to infiltrate systems, exploit weaknesses, and execute malicious actions. Addressing memory vulnerabilities is essential for safety and security, especially for industries like critical infrastructure, medical devices, aviation, and defense.

Types of Memory Safety Vulnerabilities 

There are many different types of memory safety vulnerabilities, but there are particular ones that developers and security professionals should understand. The six explained below are listed on the 2024 Common Weakness Enumeration (CWE™) Top 25 Most Dangerous Software Weaknesses list (CWE™ Top 25), and are familiar faces on the list from previous years. The CWE Top 25 lists vulnerabilities that are easy to exploit and that have significant consequences.

1. Buffer Overflows (CWE-119) 

A buffer overflow occurs when a program writes more data to a buffer than it can safely hold. This overflow can corrupt adjacent memory, potentially leading to crashes, data corruption, or even allowing attackers to execute arbitrary code. 

Example of a Buffer Overflow

A notable example of a buffer overflow vulnerability is CVE-2023-4966, also known as “CitrixBleed,” which affected Citrix NetScaler ADC and Gateway products in 2023. This critical flaw allowed attackers to bypass authentication, including multi-factor authentication, by exploiting a buffer overflow in the OpenID Connect Discovery endpoint.

 The vulnerability enabled unauthorized access to sensitive information, including session tokens, which could be used to hijack authenticated user sessions. Discovered in August 2023, CitrixBleed was actively exploited by various threat actors, including ransomware groups like LockBit, leading to high-profile attacks such as the Boeing ransomware incident. 

This vulnerability highlights the ongoing significance of buffer overflow vulnerabilities in critical infrastructure and the importance of prompt patching and session invalidation to mitigate potential compromises

2. Heap-Based Buffer Overflow (CWE-122) 

A heap-based buffer overflow occurs when a program writes more data to a buffer located in the heap memory than it can safely hold. This can lead to memory corruption, crashes, privilege escalation, and even arbitrary code execution by attackers manipulating the heap memory structure.

Example of a Heap-Based Buffer Overflow 

An example of a recent critical heap-based buffer overflow is CVE-2024-38812, a vulnerability in VMware vCenter Server, discovered during the 2024 Matrix Cup hacking competition in China. With a CVSS score of 9.8, this flaw allows attackers with network access to craft malicious packets exploiting the DCERPC protocol implementation, potentially leading to remote code execution. This heap overflow vulnerability was initially patched but required a subsequent update to fully address the issue.

3. Use-After-Free Errors (CWE-416) 

Use-after-free errors arise when a program continues to use a memory pointer after the memory it points to has been deallocated. This can lead to system crashes, data corruption, or exploitation through arbitrary code execution. 

Example of a Use-After-Free Error

CVE-2021-44710 is a critical use-after-free UAF vulnerability discovered in Adobe Acrobat Reader DC, affecting multiple versions. The vulnerability has a CVSS base score of 7.8, indicating its high severity. If successfully exploited, an attacker could potentially execute arbitrary code on the target system, leading to various severe consequences including application denial-of-service, security feature bypass, and privilege escalation.

4. Out-of-Bounds Write (CWE-787) 

An out-of-bounds write occurs when a program writes data outside the allocated memory buffer. This can corrupt data, cause crashes, or create vulnerabilities that attackers can exploit. 

Example of an Out-of-Bounds Write

CVE-2024-7695 is a critical out-of-bounds write vulnerability affecting multiple Moxa PT switch series. The flaw stems from insufficient input validation in the Moxa Service and Moxa Service (Encrypted) components, allowing attackers to write data beyond the intended memory buffer bounds.

With a CVSS 3.1 score of 7.5 (High), this vulnerability can be exploited remotely without authentication. Successful exploitation could lead to a denial-of-service condition, potentially causing significant downtime for critical systems by crashing or rendering the switch unresponsive.

5. Improper Input Validation (CWE-020) 

Improper input validation occurs when a system fails to adequately verify or sanitize inputs before they are processed. This flaw can lead to unintended behaviors, including command injection, buffer overflows, or unauthorized access. Attackers exploit this weakness by crafting malicious inputs, often bypassing security controls or causing system failures. Input validation issues are particularly common in web applications and embedded systems where external data is heavily relied upon. 

Example of Improper Input Validation

CVE-2024-5913 is a medium-severity vulnerability affecting multiple versions of Palo Alto Networks PAN-OS software. This improper input validation flaw allows an attacker with physical access to the device’s file system to elevate privileges.

6. Integer Overflow or Wraparound (CWE-190) 

Integer overflow or wraparound occurs when an arithmetic operation results in a value that exceeds the maximum (or minimum) limit of the data type, causing the value to “wrap around.” This vulnerability can lead to unpredictable behaviors, such as buffer overflows, memory corruption, or security bypasses. Attackers exploit this weakness by manipulating inputs to trigger overflows, often resulting in system crashes or unauthorized actions. This issue is common in low-level programming languages like C and C++, where integer operations are not inherently checked.

Example of an Integer Overflow

CVE-2022-2329 is a critical vulnerability (CVSS 3.1 Base Score: 9.8) affecting Schneider Electric’s Interactive Graphical SCADA System (IGSS) Data Server versions prior to 15.0.0.22074. This Integer Overflow or Wraparound vulnerability can cause a heap-based buffer overflow, potentially leading to denial of service and remote code execution when an attacker sends multiple specially crafted messages. Schneider Electric released a patch to address this vulnerability.

Memory CVEs Affecting Critical Infrastructure

Recently, nation-state actors, like the Volt Typhoon campaign, have demonstrated the potential real-world impact of memory safety vulnerabilities in the software used to run critical infrastructure.

Additionally, in the last few years, memory safety vulnerabilities within ICS have seen a steady upward trend. There were less than 1,000 CVEs in 2014 but nearly 3,000 in 2023 alone.

Here are a few examples of memory safety vulnerabilities directly impacting critical infrastructure.

Ivanti Connect Secure Flaw

A zero-day vulnerability (CVE-2025-0282) in Ivanti’s Connect Secure appliances allowed remote code execution, enabling malware deployment on affected devices.

Siemens UMC Vulnerability

A heap-buffer overflow flaw (CVE-2024-49775) in Siemens’ industrial control systems exposed critical infrastructure to risks of arbitrary code execution and disruption.  

Mercedes-Benz Infotainment System

Over a dozen vulnerabilities in the Mercedes-Benz MBUX system could allow attackers with physical access to disable anti-theft measures, escalate privileges, or compromise data.

Rockwell Automation Vulnerability

A denial-of-service and possible remote code execution vulnerability (CVE-2024-12372) in Rockwell Automation’s PowerMonitor 1000 Remote product. This heap-based buffer overflow could compromise system integrity.

Why Addressing Memory Vulnerabilities Is Critical 

Memory vulnerabilities represent a significant share of software-based attacks. According to a study by CISA, two-thirds of vulnerabilities in compiled code stem from memory safety issues. These vulnerabilities can impact industries that depend heavily on legacy systems written in C and C++—industries like aerospace, manufacturing, and energy infrastructure.

Key Risks Posed by Memory Vulnerabilities:

• Remote Control Exploits: Attackers can hijack systems, gaining full control over operations.
• Data Breaches: Sensitive information can be corrupted, stolen, or erased.
• Operational Downtime: System instability leads to interruptions in critical services.
• Compliance Failures: Organizations risk fines for failing to meet cybersecurity regulations.

The post Understanding Memory Safety Vulnerabilities: Top Memory Bugs and How to Address Them appeared first on RunSafe Security.

Over the past several years, regulators around the globe have begun issuing Software Bill of Materials (SBOM) requirements and standards in an effort to strengthen software security. SBOMs are a detailed inventory of all the components—open source, proprietary, and third-party—used in a software application. SBOMs provide visibility into software components and are a valuable tool for strengthening software supply chain security and traceability.  Why are regulators focusing on SBOMs now, and what does that mean for your software development practices?  This guide will take a look at SBOM requirements around the globe, their origins, and emerging global trends. Whether you’re a software developer or part of a security-focused team, staying updated on SBOM regulations is critical for compliance and safeguarding your software ecosystem. 

Why SBOMs Are Becoming a Must-Have

SBOM requirements didn’t emerge in a vacuum. They were born in response to two major software supply chain attacks, the most infamous of which was the SolarWinds attack of 2020. 

1. The SolarWinds Attack of 2020 

The SolarWinds attack marked a turning point in cybersecurity history. This sophisticated supply chain compromise impacted over 18,000 organizations, including multiple U.S. federal agencies. Attackers leveraged vulnerabilities in SolarWinds’ software updates to gain unauthorized access, demonstrating how a lack of visibility into source components could have devastating consequences.  The fallout from this attack placed a spotlight on SBOMs as a tool to identify and mitigate risks in software supply chains. By providing detailed inventories of software components, SBOMs have since emerged as a foundational element of secure software development practices. 

2. The Log4Shell Vulnerability 

Another major wake-up call came in late 2021 with the discovery of the Log4Shell vulnerability. This critical flaw in the widely-used Log4j library exposed organizations worldwide to potential exploitation. Many companies scrambled to assess their exposure, yet their lack of comprehensive SBOMs caused unnecessary delays in response times.  These incidents collectively underscored the critical importance of having a full inventory of software dependencies to identify vulnerabilities quickly and ensure timely remediation. 

The post A Guide to SBOM Requirements Around the Globe appeared first on RunSafe Security.

Despite these challenges, applying patches quickly remains an industry-best practice for keeping software and embedded devices secure. However, relying solely on scanning and patching is proving inadequate for modern security needs. The challenge now for software manufacturers is finding ways to improve the patching process to proactively and strategically defend embedded systems.

This blog will explore:

• When organizations should prioritize patching
• How reachability analysis is evolving but remains limited
• The role of runtime protection solutions in reducing vulnerability severity
• The tangible benefits of runtime security for developers and software manufacturers

When Should You Apply a Patch?

Severity remains a top qualifier when deciding which vulnerabilities to patch. Most organizations focus on critical and high vulnerabilities first, moving on to medium and low severities only when practical. For publicly released software, external-facing systems take precedence, but it’s important to remember that internal tools with access to sensitive data or proprietary information shouldn’t be ignored either.

For example:

• Critical vulnerabilities affecting widespread functionality or enabling remote code execution often warrant immediate action.
• Medium or low vulnerabilities might be deprioritized but can still pose risks depending on their reachability or the systems they impact.

Reachability Analysis as a Future Tool

One potential solution to this prioritization problem is reachability analysis, which assesses whether a specific vulnerability is exploitable in a given system. While some tools already provide reachability analysis for languages like JavaScript and Python, their accuracy and adoption remain inconsistent. Unfortunately, such solutions are not yet widely available for languages like C and C++, which underpin many embedded and legacy systems.

This is where runtime security solutions come into play.

Reducing Vulnerability Severity with Runtime Security Solutions

Runtime security solutions provide an innovative approach to mitigating vulnerabilities without waiting for patch cycles. By securing software in real-time, these tools reduce the operational urgency to patch, buying teams valuable time while still maintaining protection against exploits.

A key benefit of runtime solutions is it allows organizations to reduce the severity score of common vulnerabilities found across embedded software. For example, a significant number of embedded systems are written in memory-unsafe languages such as C and C++. These systems are uniquely vulnerable to memory-based vulnerabilities, including buffer overflows and use-after-free errors. Alarmingly, 70% of zero-day exploits stem from memory corruption vulnerabilities, leading to severe repercussions like remote code execution.

By eliminating memory-based vulnerability exploitability, runtime solutions offer immediate security benefits to embedded systems, including the ability to lower vulnerability severity and reduce the need to patch.

How RunSafe Protect Reduces Vulnerability Severity

Solutions like RunSafe Protect directly mitigate memory-based vulnerabilities at runtime. By doing so, developers can reduce the severity of vulnerabilities based on their Common Vulnerability Scoring System (CVSS) rating. For instance:

• Using the CVSS v4.0 calculator, developers can adjust parameters such as availability and integrity to “none” for memory-based CVEs mitigated by RunSafe Protect.
• This adjustment effectively reduces the CVSS score to zero, making the vulnerability non-exploitable.

Critically, this mitigation doesn’t replace patching—it complements it. Teams should continue to scan for vulnerabilities, adjust severity scores based on runtime mitigations, and follow existing risk management guidelines. However, runtime security minimizes the urgency associated with patching, ensuring systems remain defended while developers work on longer-term fixes.

The Broader Benefits of Runtime Security Solutions

Implementing runtime security doesn’t just enhance protection—it also delivers measurable benefits to both development teams and overall organizational efficiency. Here’s how:

Improved Operations and Smoother Patch Schedules

With runtime protections in place, patching schedules can be aligned with planned updates, reducing the need for emergency patches that disrupt workflows. Developers gain more time to properly develop, test, and deploy patches without compromising security.

Saving Developer Resources

Patching is a time-intensive process. By ensuring vulnerabilities are mitigated at runtime, runtime solutions free up developers to focus on their core tasks—writing new code and shipping innovative products. This operational efficiency directly enhances the organization’s productivity.

Enhanced Customer and Stakeholder Confidence

When vulnerabilities are mitigated at runtime, organizations can issue security advisories that reassure customers and partners. The ability to state that systems are already protected thanks to runtime protections strengthens confidence in your processes and builds trust with stakeholders.

Economic Advantages

The financial benefits are clear:

• Lower risk of costly breaches or operational downtime
• Smoother allocation of development and security resources
• Greater ability to prioritize business growth over firefighting vulnerabilities

By reducing workload, mitigating risk, and streamlining operations, runtime security ensures organizations achieve both technical and business goals.

Practical Steps for Smooth Patch Management

Runtime security solutions like RunSafe Protect offer organizations breathing room. But patching remains an essential element of your cybersecurity strategy. Here are recommended next steps for improving your patch management workflow:

1. Adopt a Comprehensive Vulnerability Management Plan: Use tools that perform regular scans, prioritize vulnerabilities by severity, and integrate runtime protections to reduce urgent patches.
2. Leverage Runtime Security Solutions: Introduce tools that can instantly mitigate known vulnerability types, especially memory-based vulnerabilities common in critical systems.
3. Invest in Reachability Analysis Tools: When available, these tools can help you focus patching efforts on the most exploitable vulnerabilities.
4. Regularly Align Security Updates with Operational Schedules: Plan patches during downtime or alongside regular updates to minimize disruption.

By adopting a layered approach to vulnerability management, organizations can keep systems secure without overburdening teams or disrupting day-to-day operations.

Take Control of Your Patch Management Strategy

Patching may remain one of the most difficult tasks in embedded systems, but it doesn’t have to drain resources or derail business priorities. By supplementing traditional scanning and patching processes with runtime security solutions, organizations can reduce vulnerability severity, protect critical systems, and empower development teams to focus on the future. Want to simplify vulnerability identification and automate mitigations?

Explore how the RunSafe Security Platform can reduce the severity of memory-based vulnerabilities and smooth out your patching process.

The post Smooth Out Your Patch Management: How to Reduce Vulnerability Severity appeared first on RunSafe Security.