For decades, cybersecurity relied on shared visibility into common codebases. When a flaw was found in OpenSSL or Log4j, the community could respond: identify, share, patch, and protect.

AI-generated code breaks that model. Instead of re-using an open source component and having to comply with license restrictions, one can use AI to rewrite a near similar version but not use the exact open source version.

I recently attended SINET New York 2025, joining dozens of CISOs and security leaders to discuss how AI is reshaping our threat landscape. One key concern surfaced repeatedly: Are we vibe coding our way to a crisis?

Listen to the Audio Overview

Losing the Commons of Vulnerability Intelligence

At the SINET New York event, Tim Brown, VP Security & CISO at SolarWinds, pointed out that with AI coding, we could lose insights into common third-party libraries.

He’s right. If every team builds bespoke code through AI prompts, including similar to but different than open source components,  there’s no longer a shared foundation. Vulnerabilities become one-offs. If we are not using the same components, we won’t have the ability to share vulnerabilities. And that could lead to a situation where you have a vulnerability in your product that somebody else won’t know they have.

The ripple effect is enormous. Without shared components, there’s no community-driven detection, no coordinated patching, and no visibility into risk exposure across the ecosystem. Every organization could be on its own island of unknown code.

AI Multiplies Vulnerabilities

Even more concerning, AI doesn’t “understand” secure coding the way experienced engineers do. It generates code based on probabilities and its training data. A known vulnerability could easily reappear in AI-generated code, alongside any new issues.

Veracode’s 2025 GenAI Code Security Report found that “across all models and all tasks, only 55% of generation tasks result in secure code.” That means that “in 45% of the tasks the model introduces a known security flaw into the code.”

For those of us at RunSafe, where we focus on eliminating memory safety vulnerabilities, that statistic is especially concerning. Memory-handling errors — buffer overflows, use-after-free bugs, and heap corruptions — are among the most dangerous software vulnerabilities in history, behind incidents like Heartbleed, URGENT/11, and the ongoing Volt Typhoon campaign.

Now, the same memory errors could appear in countless unseen ways. AI is multiplying risk one line of insecure code at a time.

Signature Detection Can’t Keep Up

Nick Kotakis, former SVP and Global Head of Third-Party Risk at Northern Trust Corporation, underscored another emerging problem: signature detection can’t keep up with AI’s ability to obfuscate its code.

Traditional signature-based defenses depend on pattern recognition — identifying threats by their known fingerprints. But AI-generated code mutates endlessly. Each new build can behave differently and conceal new attack vectors.

In this environment, reactive defenses like signature detection or rapid patching simply can’t scale. By the time a signature exists, the exploit may already have evolved.

Tackling the Memory Safety Challenge

So how do we protect against vulnerabilities that no one has seen — and may never report?

At RunSafe, we focus on one of the most persistent and damaging categories of software risk: memory safety vulnerabilities. Our goal is to address two of the core challenges introduced by AI-generated code:

• Lack of standardization, as every AI-written component can be unique
• No available patches, as many vulnerabilities may never be disclosed

By embedding runtime exploit prevention directly into applications and devices, RunSafe prevents the exploitation of memory-based vulnerabilities, including those that are unknown or zero days.

That means even before a patch exists, and even before a vulnerability is discovered, RunSafe Protect keeps code secure whether it’s written by humans, AI, or both.

Building AI Code Safely

AI-generated code is here to stay. It has the potential to speed up development, lower costs, and unlock new capabilities that would have taken teams months or years to build manually.

However, when every product’s codebase is unique, traditional defenses — shared vulnerability intelligence, signature detection, and patch cycles — can’t keep up. The diversity that makes AI powerful also makes it unpredictable.

That’s why building secure AI-driven systems requires a new mindset that assumes vulnerabilities will exist and designs in resilience from the start. Whether it’s runtime protection, secure coding practices, or proactive monitoring, security must evolve alongside AI.

At RunSafe, we’re focused on one critical piece of that puzzle, protecting software from memory-based exploits before they can be weaponized. As AI continues to redefine how we write code, it’s our responsibility to redefine how we protect it.

Learn more about Protect, RunSafe’s code protection solution built to defend software at runtime against both known and unknown vulnerabilities long after the last patch is available.

The post AI Is Writing the Next Wave of Software Vulnerabilities — Are We “Vibe Coding” Our Way to a Cyber Crisis? appeared first on RunSafe Security.

Even with decades of hard-earned security wisdom and modern verification tools, embedded software encounters the same kinds of bugs. Why do these mistakes keep showing up in code written by seasoned engineers? How do you write software that’s both secure and shippable, especially when staring down a deadline?

To dig into these questions, we spoke with Rolland Dudemaine, Director of Field Engineering at TrustInSoft. Rolland has spent more than 25 years in the embedded software world, working on the design and development of safety-critical and security-sensitive systems. He’s a regular open-source and AUTOSAR contributor, and he’s seen the industry’s best practices evolve alongside the pitfalls that stubbornly refuse to disappear.

In this Q&A, Rolland offers a straight-from-the-trenches look at secure coding, from the easy-to-miss mistakes that cause the biggest headaches, to the right way to layer security tools, to what “memory safety” really means in practice. Whether you’re writing firmware every day or steering an organization’s embedded security strategy, you’ll find insights here you can put to work.

1. What are the most common coding mistakes that introduce vulnerabilities in embedded software and why do they persist despite decades of security guidance?

Rolland Dudemaine: ​​In general, the remaining coding mistakes relate to the corner cases of the software. These often lead to runtime errors that can cause crashes, or worse, silent data corruption that may be exploitable.

Among those that remain, off-by-one errors (leading to buffer overflow/underflow) and computation overflow/underflow are the most typical, because they are not necessarily easy to reach during functional testing. When using a programming language that requires manual memory allocation, use-after-free remains a very visible cause of trouble. MITRE does a good job of listing such issues.

One of the reasons why these issues remain is that it is not possible to functionally test for these corner cases: there is an almost infinite number of ways to corrupt data. Instead, using appropriate tools is the only way to detect these kinds of issues.

2. In your experience, what’s the most overlooked aspect of secure coding in embedded C/C++?

Rolland: For projects reusing code, projects always underestimate the cost of ownership of open-source libraries. It’s not that these libraries inherently have lower quality; instead, the specific use of such libraries within the project may not be the same as the original intended usage, and it happens often that projects reach buggy corner cases. If you use third-party code, you become responsible for it.

For project-specific software, processes often focus on form over function. While using coding rules is the best way to improve maintenance cost, and well-tested, consistent code is likely to have fewer bugs, this doesn’t mean such bugs are eliminated! It’s only risk reduction, without guarantee.

During testing and code audits, using appropriate tools to check for mistakes is important. This includes static analysis, coverage tools and sanitizers. TrustInSoft Analyzer is one such tool that covers all of this in one go, but using separate tools is already a start.

3. Static analysis, formal verification, fuzzing, runtime protections—there are lots of tools out there. How should teams think about layering these techniques to get the best coverage?

Rolland: Security is all about layering. Much like serious network security always advises applying multiple network encryption schemes, code security goes through examination of the code through different angles and levels of protection.

“Security is all about layering. … Code security goes through examination of the code through different angles and levels of protection.”

That said, good security (and safety!) planning tries to avoid failures, and also plans for swift reaction in case of error after deployment. Similarly, static analysis, formal verification, and fuzzing are great examples of tools to be used during development, while runtime protection is efficient to ensure that any remaining failures will still be caught and handled gracefully in the field. RunSafe’s runtime protection is a state-of-the-art example of such a scheme that will detect and report any failure observed in production.

4. When evaluating code quality and security, how do you balance “perfect” code with what’s practical in the context of tight deadlines and limited resources?

Rolland: Perfection doesn’t exist in this world. What remains is how close the project needs to approach perfection. From there, various decisions can be made to focus on the pain points and dire consequences of field failures. And the effort to avoid them will have to be adapted in consequence.

“Perfection doesn’t exist in this world. What remains is how close the project needs to approach perfection.”

A similar pattern is to make or buy: Do you reuse third-party code? Open-source code? Use free or commercial tools to work?

When you start to get serious about your job, it quickly becomes visible that a thorough, reviewed, and if possible exhaustive approach should be used. Again, this can range from simply following coding guidelines and using systematic and formal verification tools to conducting an independent vulnerability analysis.

A heavy but interesting worldwide reference is the Common Criteria specification. Unless one has an extremely critical asset (think nation-level top-secret) to protect, the list is too extreme to be reasonably applied as is. However, it is a fantastic description of the methods to develop and verify software: selecting the right level for your needs and challenge will always push things in the right direction.

5. Can you share an example (anonymized or general) of how rigorous software verification caught a potentially serious bug before it made it to production?

Rolland: Based on feedback from our customers, the most common “potentially serious bugs” are accesses to uninitialized variables, as well as off-by-one errors. Since they are caught ahead of production, the true damage they could have caused is hard to predict, but can range from a mere malfunction to a potentially devastating bypassable security gate. 

Another example that we/TrustInSoft recently advertised at the CYSAT Paris event is a series of bugs that we found in the NASA cFE (Control Flight Executive). That open-source piece has been used in many space devices in production (James Webb telescope, among others), yet we recently managed to find a few runtime errors that could be damaging, including access to uninitialized variables.

6. What role does memory safety play in modern embedded security, and how are you seeing teams address these risks differently today than five years ago?

Rolland: The adoption of systematic security audits, sanitizers, and other formal verification tools, such as TrustInSoft Analyzer, has helped raise the bar and limit the amount and types of bugs that pass through.

That said, everyone working on C or C++ language code has started to look at Rust and other “memory-safe” languages. We’re actually adding Rust support to TrustInSoft Analyzer and it will ship in our next release. 

However, early analyses on customer projects using Rust show that, in fact, runtime errors persist, at a lower but visible level. One of the reasons is that the definition of memory safety in Rust isn’t that there is no risk anymore; rather, if a failure is detected at runtime, the code may deterministically panic instead of doing something unpredictable. It’s much better, but it will not prevent a DoS (Denial-of-Service), for instance.

All in all, adopting a new language presents an opportunity to transition to more modern practices: code is rewritten with enhanced experience, improved design, refined coding practices, improved testing, and more precise specification. The new language itself isn’t the sole cause of improvement, but it’s a pretext for change for the better, and an opportunity to use efficient verification tools.

7. Software supply chain risks have become top-of-mind for embedded teams. How important is it to have visibility into all software components, and how do you view SBOMs within the embedded security picture?

Rolland: The European CRA (Cyber Resilience Act), the US Cyber Trust Mark, and the Chinese CSL (CyberSecurity Law) all mandate SBOM for a reason: it’s the minimum security hygiene to list what you are using and shipping. If you don’t even know what you’re shipping, how could you even start to evaluate the risks?

Once such a list is established, it becomes possible, mapped to the system and software architecture, to determine which are the risky items in terms of attack surface, and consequently identify where the verification effort should be focused.

SBOM does not make the system inherently secure: it allows projects to gauge risks. So, it definitely goes in the right direction, even when this just looks like paperwork at first.

8. Looking ahead, what trends or technologies do you think will reshape how we write secure embedded code over the next 3–5 years?

Rolland: It’s all too easy to answer AI to this question, as AI is seen as the answer to everything these days. However, AI in this specific case is a risk: humans using AI for coding are no longer the designer/logician/artist of the code, but merely reviewers. There is consequently a higher risk of subtle security implications when adopting AI-generated code; it becomes truly important, consequently, to use either formal verification tools to verify, more thorough human reviews, or both.

On a more positive note, the move to memory safe programming languages is opening the eyes of many developers and managers to the fact that good practices lead to much better code quality. We see more interest in formal verification tools, and TrustInSoft Analyzer is being trusted more than ever to verify critical code, regardless of the origin.

“Good practices lead to much better code quality.”

Building Resilient Embedded Software with the Right Tools and Partners

Securing embedded systems is an ongoing process that demands rigor, the right tools, and a willingness to adapt as threats evolve. As Rolland Dudemaine’s insights show, achieving meaningful improvements in software security requires both technical discipline and strategic planning, from catching elusive corner-case bugs to layering defenses that protect systems long after deployment.

If your team is looking to strengthen its approach to embedded security, RunSafe Security offers solutions designed to neutralize the entire class of memory safety vulnerabilities and protect against runtime exploits without disrupting your development workflow. 

Learn how our runtime code hardening eliminates memory corruption risks and see how we help organizations in critical industries ship safer, more resilient systems.

Explore RunSafe Protect.

The post Secure Coding Practices: A Q&A with Industry Expert Rolland Dudemaine appeared first on RunSafe Security.

This year, we’re proud to sponsor the Maritime Hacking Village (MHV), the destination at DEF CON for hackers, engineers, and tinkerers who want to get their hands on real maritime tech and explore the vulnerabilities lurking beneath the surface.

The 2025 theme, “Digital Blockade in the Pacific,” draws on real-world geopolitical flashpoints to frame a gamified hacking experience built around real maritime infrastructure.

“It’s definitely not RSA, and it’s not Black Hat,” said Duncan Woodbury, Executive Director of the Maritime Hacking Village, on RunSafe’s Exploited: The Cyber Truth podcast. “There are no sponsored talks. What we do at villages is bring people together to perform security research against real-world critical infrastructure systems.”

This year’s setup includes:

• 🚤 Two unmanned surface vessels (USVs)—autonomous watercraft adapted for live RF and telemetry hacking
• 🏗️ A working crane control system—donated by one of the largest ports in the Western Hemisphere, complete with a real 8×8-foot shipping container you can “unlock” via successful exploit
• 🛰️ GPS & AIS spoofing scenarios—showcasing how easy it is to manipulate unencrypted maritime systems
• 🎯 Gamified CTF-style challenges—all wrapped in a storyline simulating a digital blockade in a contested region

“We prioritize real systems and avoid simulations,” said Woodbury. “We can produce powerful results in just 20 hours of conference time.”

“That’s why we’re excited to be part of this,” said Joe Saunders, CEO and Founder of RunSafe Security. “DEF CON is where real vulnerability research happens. The Maritime Hacking Village puts legacy systems and cutting-edge autonomous vessels in front of the best hackers in the world—and we get better for it.”

Why RunSafe Is at the Maritime Hacking Village

RunSafe is no stranger to high-consequence embedded environments. From defense to critical infrastructure to automotive, we work with teams building software that must keep running.

“Maritime infrastructure is what we call the last dinosaur,” said Woodbury. Many systems are decades old and are just now beginning to adopt digital tech and automation.

RunSafe’s core technology—RunSafe Protect—defends embedded software by neutralizing memory safety vulnerabilities at runtime, preventing exploit chains without requiring developers to rewrite code. It’s the kind of defense that matters when you’re out on the ocean, or in a factory, or controlling a satellite.

“That’s why we’re excited to be part of this,” said Joe Saunders, CEO and Founder of RunSafe Security. “DEF CON is where real vulnerability research happens. The Maritime Hacking Village puts legacy systems and cutting-edge autonomous vessels in front of the best hackers in the world—and we get better for it.”

See You in the Village

DEF CON is where the boundaries of cybersecurity get stress-tested. We’re excited to be part of a community pushing those limits not just in theory but in practice.

If you’re curious about embedded systems, maritime autonomy, or how to defend devices that can’t afford to fail, make sure the Maritime Hacking Village is on your map.

“Hiding vulns sink all ships,” said Saunders. “If you don’t probe your own systems, motivated actors will. By engaging with communities like DEF CON, you’ll benefit from the discoveries, and you’ll be better off in the long run.”

📍 DEF CON 33 | Maritime Hacking Village
🗓 August 8–11, 2025
📌 Caesars Forum, Las Vegas

Catch all the updates from the Maritime Hacking Village: https://www.linkedin.com/company/maritimehackingvillage/
Learn more about RunSafe Security: https://runsafesecurity.com

Want to connect ahead of the event? Drop us a line or flag us down in the village. We’ll be the ones near the watercraft.

The post RunSafe Security Joins the Maritime Hacking Village at DEF CON 33 appeared first on RunSafe Security.

Our goal at RunSafe is to give defenders a leg up against attackers, so we wondered: What if we could quantify this seemingly unquantifiable risk? What if we could take meaningful action to implement zero-day protection for systems before vulnerabilities are even discovered?

To dig into these questions, we partnered with Ulf Kargén, Assistant Professor at Linköping University, who developed the CReASE (Code Reuse Attack Surface Estimation) tool, which underpins RunSafe’s Risk Reduction Analysis.

Quantifying the Unquantifiable: A New Approach to Zero-Day Risk

VulnCheck, in their “2024 Trends in Vulnerability Exploitation” report, found that 23.6% of all actively exploited vulnerabilities in 2024 were zero-day flaws. We’re seeing nation-state actors like Volt Typhoon and Salt Typhoon specifically target these unknown vulnerabilities to achieve their objectives, as noted in research from Google Threat Intelligence Group, which tracked 75 zero-day vulnerabilities exploited in the wild in 2024.

Most of the industry’s response to zero days has been trying to detect and prevent threats by looking for indicators of attack, suspicious behavior, and patterns that might tip us off. But attackers have gotten really good at hiding and masking their activity. What’s been left wide open is the underlying risks in software itself. Instead of securing the foundation, we’ve built bigger walls around our systems.

That might work in a data center where systems live behind firewalls and racks of gear. But in the world of IoT and embedded devices, there are no walls. These systems are deployed far from the protection of the network where they are alone, exposed, and vulnerable. They need to be self-reliant. They need to be like samurai—able to defend themselves without backup.

Because of this, we saw the need for a method to quantify the risk of zero days and a way to make devices intrinsically more robust against exploitation, regardless of what vulnerabilities might exist within them. If you can quantify risk with real technical rigor, you can make smart decisions to reduce your attack surface and make a compelling argument to leadership on where to focus resources.

Return-Oriented Programming: Understanding the Threat

Modern cyberattacks frequently use a technique called Return-Oriented Programming (ROP). When traditional code injection attacks became difficult due to improved security measures, attackers evolved to use “code reuse” attacks instead.

Modern exploits repurpose a program’s own code, using existing code snippets (called “gadgets”) within a program and chaining them together to create malicious functionality. The program’s own code is weaponized against itself.

This insight gives us a way to measure memory-based zero-day risk specifically. While it’s impossible to predict all potential vulnerabilities in code, we can analyze whether useful ROP chains exist in a binary that could lead to the successful exploitation of a vulnerability.

Quantifying Zero-Day Risk with CReASE

We worked alongside researcher Ulf Kargén at Linköping University who developed the Code Reuse Attack Surface Estimation (CReASE) tool to quantify previously unmeasurable risk. You can listen to Ulf discuss the tool and how it works in this webinar.

CReASE scans binaries to identify potential ROP gadgets and determines whether they could be chained together to perform dangerous system calls. It doesn’t try to predict where specific vulnerabilities might exist but instead analyzes whether the code structure would allow successful exploitation if a vulnerability were discovered.

It answers the question: Are any useful ROP chains available to an attacker?

Unlike existing tools that focus on guaranteeing working exploit chains (often sacrificing scalability or completeness), CReASE uses novel data flow analysis to achieve both scalability and completeness comparable to a human attacker.

The result is a risk scoring system that quantifies the probability that the next memory-based zero-day vulnerability could be exploited to achieve specific dangerous outcomes like remote code execution, file system manipulation, or privilege escalation.

The CReASE tool underlies RunSafe’s Risk Reduction Analysis, which you can use to analyze your exposure to CVEs and memory-based zero days.

The Memory Safety Challenge

To understand why this approach is so powerful, we need to recognize two critical facts:

1. 70% of vulnerabilities in compiled code are memory safety vulnerabilities
2. 75% of vulnerabilities used in zero-day exploits are also memory safety vulnerabilities

These numbers tell us that memory safety vulnerabilities constitute a significant risk in our codebases. When a memory vulnerability is exploited, attackers can execute arbitrary code, take control of devices, crash systems, exfiltrate data, or deploy ransomware.

By focusing our risk quantification and mitigation efforts on memory-based vulnerabilities specifically, we’re addressing a common and dangerous attack vector for zero-day exploits.

Memory Randomization: Making Zero-Day Vulnerabilities Inert

Once we quantify the risk, what can be done about it? Traditional memory protection like Address Space Layout Randomization (ASLR) provides some security by randomizing where blocks of code are loaded in memory. However, ASLR still loads functions contiguously, making it vulnerable to information leak attacks.

RunSafe’s approach takes randomization to the function level. Instead of randomizing where the entire binary loads, we randomize each function independently. In a typical binary with 280 functions, this creates 280 factorial possible memory layouts — more than 10^400 combinations.

Even if a memory-based zero-day vulnerability exists, with RunSafe’s Load-time Function Randomization (LFR), attackers can’t reliably construct a working ROP chain because they can’t predict where the necessary gadgets will be located. We’ve effectively made the vulnerability inert.

Taking Action: Zero-Day Vulnerability Protection

The most effective approach to memory-based zero-day risk combines analysis and protection:

1. Analyze your binaries to understand your current risk profile
2. Apply function-level randomization to neutralize potential exploits
3. Measure the risk reduction to quantify your improved security posture

Our customers typically see a risk reduction that changes the odds from “the next zero-day can compromise the system” to “maybe one in the next 10,000 zero-days might succeed.” That’s a dramatic improvement in security posture.

While no solution can eliminate all types of zero-day vulnerabilities, addressing memory-based vulnerabilities targets the most common and dangerous attack vector. In a world where zero-days will always exist, making them ineffective is the next best thing to eliminating them entirely.

Want to try out the Risk Reduction Analysis tool for yourself? All you’ll need to do is create an account and upload a binary to get your results.

Run an analysis here.

The post Reducing Your Exposure to the Next Zero Day: A New Path Forward 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.

That doesn’t mean you shouldn’t patch, but you should seek out options to protect devices and embedded systems even before a patch is available. For example, runtime protections are a welcome addition to your ICS/OT patch management strategy, particularly with threat actors like Volt Typhoon targeting critical infrastructure.

The Challenges of ICS/OT Patch Management

Patching vulnerabilities in critical systems involves far more complexity than issuing updates for standard IT environments. The stakes are higher, and the constraints are substantial, particularly in OT environments. 

Why Is Traditional Patching So Challenging?

1. Downtime Is Expensive and Risky
Critical infrastructure systems in industries like energy, industrial automation, and manufacturing simply cannot afford prolonged downtime. Stopping operations, even briefly, to patch a system could disrupt essential services and impact public safety. 

2. Managing Legacy Systems and Compatibility Issues
Many critical infrastructure systems are built on aging or bespoke software that may not support new patches. Applying updates could introduce unintended errors or reduce system functionality.

3. Addressing Lengthy Patch Cycles
For complex OT systems, patch development, testing, and deployment can take months. This leaves systems exposed to vulnerabilities for extended periods and makes them highly attractive targets for attacks.

Why ICS/OT Systems Need More Than Patches

While patching remains an industry-standard practice, patch-only strategies leave businesses at significant risk. Three key shortcomings make traditional patching insufficient for critical infrastructure systems:

1. Delayed Vulnerability Resolution
Even when patches are eventually issued, adversaries exploit the lag between vulnerability discovery and patch deployment. This leaves OT systems particularly vulnerable to attacks, as demonstrated by global ransomware campaigns and nation-state actors that have targeted unpatched critical infrastructure.

2. Incomplete Coverage
While patching resolves known vulnerabilities, it does not protect against future attacks or zero days in software.

3. Excessive Resource Burden
Security teams spend countless hours addressing vulnerabilities rather than focusing on proactive strategies. This creates fatigue among teams and diverts resources from long-term improvements. 

An Alternative Strategy for Mitigating Vulnerabilities

Given these challenges, organizations can benefit from proactive solutions that complement patching to provide stronger defenses against vulnerabilities, even before a patch is available.

One solution is runtime exploit prevention, which defends devices by mitigating vulnerabilities at runtime rather than relying on patches. Runtime exploit prevention is specifically effective against various high-risk vulnerabilities, including:

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

A single unpatched vulnerability in SCADA or HMI systems could allow attackers to compromise an entire facility, leading to catastrophic outcomes.  With runtime protections applied, many of these exploits can be prevented, significantly reducing risk to critical systems.

Case Studies: Successful Alternatives to Patching

Defending HMIs: HMI products are the most commonly attacked OT network devices, use a variety of operating systems, and are often in very difficult to update facilities within critical infrastructure. One industrial automation leader deployed runtime protection to HMI products built on embedded Linux, significantly reducing the attack surface without altering product functionality. Additionally, with runtime protections applied, the organization now has protection against memory-based zero days, which means devices are protected even before a patch is available and applied. 

Embedded Systems Protection: In another example, Vertiv, a leading global provider of digital infrastructure and continuity solutions, integrated RunSafe Security’s runtime protection software as a layer into their Yocto builds to enable self-protection against memory-based attacks. RunSafe’s integration into Vertiv’s GitLab environment automated the identification and mitigation of vulnerabilities, centralizing vulnerability management and protection devices against zero days.

Future-Proofing Critical Infrastructure Security

Securing software and devices deployed across critical infrastructure is a multifaceted challenge, especially as attackers become more sophisticated. While patching remains essential, modern infrastructure operators cannot rely on it as their sole defense strategy. 

Complementary solutions, like runtime protections, empower security teams to transition from a reactive stance to proactive, strategic defense planning. 

Want to minimize your patching cycles and defend your systems against memory-based vulnerabilities? Explore how RunSafe Protect can strengthen your patch management strategy and safeguard your devices.

The post Alternatives to Patching for ICS/OT Software and Devices 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.

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.

But as development speeds increase, securing software at the same pace becomes a challenge. Security often becomes a bottleneck in the delivery pipeline, introducing delays that prevent new technology from making it quickly into the field. Adversaries, however, don’t wait.

This is where Runtime Application Self Protection (RASP) enters the picture. RASP is a powerful addition to existing CI/CD pipelines, offering protections from build time to runtime to increase the cyber resiliency of military systems without sacrificing speed.

Applying RASP in the DoD Software Factory

Imagine trying to infiltrate a building where not just the entrances but the entire floor plan completely changes every time you enter — that’s what attackers face when targeting applications protected by RASP.

RASP is a security technology that operates within software applications to detect and block attacks while an application is running. Unlike Address Space Layout Randomization (ASLR), which has been a standard security feature for years, Load-time Function Randomization (LFR) — a form of RASP — provides advanced runtime protection by randomizing individual functions within a program to create a unique memory layout every time the software loads.

Like in our building analogy, RASP reshuffles the rooms so attackers cannot find a successful path to attack. With RASP,  a device or system already deployed in the field can defend against attacks like malware, code injection, backdoors, zero-days, and memory-based vulnerabilities.

Within the context of a software factory, implementing RASP allows for the prevention of exploits at runtime, significantly reducing the severity and risks of unpatched vulnerabilities. When integrated into the CI/CD pipeline, RASP provides continuous protection, whether the software is in development, testing, or deployed in the field, making it possible to confidently ship software faster.

How RASP Complements Source Code Analysis in the Software Factory

While source code analysis tools excel at identifying known vulnerabilities during development, they can’t catch everything. This is where RASP provides crucial complementary protection. RASP operates as an active guardian, preventing exploitation in the field even if the vulnerability wasn’t caught during static analysis.

Runtime protection is particularly valuable for embedded military applications written in C/C++. Memory safety vulnerabilities represent up to 70% of exploitable vulnerabilities in embedded software. In 2022, the National Security Agency (NSA) issued guidance emphasizing the severity of memory safety vulnerabilities, stating that they remain the most readily exploitable category of software flaws. Additionally, MITRE’s Common Weakness Enumeration (CWE) consistently ranks memory corruption vulnerabilities among the top 25 most dangerous software weaknesses.

RASP, by randomizing memory layouts, prevents attackers from exploiting memory safety vulnerabilities. By doing so, RASP protects assets in the field by taking high-severity memory-based vulnerabilities and reducing the risk to not exploitable, eliminating the memory safety threat without requiring massive code changes or impacting performance.

Combining static analysis with RASP strengthens the software factory, addressing issues early on in the development process while also having a layer of defense at runtime that actively protects against both known vulnerabilities and zero days targeting memory-based vulnerabilities.

Real-World Implementations: RASP in Action

RunSafe Security’s Identify and Protect solutions have been deployed with success across multiple DoD programs. Software teams are using RunSafe’s automated runtime exploit prevention solution to improve the cyber resiliency of weapon systems. 

• RunSafe Identify: Generate an SBOM and identify vulnerabilities
• RunSafe Protect: Deploy RASP to prevent the exploitation of memory-based vulnerabilities in C/C++ code

What makes RunSafe’s approach particularly valuable in defense contexts is its operational flexibility:

• Operates entirely on-premises
• Requires no network connectivity
• Seamlessly integrates with existing CI/CD workflows
• Maintains compatibility with DoD cloud environments
• Adds minimal performance overhead (just 1%)
• Provides an alternative to rewriting C/C++ code, saving time and costs

Perhaps most importantly, RunSafe’s implementation doesn’t overcomplicate the DevSecOps process. Once set up, it requires minimal maintenance while providing continuous protection

Looking Forward: The Strategic Advantage

For defense organizations leaning into the software factory concept to modernize their DevSecOps practices, RASP represents a strategic opportunity. RASP offers immediate protection while maintaining development velocity. It’s a force multiplier that enhances existing security tools while supporting the mission-critical need for rapid software delivery.

The post Is Your Software Factory Missing RASP? appeared first on RunSafe Security.

The Urgency of Space Security

Space assets, from satellites to ground stations, are integral to defense and civilian operations. With the global space economy projected to exceed a trillion dollars by 2030, the risk of cyberattacks becomes a pressing concern. Events like Russia’s cyberattack on Viasat during the Ukraine war demonstrate how adversaries can target satellites to erode confidence and disrupt infrastructure.

However, space infrastructure remains vulnerable due to limited cybersecurity regulations and the logistical challenges inherent in space operations. Protecting these assets from emerging space threats is essential to maintain national security, economic stability, and the continuity of essential services worldwide.

The primary cyber threats to space assets include attacks on ground stations and on-orbit systems. Ground stations are more accessible targets, but satellite attacks can have far-reaching implications, disrupting military and civilian networks. Threat actors exploit weaknesses in both software and hardware, with ransomware and platform-level compromises posing significant risks.

Satellite Command & Control Systems, spacecraft navigation systems, remote sensing and telemetry systems, and more are all examples of critical systems that could be targeted in an attack.

1. Attacks on Ground Stations: Ground stations represent a vulnerable entry point for adversaries. A recent example is Russia’s pre-invasion cyberattack on Viasat, which disrupted Ukrainian communication systems. Breaking satellite-ground communication links can lead to loss of satellite control, interruptions to data transmission, and navigation errors.
2. Orbital Interference: Adversaries have demonstrated the ability to threaten satellites in orbit. Recently, concerns have been raised with Russia’s Luch/Olymp satellites, which exhibit unusual movement patterns that raise the  potential for monitoring or interference with other satellites’ operations and the potential for direct orbital attacks.
3. Compromise of the Supply Chain: The increasingly globalized and commoditized nature of the space supply chain introduces new vulnerabilities. Malicious actors can target the development environments, manufacturing processes, or the software supply chain to infiltrate space systems through compromised hardware or software. Even subtle changes in manufacturing code could compromise the integrity of critical components, with the potential for catastrophic failures.
4. Malware: Attackers can upload malware to satellite terminals, giving them control over devices or disrupting communications.
5. Source Code-Level Attacks: Sophisticated cyber threats like the SolarWinds attack demonstrate the risk of attacks at the source code and platform level, potentially compromising the trust and integrity of space systems.

To counter these threats, the security community must prioritize trusted, secure communication channels and reliable updates for satellite functions. Ensuring trust in AI-driven processes and machine-learning functions is another growing challenge as these technologies become central to satellite operations.

Unique Challenges to Security in Space

Unlike terrestrial systems, space assets face constraints that complicate security implementations. Solutions must avoid adding excess power consumption, weight, or cost to satellites while still providing robust protection.

Additionally, it’s very difficult to update space systems once they are launched. Security needs to be done right from the get-go. Once an asset is in space, it’s a foregone conclusion. Because of this, it’s imperative to consider implementing runtime protection to defend space assets even after they are operating in orbit.

RunSafe’s Advantage in Space Cybersecurity

RunSafe Security’s technology offers an innovative solution by providing software hardening for satellite systems without additional hardware requirements. This approach maintains operational efficiency, making it highly suitable for space applications. By focusing on software resilience, RunSafe extends the operational life of satellites, a critical advantage when assets in orbit lifespan should be extended to boost the return-on-investment.

RunSafe’s solutions bring unique operational benefits to space systems:

• Hardware-Free Security: RunSafe’s software-based approach enables satellite resilience without additional hardware, making it a cost-effective option that aligns with the operational constraints of space.
• Support of Open Source Software: RunSafe protects open source software deployed as docker images or containers that allow for the swapping and repurposing of satellite software, minimizing the risk of cyber incidents while enhancing mission flexibility. This adaptability is crucial in a landscape where customized solutions tied to hardware often incur prohibitive costs and lack ability to repurpose to meet new missions.

These capabilities make RunSafe an ideal partner for entities focused on extending the lifespan and robustness of space assets without compromising weight, power, or cost.

Public-Private Collaboration in Space Security

As government and commercial entities increasingly share responsibility for space infrastructure, a closer public-private partnership is necessary to ensure cohesive cybersecurity measures. The Space ISAC, a bridge between industry and government, plays a vital role in this collaboration. The Space ISAC helps coordinate responses to threats like orbital anomalies or cyberattacks through threat intelligence sharing and real-time monitoring.

However, collaboration must extend beyond monitoring. Industry standards, developed through cooperation between agencies and private companies, are critical to building a secure framework for space operations. Trusted information-sharing platforms like the Space ISAC’s Watch Center exemplify the proactive approach needed to protect our space infrastructure.

Moving Toward Effective Regulations and Standards

Current space policy directives encourage, but do not mandate, cybersecurity for space assets. This gap in enforceable regulations leaves many companies needing clear guidance, risking vulnerabilities that adversaries could exploit. Evolving best practices offer a flexible path forward, enabling companies to adopt measures tailored to their specific needs without the rigidity of static regulations.

Meanwhile, organizations like IEEE are working toward defining baseline standards for space cybersecurity, ensuring that space infrastructure can withstand the evolving cyber landscape.

As space becomes recognized as a critical infrastructure domain, protecting it from cyber threats is imperative. RunSafe’s innovative approach, focusing on adaptable, hardware-free security, offers a path forward that addresses the unique constraints of space operations. However, effective protection requires more than technology; it demands collaboration across public and private sectors, unified standards, and a proactive stance on cybersecurity.

Through partnerships with organizations like the Space ISAC and forward-looking policies, we can ensure that space assets remain secure, resilient, and capable of supporting global stability in the decades to come. In the race to secure space, now is the time to act.

For those in the industry, cybersecurity, or policy-making, the time to prioritize space security is now. Join us in advancing solutions that protect our orbital assets and ensure a safer, more resilient future in space.

The post Securing Space as the Next Frontier of Critical Infrastructure appeared first on RunSafe Security.

For a deeper discussion on Volt Typhoon’s tactics and the national security stakes, listen to our RunSafe Security Podcast episode featuring experts unpacking the threat to critical infrastructure.

Unlike with ransomware attacks, Volt Typhoon’s aims are focused on the long-term, not the short-term. Ransomware culprits want quick transactions with only enough disruption to their targets as required to extract payments. Nation-state aligned cyber offense, however, has a two-fold purpose: (1) blunt military capabilities and (2) create disruption and overall panic in society. 

These actors take a long-term perspective, preparing in advance to be able to achieve both goals when a conflict arises. In the case of the PRC-backed Volt Typhoon, that conflict could be the PRC’s attack on Taiwan. If Volt Typhoon is effective in meeting its goals, it could impact the response of the United States, potentially deterring the US from engaging in the conflict. We are in an age of cyber as a means to achieve geopolitical goals.

What Is the Cyber Kill Chain? How Nation-State Actors Prepare for Attack

The Kill Chain construct originates in kinetic warfare. For example, in 1990, General John Jumper coined a kill chain for airborne targets: F2T2EA (find, fix, track, target, engage, assess). It is expected to be completed as rapidly as possible. Cyber kill chains, on the other hand, can occur over a much longer period of time.

In the cyber kill chain coined by Lockheed Martin, Reconnaissance is the first phase before Weaponization. The Reconnaissance phase can be prolonged; it is also referred to as the preparation of the battlefield stage. The attacker is in the system, searching for weaknesses, and in some cases living off the land. 

Volt Typhoon is in the Reconnaissance stage within critical infrastructure, preparing to move to the next stages of the kill chain if geopolitical circumstances warrant.

What Does a Volt Typhoon Cyber Kill Chain Look Like?

The Department of Homeland Security’s Cybersecurity and Infrastructure Security Agency (CISA) has published detailed descriptions of the typical pattern of attack involving Volt Typhoon. Drawing from a February 2024 CISA notice, a Volt Typhoon cyber kill chain typically involves:

1. Extensive pre-compromise reconnaissance

Surveillance starts by profiling network traffic into and out of a target organization. The goal is to identify:

• Hardware at the edge: By identifying hardware at the edge and the OS versions on the hardware, the attacker can plan the cyber weapons they need for the next stage of the attack. The makes, models, and configurations of routers and other edge devices can often be determined by careful observation of in-bound and out-bound traffic.
• Communications protocols: Communications protocols provide insight into the make, models, and configurations of other devices, further inside a target network.

2. Exploitation of edge devices using known or zero-day vulnerabilities

Compromising the edge devices of a target network is important, because often those edge devices are configured to provide alerts when indicators of compromise occur. By compromising the edge devices themselves (routers, etc), the attacker can “blind” the sensor network. Exploitation will target the operating systems and applications on the edge devices. Once edge devices have been compromised, those devices themselves become part of the surveillance network, but with a privileged view of behavior “inside the network.”  Volt Typhoon has used a wide variety of exploitation techniques:

• Memory safety exploitation: In one confirmed compromise, Volt Typhoon actors likely obtained initial access by exploiting CVE-2022-42475 in a network perimeter FortiGate 300D firewall that was not patched. There is evidence of a buffer overflow attack identified within the Secure Sockets Layer (SSL)-VPN crash logs.
• Web-based exploitation: Some edge devices have poorly configured management interfaces, which can expose administrative functions to the Internet.

3. Obtaining administrative credentials using privilege escalation vulnerability

Using the privileged position on edge devices, the attacker tries to determine administrative credentials so that further access to devices will no longer require the exploitation from step 2 above. Utilizing credentials also means that the attacker can maintain persistence on a device, even if the exploitation vector from step 2 is patched.

4. Moving laterally to the domain controller, using the stolen credentials 

Compromising the domain controller is a key objective, because it means that all further accesses will have the patina of legitimacy. Identifying fraudulent logins from legitimate user names and passwords requires sophisticated tools that most organizations don’t use.

5. Discovery on victim network, using Living-off-the-Land (LOTL) techniques

With “domain controller” access, the attacker now moves into the stage of executing their mission on target, which might be:

• Exfiltrate data: Often the objective of an attacker is to to steal sensitive data (e.g. medical records, financial information, corporate intellectual property, government classified information). The attacker will be able to patiently find where that sensitive data is located and craft a plan for low-probability of detection exfiltration of that data.
• Inject tools for direct action: This could mean placing assets for ransomware attacks or disruption of system services. Extensive documentation has highlighted the PRC’s commitment to disrupting US critical infrastructure in the event that China attempts to retake Taiwan.

What Can Be Done Today to Prevent Volt Typhoon’s Future Success? Addressing Memory Safety

The attack scenario above highlights that a memory safety vulnerability is part of the Volt Typhoon cyber kill chain. It’s a reasonable approach as: (1) a number of the most dangerous CWEs per MITRE relate to memory safety (6 of the top 25); (2) 70% of Google and Microsoft security patches relate to memory safety as referenced in NSA’s advisory about memory safety; and (3) in VxWorks Urgent/11, 6 of the 11 vulnerabilities related to memory safety.

It is reasonable to hypothesize that Volt Typhoon cyber kill chains also target OT/ICS devices, which are attractive as both edge devices (step 2 above) and as controllers of critical infrastructure. Capture of these devices enables Volt Typhoon to directly disrupt critical infrastructure by sending malicious commands and/or erroneous data to these devices. Additionally, these OT/ICS devices are often good pathways into the IT infrastructure.

In the case of an attack on Taiwan, Volt Typhoon could deter the US from taking action by exploiting a memory-based vulnerability, for example, to disrupt a major power grid.

Approaches do exist for memory safety now, including the hardening of software in OT/ICS devices to withstand attacks against both known and unknown memory-based vulnerabilities. Unlike static defenses that can be easily bypassed, techniques like moving target defense randomize at a granular level the memory layout of software binaries. By constantly shifting the software landscape, attackers are unable to predictably exploit memory vulnerabilities.

For example, RunSafe Security’s Protect solution mitigates cyber exploits by dynamically relocating software functions in memory every time the software is loaded. By ensuring that the memory layout changes every time software is loaded, RunSafe effectively thwarts repeated attack attempts and prevents bad actors, like Volt Typhoon, from compromising critical infrastructure. 

Call to Action for Critical Infrastructure Owners

As outlined, there is time to foil Volt Typhoon’s Exploit stage and their ultimate goal of impacting the United States response if a conflict arises. Only critical infrastructure owners can close the gap—by demanding Secure by Design systems and insisting on runtime protection against memory-based exploits.

Unlike CISA, which provides guidance and recommendations, critical infrastructure owners purchase and update ICS/OT devices installed in their plants, grids, and factories. It falls in their hands to require, demand, and pound the table for ICS/OT device manufacturers, who are their vendors, to increase the cyber resilience of embedded devices. These devices must have the ability to operate through attacks in real-time without the need for human, centralized monitoring and response. 

By demanding memory safety and other defense measures from their ICS/OT device vendors now, critical infrastructure owners can prevent the success of Volt Typhoon in the future.

Want to hear from RunSafe leaders on how to approach this challenge? Tune in to the RunSafe Security Podcast episode on Volt Typhoon to explore real-world implications and actionable strategies.

Learn more about RunSafe Security’s Protect solution in our technical deep dive.

The post Don’t Let Volt Typhoon Win: Preventing Attacks During a Future Conflict appeared first on RunSafe Security.

Introduction

The Unique Challenges Facing DoD Systems

RunSafe’s Approach to Cyber Resilience for DoD Systems

Integrating RunSafe into DoD Systems

The Future of Cyber Resilience for DoD

How RunSafe Ensures Mission Success in the DoD’s Cyber Landscape

Introduction

As cyber threats to mission-critical systems grow increasingly sophisticated, the Department of Defense (DoD) faces unprecedented challenges in protecting its vast and complex infrastructure. The stakes could not be higher—national security, military operations, and the safety of personnel depend on the integrity and reliability of these systems. In this high-stakes environment, cyber resilience is an absolute necessity.

RunSafe understands the urgency of this mission. Our solutions are designed to provide robust security measures that go beyond traditional defenses. By protecting software and securing systems, we ensure that memory safety vulnerabilities are addressed before they can be exploited in accordance with the NSA advisory of November 2022. This proactive approach is critical in safeguarding the DoD’s operations, ensuring mission-critical systems remain secure, functional, and resilient even in the face of sophisticated cyber attacks.

In this blog post, we delve into how RunSafe Security supports the DoD’s cyber resilience efforts. From advanced protection techniques to seamless integration with existing systems, discover how our innovative solutions are helping to secure the future of defense operations.

The Unique Challenges Facing DoD Systems

The DoD operates in one of the most challenging cyber environments, facing constant threats from nation-state actors, advanced persistent threats (APTs), and sophisticated cyber attacks. These adversaries possess the resources and expertise to launch highly targeted and complex operations, aiming to compromise DoD systems and disrupt mission-critical operations. The stakes are immense, with potential consequences ranging from compromised military operations and data breaches to severe national security risks.

Cyber attacks on DoD systems can lead to operational paralysis, loss of sensitive information, and endanger the lives of military personnel. The disruption of communication networks, manipulation of command and control systems, and unauthorized access to data are examples of how devastating such attacks can be. In this high-threat environment, the DoD cannot afford to rely on EnterpiseIT-centric cybersecurity measures alone.

To counter these sophisticated threats, the DoD requires a defense-in-depth cyber resilience strategy for its unique mission requirements. This strategy must encompass proactive defense mechanisms and automated response capabilities. RunSafe Security is at the forefront of delivering such solutions, providing advanced software protection techniques that can fortify DoD systems against a wide array of cyber exploits. By integrating these innovative measures, we help ensure that the DoD’s operations remain secure, resilient, and mission-ready in the face of evolving cyber adversaries.

RunSafe’s Approach to Cyber Resilience for DoD Systems

RunSafe takes a proactive approach to cyber resilience, designed to meet the rigorous demands of DoD systems. Our focus on proactive protection, mission assurance, and seamless integration ensures that the DoD maintains operational integrity and security against the most advanced cyber threats. By addressing vulnerabilities before they can be exploited, we provide a robust defense that keeps mission-critical systems secure and resilient.

Key features of RunSafe’s solutions include automated software protection techniques for both legacy and new weapon systems. This ensures comprehensive coverage across the DoD’s diverse technological landscape. Additionally, automated response and recovery mechanisms guarantee mission continuity, swiftly restoring normal operations in the event of an attack.

RunSafe’s solutions are designed for compatibility with the DoD’s software development and deployment processes, including DevSecOps and CI/CD pipelines. This seamless integration enables rapid deployment and ongoing protection without disrupting existing workflows. By embedding security into the development lifecycle, we are helping the DoD stay ahead of evolving cyber threats.

Integrating RunSafe into DoD Systems

Integrating RunSafe Security’s solutions into various DoD systems is a seamless and highly effective process, enhancing the cyber resilience of weapons systems, data centers, and critical infrastructure. Our solutions are designed to integrate smoothly with existing workflows, ensuring minimal disruption to operations while maximizing security.

The integration process is streamlined to fit naturally into the DoD’s software development and deployment environments. By working closely with development teams, we ensure that our advanced software hardening techniques and real-time vulnerability detection capabilities are embedded within DevSecOps pipelines and CI/CD workflows. This approach ensures that security is a fundamental part of the development lifecycle, from initial coding to final deployment.

For example, RunSafe’s techniques have protected legacy code in weapons systems against memory safety vulnerabilities, significantly reducing the risk of cyber attacks. Critical DoD infrastructure systems benefit from our automated response mechanisms, which ensure rapid recovery and maintain operational continuity in the face of cyber incidents.

RunSafe’s successful integrations demonstrate our commitment to enhancing mission success through superior cyber resilience. By embedding robust security measures into every aspect of the DoD’s technological framework, we are proud to protect the nation’s most vital systems against evolving cyber threats.

The Future of Cyber Resilience for DoD

At RunSafe Security, our vision for the future of cyber resilience within the DoD is grounded in continuous innovation and unwavering support for mission-critical systems. We are dedicated to staying at the forefront of cybersecurity advancements, constantly evolving our solutions to counter emerging threats targeting DoD systems. By investing in research and development, we ensure that our technologies not only meet but exceed the stringent requirements of the DoD’s complex operational environment.

Our commitment extends beyond technological innovation to encompass comprehensive support for the DoD’s mission success. We understand the pivotal role that secure and resilient systems play in national defense and military operations. That’s why RunSafe is dedicated to providing solutions that integrate seamlessly into the DoD’s infrastructure, enhancing cybersecurity posture without disrupting critical missions.

RunSafe is committed to helping safeguard DoD systems against evolving cyber threats, empowering our nation’s defenders with the tools they need to protect our freedom and security.

We invite readers to explore RunSafe’s solutions by downloading “3 Ways to Achieve DOD Cyber Resilience.” Discover how our innovative approach can strengthen your defense systems against cyber threats.

The post How RunSafe Ensures Mission Success in the DoD’s Cyber Landscape appeared first on RunSafe Security.

Introduction

The Hidden Costs of Rewriting Code

The Memory Safety Crisis: A Growing Concern

Innovative Approaches to Memory Safety

Addressing Memory Safety: A Comprehensive Approach

The Real Cost of Rewriting Code for Memory Safety – Is There a Better Way?

Introduction

Memory safety vulnerabilities are a persistent and pervasive issue in the software development world, leading to some of the most severe and costly security breaches. From buffer overflows to dangling pointers, these vulnerabilities are a common attack vector, exploited by malicious actors to gain unauthorized access, cause data corruption, or crash systems. Traditionally, the go-to solution has been to rewrite the affected codebase to ensure memory safety, which is not feasible. However, this approach is fraught with challenges, including substantial time investment, high costs, and the inherent complexity of reworking existing systems without introducing new bugs.

Rewriting code for memory safety is akin to renovating an old house; it’s labor-intensive, expensive, and often reveals unforeseen problems that further complicate the project. For developers and IT security professionals, the idea of re-engineering vast amounts of legacy code for hundreds of different types of products and often millions of fielded devices is daunting, often leading to project delays and increased pressure on already stretched resources. The technology leaders and system architects face the additional burden of justifying these costs and disruptions to stakeholders.

But what if there were a better way? 

Advances in technology now offer innovative solutions that enhance memory safety without the need for extensive code rewrites. These cutting-edge approaches mitigate risks while saving time and resources, enabling product manufacturers to secure their systems more efficiently and effectively. Read on to discover these groundbreaking methods and explore how they can transform the landscape of software security.

The Hidden Costs of Rewriting Code

Rewriting code for memory safety is usually a monumental endeavor that consumes significant time and resources. For software developers and engineers, the process involves learning new programming languages, testing open source components that may not be compatible, hiring new developers with different skills, testing all over again, and then getting your customers to buy new versions of the device they just purchased. This meticulous task demands a high level of expertise and substantial man-hours, diverting valuable resources from other critical projects.

Moreover, the process of rewriting code can inadvertently introduce new bugs and vulnerabilities. As developers modify and restructure the code, there is always the risk of human error, leading to new security flaws that could be even more challenging to detect and rectify. This not only undermines the initial objective of enhancing security, but can also add additional rounds of testing and debugging, further stretching timelines and budgets.

The disruption caused by rewriting code extends beyond the development team. Existing workflows are interrupted, scarce resources that could be focused on new features are deployed to redoing existing features, leading to delays in project timelines and deviations from carefully planned product roadmaps. For technology leaders and system architects, this upheaval can create significant strategic challenges, as they must balance the urgent need for security with the equally pressing demands of innovation and market competitiveness.

In light of these hidden costs, it becomes evident that the traditional approach to memory safety is far from ideal. Product owners and development teams need solutions that address security vulnerabilities without derailing their operations and straining their resources.

The Memory Safety Crisis: A Growing Concern

Memory safety vulnerabilities have become a pressing issue in today’s digital landscape, with far-reaching consequences. According to a recent study by Microsoft, nearly 70% of all software vulnerabilities stem from memory safety issues, underscoring the critical nature of this threat. High-profile breaches, such as the Heartbleed bug and the WannaCry ransomware attack, highlight the devastating impact these vulnerabilities can have. These incidents not only compromised sensitive data but also caused billions of dollars in damages and disrupted services globally.

As software systems grow increasingly complex, maintaining memory safety becomes more challenging. Modern applications often integrate numerous third-party libraries and dependencies, each with its own potential vulnerabilities. This complexity amplifies the difficulty of ensuring that every component adheres to stringent memory safety standards. For software developers and security professionals, the task of safeguarding these intricate systems is akin to finding a needle in a haystack, requiring continuous vigilance and comprehensive testing.

Given the escalating scale and sophistication of these threats, the need for proactive and effective solutions is more urgent than ever. Traditional methods like rewriting code are no longer sufficient. Product manufacturers must adopt innovative strategies that can address memory safety vulnerabilities swiftly and efficiently, without compromising their operational capabilities.

Innovative Approaches to Memory Safety

New approaches to memory safety are transforming the way product manufacturers address vulnerabilities. Advanced software hardening techniques have emerged as a game-changer, providing robust security enhancements without disrupting existing workflows. These methods integrate seamlessly with current software development processes, ensuring that memory safety is maintained without compromising operational efficiency.

Key features of these advanced approaches include real-time monitoring and threat detection, which continuously scan applications for suspicious activity. Automated response and recovery mechanisms further bolster security by swiftly neutralizing threats and restoring systems to a safe state, minimizing downtime and mitigating the impact of attacks.

Moreover, these innovative solutions are designed to be compatible with a wide range of software environments, ensuring that they can be deployed across diverse platforms and applications. This flexibility makes it easier to adopt these techniques without extensive modifications to existing infrastructure. For product managers and security leaders, the benefits are clear: enhanced security, reduced risk of breaches, and a more resilient software ecosystem, all achieved without the significant resource investment typically associated with code rewrites.

Addressing Memory Safety: A Comprehensive Approach

Addressing memory safety requires a comprehensive and multifaceted approach that goes beyond implementing innovative technologies. While advanced software hardening techniques are crucial, their effectiveness is amplified when combined with best practices and robust organizational policies. This holistic strategy ensures that every aspect of the software development lifecycle prioritizes memory safety, creating a resilient and secure foundation.

Collaboration is key to achieving this goal. Developers, security teams, and stakeholders must work together to identify vulnerabilities, develop mitigation strategies, and implement effective solutions. By fostering open communication and collaboration, product teams can ensure that memory safety is not just a technical issue but a shared responsibility. This unified effort helps to align priorities, streamline processes, and ensure that security considerations are integrated into every phase of development.

Continuous training and awareness are also vital components of a comprehensive memory safety strategy. Regular training sessions and workshops help keep teams updated on the latest threats, best practices, and technological advancements. Encouraging a culture of knowledge-sharing and continuous learning ensures that everyone, from junior developers to senior architects, remains vigilant and informed.

By combining innovative solutions with collaborative efforts and ongoing education, product manufacturers can build a robust defense against memory safety vulnerabilities. This comprehensive approach not only enhances security but also promotes a culture of secure software development, ensuring long-term protection and resilience.

To achieve memory safety and calculate your potential attack surface reduction, consider implementing software memory protections without rewriting a single line of code. Imagine how much your CFO will appreciate the efficiency and cost savings of this proactive security measure. Start enhancing your software’s defense today!

The post The Real Cost of Rewriting Code for Memory Safety – Is There a Better Way? appeared first on RunSafe Security.

Securing Airborne Systems with Advanced Memory Safety Techniques

How RunSafe Code Works

RunSafe Code Qualification – Development Tool

RunSafe Code Certification – Flight Software

RunSafe Code Certification – Airworthiness Security

Elevating Flight Safety: Software Security in Airborne Systems

Securing Airborne Systems with Advanced Memory Safety Techniques

Critical software, including vital infrastructure management systems, heavily relies on languages like C and C++, notorious for their power but plagued by memory vulnerabilities. The NSA reports that 70% of security fixes by tech giants like Google and Microsoft pertain to memory safety, a concern echoed in MITRE’s Top 25 Most Dangerous Software Weaknesses, where memory safety ranks first, as well as seven of the top twenty-five vulnerabilities. 

The crux of the problem lies in the predictability of these languages. Without measures like RunSafe, discovering a memory vulnerability in one software binary becomes a gateway for attackers, simplifying the exploitation process. This challenge is compounded by the proliferation of open-source code and advancing binary analysis tools.

RunSafe’s product, RunSafe Code, aims to address these vulnerabilities. It will be certifiable for flight safety at the highest level through DO-178C at DAL A and qualifiable by DO-330 at TQL 1. Comprising two components, RunSafe Code operates during both compilation and execution of software. The security features of RunSafe will be outlined in shell documents, offering comprehensive insights into its design. 

How RunSafe Code Works

RunSafe Code modernizes software security by dynamically relocating function loads into memory uniquely for each instance deployed, thwarting attackers’ attempts to exploit memory-based vulnerabilities, which constitute nearly 70% of compiled code vulnerabilities. This is achieved without altering any lines of source code, ensuring no impact on system performance or functionality.

During the development phase, integrating RunSafe Code into software renders exploitation attempts unreliable for attackers, as the code needed for exploitation is never in the same place twice. Even failed exploit attempts result in program crashes, rendering any gained information useless upon relaunch. This seamless integration with existing compilers and linkers streamlines the development process, ensuring compatibility with various build systems, from simple examples to complex builds using different compilers per project.

In airborne systems, RunSafe Code continues its transformative role, ensuring unique memory layouts for each binary and shared object. Through metadata embedded in the ELF file, RunSafe Code relocates functions in memory using customer-defined seeds, ensuring a deterministic relocation process. Notably, this relocation process incurs no runtime performance overhead, preserving the program’s intended functionality without compromising performance.

This robust approach to software hardening, both during development and deployment, positions RunSafe Code as a vital tool in the arsenal against cyber threats, qualifying it under industry standards such as DO-330 and DO-178C for airborne systems. With RunSafe Code, software developers can confidently bolster their defenses against exploitation attempts, ensuring the resilience and security of critical software systems.

RunSafe Code Qualification – Development Tool

RunSafe is certifying RunSafe Code as a TQL-1 tool and flight software at DAL-A, enabling its use across diverse Critical Software Configuration Items (CSCIs), regardless of their DAL classification. TQL-1, the most stringent level outlined by DO-330, demands meticulous qualification due to its potential impact on flight safety, acknowledging the catastrophic consequences of any defects introduced into flight software.

The  certification process adheres rigorously to DO-330’s objectives and activities, ensuring compliance with engineering independence. Recognizing the existing version of RunSafe Code as a prototype, the project anticipates addressing any gaps identified during the certification phase systematically. Development plans, standards, and work products are meticulously crafted and vetted, with engineering independence verifying their integrity.

Moreover, the tool qualification package assembled will furnish CSCI developers with essential materials, including Tool Operational Requirements (TOR), a Tool Qualification Plan (TQP), and verification test cases. Draft materials provided by RunSafe will be tailored by developers, ensuring seamless integration into their environments. Any issues encountered during application will be escalated to RunSafe for resolution, with developers assuming responsibility for correct tool usage and adherence to quality assurance protocols.

RunSafe Code Certification – Flight Software

Under DO-178C, CSCI developers are tasked with creating software that follows a detailed certification plan. RunSafe Code introduces novel alterations to the CSCI executable, invalidating the formal “run for score” test that verifies compliance with DO-178C expectations. Thus, this testing must occur after applying RunSafe Code. 

To meet DO-178C requirements, RunSafe Code provides proposed materials for integration into the CSCI developer’s data, including proposed system requirements, Software High Level Requirements (HLRs), and Low Level Requirements (LLRs), along with test cases and trace data. The seed value generated for each load is treated as a Parameter Data Item (PDI) under DO-178C. The qualification package includes draft materials for integration, outlining proposed changes to the CSCI plan and development artifacts to accommodate RunSafe Code alterations.

RunSafe Code modifies source code to relocate itself in allocated memory space upon loading, using a randomly selected seed value. This deterministic relocation ensures uniqueness across instances, thus enhancing software security.

RunSafe Code Certification – Airworthiness Security

DO-326 and DO-356 emphasize an integrated approach to cybersecurity, aiming to prevent and mitigate cyber attacks by integrating security strategies tailored to specific systems and environments. RunSafe Code contributes to this approach by aligning with two key principles: Defense in Depth and Ease of Maintenance.

By enveloping the entire product CSCI with its protective shield, RunSafe forms a crucial layer within the Defense in Depth strategy, allowing developers to concentrate on custom defense strategies for their projects. Moreover, RunSafe Code simplifies CSCI maintenance by assuming responsibility for tool upkeep, training, support, and documentation.

RunSafe provides comprehensive documentation to meet the requirements of DO-326/356, serving as a model for CSCI developers. This documentation includes security certification plans, risk assessments, system requirements, and verification results. While tailored to RunSafe Code, this package serves as a template for other CSCIs, offering operational and maintenance guidance.

Committed to supporting CSCI developers, RunSafe assists in the successful implementation of RunSafe Code and addresses any arising issues, ensuring robust software supply chain security.

The post Elevating Flight Safety: Software Security in Airborne Systems appeared first on RunSafe Security.

Memory Safety Through Hardening System Code

From Static to Moving

Risk Assessment

Hardening the Code

Protecting vulnerable systems

A static target is a sitting duck. However, we all know that hitting a moving target can be far more challenging—as it involves accounting for the target’s speed, direction, and distance. Then there are other factors, such as the attacker’s skill, the type of weapon used, and environmental conditions, which also play a significant role in determining the difficulty of hitting a moving target. The embedded software world, the world in which our country’s critical infrastructure (government, business, military, utilities, and more) exists, and is utilized and repurposed, is a static target. That’s changing. It has to change. The embedded software of our most vital systems is vulnerable…and constantly under attack.

Weapons systems, in particular, are tempting targets. According to Schneier on Security, “Our military systems are vulnerable. We need to face that reality by halting the purchase of insecure weapons and support systems and by incorporating the realities of offensive cyberattacks into our military planning. Over the past decade, militaries have established cyber commands and developed cyberwar doctrine. However, much of the current discussion is about offense. Increasing our offensive capabilities without being able to secure them is like having all the best guns in the world, and then storing them in an unlocked, unguarded armory. They just won’t be stolen; they’ll be subverted.”

This blog is obviously speaking to the broader aspects of cybersecurity. But the point is valid. When it comes to cybersecurity, we need to turn our focus toward defense. Defending our weapons systems’ memory-based vulnerabilities. And defending the memory-based vulnerabilities in all of our critical infrastructure.

From Static to Moving

For more than a year now, the U.S. government has been communicating the severity of the risk that memory-based vulnerabilities pose in embedded software deployed across critical infrastructure. According to MITRE, 3 of the top 8 (and 8 of the top 25) most dangerous software weaknesses are memory safety related. Microsoft and Google have each stated that software memory safety issues are behind approximately 70% of their vulnerabilities. The NSA recommends that software producers using C and C++ languages should rewrite their products in memory-safe languages such as Rust (a modern version of C and C++ that ensures that programmers write stable and extendable, asynchronous code).

But therein lies the heart of the problem. Making the move to memory-safe languages is more than difficult. It’s both time- and cost-prohibitive to rewrite all your system code in another language. So how do you ensure memory safety, and thereby close the loopholes that adversaries are taking advantage of? The key is in how we think about it. We must shift our thinking away from merely patching problems toward a more strategic approach. Let’s not just fill in the holes in the road (again and again and again); let’s build a new road! 

The first step in taking immediate action toward solving the problem is to research what other options are available. Existing scanning, patching, and monitoring tools do not solve the memory vulnerabilities inherent in C and C++ coded systems. Perhaps it’s time to consider a solution that would protect your current code, while you make the transition to memory-safe languages for future coding. It’s important to look for tools that will enable your software development team to achieve memory safety without rewriting code and without affecting system performance.

Specifically, this suite of tools should cover the three most common use cases: dropping security into the code at build time, downloading protected versions of open-source software packages, and flagging instabilities and vulnerabilities at runtime.

Risk Assessment

Currently, attackers have the advantage over defenders in cybersecurity. The right tool looks to shift the balance of power from the attacker to the defender while preventing data loss. To shift the balance of power, you first need to know how exposed your software is to memory-related exploits. That is, a risk assessment.

The right tool will utilize the National Vulnerability Database (NVD) to analyze software vulnerabilities in hundreds of thousands of software packages (open-source, commercial, and proprietary software) and use a fast and powerful methodology to examine the software bill of materials (SBOM), assess the risk to the system, and alert stakeholders.

Lastly, the tool you choose should automate the hardening of high-risk code with moving-target defense technologies, reducing the attack surface by eliminating the exploitation of entire classes of vulnerabilities and data theft.

You want insights within minutes, including a detailed list of recommendations.

Hardening the Code

As discussed, the toughest target to hit is a moving target. You want to turn your code into that moving target, hardening your code using load-time function randomization (LFR). This stops hackers from exploiting memory-related vulnerabilities. Rather than taking 5-10 years and millions (if not tens of millions) of dollars to rewrite every line of code to memory-safe languages, LFR can be applied in minutes without rewriting software.

This software diversity relocates where functions load into memory uniquely for every software load for each instance deployed, denying attackers the ability to exploit memory-based weaknesses.

With no new software and no change in the lines of code, there is no change in system performance and no change in functionality. It’s important to employ Moving Target Defense (MTD)-related techniques for this approach, so the hardening process does not incur performance overhead. That way, there is no way for hackers to know distances between functions or create exploits that take advantage of knowing how functions are laid out, let alone launch and scale attacks on your systems.

Hardening the code helps you achieve the transition from a static target to a moving target, reducing the software attack surface by eliminating the exploitation of software memory issues and protecting your data.

The post Memory Safety Through Hardening System Code appeared first on RunSafe Security.

Safeguarding LYNX MOSA.ic: Lynx and RunSafe’s Security Partnership

Why does memory safety matter to Lynx users?

No impact on Runtime performance? Development schedule?

Easier compliance with security requirements

What about the Software Bill of Materials?

How to immunize LYNX MOSA.ic against 70% of code vulnerabilities?

Safeguarding LYNX MOSA.ic: Lynx and RunSafe’s Security Partnership

RunSafe Security is excited to announce a strategic partnership with Lynx Software Technologies (Lynx). The partnership between Lynx and RunSafe protects LYNX MOSA.ic against 70% of the most common vulnerabilities with no developer impact.

At the launch of the partnership with Lynx Software Technologies, the RunSafe protection applies to the build root Linux operating system, applications, and customer software. In early 2024, the team intends to release the LynxOS-178 version of the protections. 

The segments, including aircraft manufacturers, industrial controls, defense systems, and IOT devices, are really challenged with meeting desired delivery schedules at a time when system complexity is increasing at a fast rate. Our effort here with Lynx is beyond “marketecture” and PowerPoint. The purpose of this engagement is to deliver RunSafe technology as a proven component in LYNX MOSA.ic. The “ic” stands for Integration Center and we fully believe that one critical piece in enabling reductions in program risk and development schedule comes from integrating cybersecurity protections during the product development process. Lynx will deliver RunSafe’s technology as part of its LYNX MOSA.ic product.

Why does memory safety matter to Lynx users?

Prevalence of Memory Safety Bugs

In compiled code, memory safety bugs are the single largest class of bugs. In the embedded and real-time operating system spaces, compiled code represents the vast majority of code. A few statistics, based on research at North Carolina State University:

• Typically 70% of the bugs in compiled code are memory safety issues.
• Memory safety bugs have a much more severe impact on systems, according to their average severity scores (NVSS). 
• 59% of memory-related code vulnerabilities have been weaponized, with exploits readily available. 
• Memory safety bugs tend to take much longer for developers to fix, relative to non-memory safety bugs (180 days for memory safety vs 90 days for non-memory safety).

Patching Deployed Systems is Difficult

Time is on the side of the attackers. Deployment cycles of systems in military, aerospace, and federal markets are long. In the case of planes, they can be measured in decades. Patches are hard to deploy to these complex, fielded systems. Meanwhile, highly resourced and skilled attackers develop cyber kill chains, finding (or buying on the dark web) zero days. With RunSafe, systems running Lynx RTOS are protected and future-proofed against the majority of these zero-day attacks without patching.

Regulatory Drivers

For those Lynx customers selling to US government programs, there is an increased focus on the memory safety of acquired systems and software. Figure 1 below shows actions undertaken by the US government to tighten up memory safety.

Figure 1

No impact on Runtime performance? Development schedule?

The process of reordering the functions happens when the process is set up in memory. Instead of jumping right to the normal entry point for the function, the binary reorders its functions first. Then it begins normal operations. This reordering of memory typically adds only 1%-3% to process setup time. If a function took 1 second to load before, it will now load in 1.01 to 1.03 seconds.

From that point forward, the RunSafe protection is passive. There is no change in the sheer instruction count, control flow, etc. There are no additional memory reads, writes, lookups, etc. Our customers, even on the most stringent real-time systems, have never found a measurable impact on runtime performance.

Easier compliance with security requirements

Lynx customers are better able to document their compliance with RMF (DoDI 8510.01), which incorporates NIST 800-53. Consequently, programs accelerate time to ATO at a lower cost. For high-impact systems, RunSafe enhances compliance with more than 20% of the controls. For many RunSafe-impacted controls, the only alternative is thousands of hours of testing. 

RunSafe provides “last-mile integrity” into the running memory, increasing confidence that the code operates in memory the way the developer intended. By mitigating an entire class of vulnerabilities, RunSafe makes possible incident handling responses that were previously impossible. This protection can be applied to every layer of the system’s software. Table 1 shows the breakout of impacted controls across the various levels of system integrity. A whitepaper with more details about the NIST 800-53 controls can be found here.

Table 1

What about the Software Bill of Materials?

Machine-readable SBOMs are being required by EO14028 and making their way into FAR clauses. RunSafe’s tools make it possible to build a complete and perfect SBOM for each Lynx project, regardless of whether a package manager is used for the compiled code, or not. By working into the build process, RunSafe is able to identify every file coming into the build, every dependency, library, include file, etc., and build a perfect tree of dependencies between the components. For Lynx Software Technologies customers, this is a zero-effort activity.

How to immunize LYNX MOSA.ic against 70% of code vulnerabilities?

A future webinar and configuration document will describe the configuration steps, but this would involve a slight change to a build script, instructions on where to include the license key, and which configuration files to edit. No other changes are necessary (see figure 2).

Figure 2

How does RunSafe Security Code protect the OS and applications?

Memory safety bugs (stack overflows, heap overflows, etc.) wreak havoc on their targets by using code already in memory in unintended ways. For example, by moving the instruction pointer one byte past an add instruction, the processor may execute a branch instruction. For these attacks to work, the attacker must have highly predictable insight into the layout of memory on the victim process.

Figure 3 below shows a few different memory scenarios. The first column is the memory layout if no protection is applied. This gives the attacker a perfectly deterministic layout across all devices. The second column shows the protection of a technique called Address-Space Layout Randomization (ASLR). This randomizes the base address of binaries or libraries, but t威而鋼
he body of the binary will still have a deterministic organization, relative to this base address. Given the prevalence of memory leaks, ASLR hasn’t done much to slow down attackers in the last 15 years. RunSafe’s protection randomizes the individual functions that comprise a binary, as shown in the Fine-grained randomization graphic.

On average, binaries tend to have around 280 functions. That gives our attacker roughly 280(!) permutations to consider. To understand that scale, if an attacker were able to attempt 100 trillion possible randomizations every nanosecond, the attacker would spend 3*10524 universes before they hit every possible permutation.

Figure 3

After analyzing thousands of binaries and hundreds of thousands of functions using open-source software, RunSafe Security was able to show that there weren’t enough bits of code to misuse at a function-level, to create attacks that work on unprotected code.

The post Safeguarding LYNX MOSA.ic: Lynx and RunSafe’s Security Partnership appeared first on RunSafe Security.

A Bridge to Memory Safety: Leveraging Load-time Function Randomization for Immediate Protection and Liability Shift

Addressing Critical Infrastructure Vulnerabilities: Insights and Recommended Actions

Advancing Memory Safety Measures

Mitigating Memory Exploits: The Power of Load-time Function Randomization

Enabling Immediate Memory Safety

Addressing Critical Infrastructure Vulnerabilities: Insights and Recommended Actions

The looming threat China poses in attacking the US Critical Infrastructure – whether in conjunction with a military attack on China or independent of it – raises the question: what can we do to solve the most serious vulnerabilities enabling potential disruptions in service, memory-based vulnerabilities?   

The default answer today through NSA Guidance and a call to action by CISA Director Jen Easterly is for industries to employ memory safe languages. However, this rewriting of code will take 10-20 years, billions of dollars, and create a significant disruption – and as such will not be available in time to fend off an attack from China. 

To avoid delays in implementing memory safety through the long time frame in which memory safe languages would take to be adopted and to save money by protecting software without rewriting software, the US Government can enable Memory Safety without delay, as follows:

• Incorporate memory safe mitigation methods, such as Load-time Function Randomization, now across all critical infrastructure applications;
• Implement the shift in liability from the operator to the product manufacturer within 3-6 months; and, 
• Offer safe harbor to anybody who deploys Load-time Function Randomization along with other Secure by Design / Secure by Default controls

Advancing Memory Safety Measures

With the release of the Office of National Cyber Director’s (ONCD) National Cybersecurity Strategy (NCS) document and the subsequent Cybersecurity and Infrastructure Security’s (CISA) announcement of Secure by Design / Secure by Default (SBD^2), the US Government has taken a very strong step forward to mitigate memory safety issues in software code that adversaries use to exploit software across Critical Infrastructure.   

Although SBD^2 principles are sound and proven to help industries move forward with guidance, shifting to memory safe languages today is extremely difficult – and the combination will not yield memory safety immediately. This document summarizes actions that can be taken today to ensure memory safety is viable today.  

By incorporating these recommendations into the rollout of Memory Safety programs going forward, the US Government can give industries the ability to shift liability and enable safe harbor immediately.

Mitigating Memory Exploits: The Power of Load-time Function Randomization

• ROP Gadgets, the building blocks for memory-based exploits, cannot be leveraged when Load-time Function Randomization is employed as they can with ASLR employed. Based on a 2023 RunSafe study, return oriented programming gadgets that leverage memory based-vulnerabilities remain effective even when Address Space Layout Randomization (ASLR). Over 40% of all CVEs are memory corruption related, and exploits targeting these vulnerabilities are nearly 100% successful even when Address Space Layout Randomization (ASLR) is present. Protecting the exact same binaries and libraries with RunSafe’s Load-time Function Randomization (LFR) reduces this memory safety exploitation risk to effectively zero (less than 1/245,194).
• Load-time Function Randomization eliminates the exploitation of all related memory CWEs and their CVEs. In a 2022 study by North Carolina State University, binary randomization mitigates over 99% of all exploits targeting memory related CWEs and their associated CVEs.  

• Several production deployments of Load-time Function Randomization exist to prove it as a viable solution for industries to employ. Examples include using LFR to protect against  exploitation of memory vulnerabilities, including
  • Software used on Navy vessels
  • Firmware used in computer servers
  • Embedded code on engine controllers
  • Flight management software on satellites
  • Interoperability components of electric vehicle charging stations

• Load-time Function Randomization doesn’t require developers to rewrite software like deploying memory safe languages would require. LFR offers a counter to objections from industry who will object to the labor and time required. Rather than taking 5-10 years to transition memory safe languages that could cost millions if not tens of millions of dollars to rewrite products, LFR can be applied in minutes without rewriting software. 

Enabling Immediate Memory Safety

• Memory safe remediation methods employing Load-time Function Randomization offers a bridge to memory safety today. 
• This approach as a means of memory safe remediation methods complements SBD^2 controls and could be immediately added to the approach to enable the immediate rollout of the liability shift and safe harbor provisions of the ONCD’s NCS document and CISA’s SBD^2 program. 
• The Load-time Function Randomization is proven to be more effective than ASLR and is deployed by industries today.

For people interested in detailed reading on the analysis discussed above, please contact us for these research summaries:

1. Memory Safe Methods Prevent Exploitation – NC Study demonstrating methods mitigate against exploitation of memory related CWEs and their CVEs.
2. Memory Safe Methods Are Far Superior to ASLR – Unlike ASLR, RunSafe analysis demonstrates information leaks are insufficient to generate complete ROP chains that lead to successful exploits.

Let’s solve Memory Safety now – and let’s be prepared if China attempts to disrupt our critical infrastructure as part of a broader geopolitical conflict.

The post A Bridge to Memory Safety: Leveraging Load-time Function Randomization for Immediate Protection and Liability Shift appeared first on RunSafe Security.

Cyber Hardening in the Modern Age: Why Military Systems Need to Keep Up

Cyberattacks on Military Systems Are Nothing New

Deadly Consequences

How Can We Effectively Cyber Harden Our Military Systems?

Every person worldwide, from the girl next door to top-secret military personnel and diplomats, is deeply rooted online. From how we work and play to how we learn and worship, cyberspace has consumed every facet of our daily lives. Our reliance on cyberspace extends to the ways we govern and protect our countries.

As such, cyberattacks have become among the world’s gravest dangers. Not only can they impact our bank accounts, but exploits can also disrupt power grids and threaten national security. 

Currently, the United States Department of Defense (DoD) is “hardening” its systems, which involves eliminating cyberattacks by patching vulnerabilities and switching off nonessential services, sensors, and networks against such attacks. Across the pond, the UK’s Defense and Security Accelerator (DASA) is taking the same precautions in the form of a new Innovation Focus Area (IFA) to identify and implement technologies that will improve the Ministry of Defense’s resilience against cyberattacks.   

Cyber hardening, or eliminating cyberattacks by patching vulnerabilities and switching off nonessential services, is paramount in the digital age. But how secure are our military systems, and what can we do to protect them?

Cyberattacks on Military Systems Are Nothing New

The threat of cyberattacks on military network security systems isn’t a new problem. In fact, it’s been an issue since computers were first introduced to US Navy war rooms during World War II. However, as our dependency on technology grew, so did our risks.

Cyber warfare, or cyberattacks that target critical infrastructure, including military weapons, can be deadly to both the military and civilians. Some of the most common types of cyber warfare include exploits leading to espionage, sabotage, and denial-of-service (DoS) attack. These attacks can cause mass power outages, economic disruption, and even death. 

A few significant examples of cyber warfare in modern times include: 

• Stuxnet Virus: This worm attacked Iran’s nuclear program and was spread through infected Universal Serial Bus devices. 
• Sony Pictures Hack: In 2014, a hacker group called Guardians of Peace released confidential data from Sony Pictures, including personal information about Sony employees and their families. The hackers demanded that Sony withdraw its movie The Interview, which depicted North Korean leader Kim Jong-un in a negative light. 
• Fancy Bear: A Russian-organized group of cybercriminals targeted Ukrainian artillery and rocket forces between 2014 and 2016. The malware was spread through infected Android apps used by the artillery unit to manage data.
• NASA Hack: In 1999, a 15-year-old boy named Jonathan James hacked into the US Department of Defense and NASA, stealing valuable software used to support the International Space Station. 

Seeing that even bored teenagers can hack into government systems, it’s vital that the military efficiently protects itself and takes the necessary precautions to pinpoint software vulnerabilities.

Deadly Consequences

The consequences of a cyberattack on military systems can be far-reaching. Not only can it jeopardize critical infrastructure, but it can put both military personnel and civilians at risk. Sensitive information can be sold on the dark web to hack bank accounts and steal identities. In addition to impacting people, cyberattacks can jeopardize a company’s compliance, reputation, and profits. 

Cyber terrorists can also disable crucial operations and systems, disrupt infrastructures, target the supply chain, render communications—like texting—unusable, spread propaganda, and weaken a country’s defenses against a massive physical attack.

How Can We Effectively Cyber Harden Our Military Systems?

So, how can the military reduce surface attacks and efficiently harden its embedded systems?

In an official statement, the White House urged all organizations to do the following:

• Mandate the use of multi-factor authentication for all systems
• Ensure all systems are patched and protected against vulnerabilities
• Implement modern security tools on all devices and computers
• Encrypt and back up all data
• Educate employees on common cyberattack strategies

Military systems can take additional steps to improve their protection and risk management strategies by educating employees and investing in advanced cybersecurity equipment and technology, like RunSafe Security.

RunSafe can drastically reduce military systems’ risk of cyberattacks without disrupting software developers and maintainers. Our technology inoculates systems to mitigate memory corruption vulnerabilities, which are prevalent in compiled codes and often targeted by attackers. 

Discover what software in your system is at risk for attack. Protect your systems with products already used by the US Air Force, the US, Navy, and major primes.

The post Cyber Hardening in the Modern Age: Why Military Systems Need to Keep Up appeared first on RunSafe Security.