RunSafe Security’s 2025 AI in Embedded Systems Report, based on a survey of over 200 professionals throughout the US, UK, and Germany working on embedded systems in critical infrastructure, captures the scale of this shift: 80.5% use AI in development, and 83.5% already have AI-generated code running in production.

As AI-generated code becomes a permanent part of embedded software pipelines, embedded systems teams need a clear view of where vulnerabilities are most likely to emerge.

According to respondents, six risks stand out as the most urgent for embedded security in 2025.

Listen to the Audio Overview

The 6 Most Critical Risks of AI-Generated Code

1. Security of AI-Generated Code (53% of respondents)

Security vulnerabilities in AI-generated code remain the single most significant concern among embedded systems professionals. More than half of survey respondents identified this as their primary worry.

AI models are trained on vast repositories of existing code, much of which contains security flaws. When AI generates code, it can replicate and scale these vulnerabilities across multiple systems simultaneously. Unlike human developers, who might introduce a single bug in a single module, AI can reproduce the same flawed pattern across entire codebases.

The challenge is particularly acute in embedded systems, where code often runs on safety-critical devices with limited ability to patch after deployment. A vulnerability in an industrial control system or medical device can persist for years, creating long-term exposure. Traditional code review processes, designed to catch human errors at human speed, struggle to keep pace with the volume and velocity of AI-generated code.

2. Debugging and Maintainability Challenges (45.5% of respondents)

Nearly half of embedded systems professionals worry about the difficulty of debugging and maintaining AI-generated code. When a human engineer writes code, they understand the logic and intent behind every decision. When AI generates code, that understanding often doesn’t transfer.

When bugs appear, tracing their root cause becomes significantly harder. Engineers must reverse-engineer the AI’s logic rather than reviewing their own design decisions. When modifications are needed—whether for new features or security patches—developers must understand code they didn’t write and may struggle to modify without introducing new issues.

In embedded systems, where code often has a lifespan measured in decades, maintainability is critical. If the original code is AI-generated and poorly documented, each maintenance cycle becomes progressively more difficult and error-prone.

3. Regulatory and Compliance Uncertainty (41% of respondents)

41% of survey respondents flagged regulatory and compliance uncertainty as a major concern with AI-generated code. Yet the certification processes organizations rely on today weren’t designed to account for AI-generated code. In regulated industries such as medical devices or aerospace, obtaining code certification requires extensive documentation of design decisions and validation procedures. When AI generates the code, much of that documentation doesn’t exist in traditional forms.

This creates several challenges. Organizations must make their own determinations about what constitutes adequate validation for AI-generated code, with limited regulatory guidance. When incidents occur, the question of liability becomes murky: Who is responsible when AI-generated code fails?

4. Reuse of Insecure Patterns (27.5% of respondents)

AI models learn from existing code, and that code is often flawed. More than a quarter of embedded systems professionals worry that AI tools will perpetuate and scale insecure coding patterns across their systems.

This risk is particularly concerning because it’s systemic rather than isolated. If an AI model is trained on C/C++ code that commonly contains memory safety issues—and C/C++ historically dominates embedded systems—the AI will likely generate code with similar vulnerabilities.

This risk isn’t just theoretical. Memory safety vulnerabilities such as buffer overflows and use-after-free errors account for roughly 60-70% of all security vulnerabilities in embedded software. If AI tools perpetuate these patterns at scale, the industry could see a multiplication of one of its most persistent and exploitable vulnerability classes.

5. Lack of Transparency and Explainability (26% of respondents)

AI-generated code often functions as a black box. The code works, but understanding why it works or why it fails can be extraordinarily difficult. 26% of embedded systems professionals cite this lack of transparency as a significant concern.

In embedded systems, where reliability and safety are paramount, this opacity creates serious problems. Engineers need to understand not just what the code does, but how it handles edge cases, error conditions, and unexpected inputs. With AI-generated code, that understanding is often incomplete or absent.

The survey reveals additional concern about what happens when AI-generated code becomes increasingly bespoke. Historically, when developers used shared libraries, a vulnerability discovered in one place could be patched across an entire ecosystem. If AI generates unique implementations for each deployment, this shared vulnerability intelligence fragments, making collective defense more difficult.

6. Legal and Licensing Risks (19.5% of respondents)

Nearly one in five embedded systems professionals identifies legal and licensing risks as a concern with AI-generated code. AI models are trained on vast amounts of code, much of it open source with specific licensing requirements. When AI generates code, questions arise: Does the output constitute a derivative work? Who owns the copyright to AI-generated code?

These questions remain largely unresolved, and different jurisdictions may answer them differently. For embedded systems manufacturers, this creates software supply chain risk. If AI-generated code inadvertently reproduces proprietary algorithms or patented methods from its training data, manufacturers could face infringement claims.

For organizations in regulated industries or those serving government customers, these legal uncertainties can be deal-breakers. Defense contractors, for example, must provide clear provenance and licensing information for all software components.

Why These Risks Matter for Embedded Systems Teams

The 2025 landscape reveals an industry at a critical juncture. AI has fundamentally changed how embedded software is developed, and that transformation is accelerating. 93.5% of survey respondents expect their use of AI-generated code to increase over the next two years.

But this acceleration is happening faster than security practices have evolved. The tools and processes that worked for human-written code at human speed aren’t designed for AI-generated patterns at machine velocity.

The good news is that awareness is high and investment is following: 91% of organizations plan to increase their embedded software security spend over the next two years.

Understanding these six critical risks provides a roadmap for where design decisions, security investments, and process changes will have the most significant impact. Organizations that address these risks proactively—through better tooling, enhanced testing, runtime protections, and clearer governance—will not only strengthen their systems but also position themselves as industry leaders.

The insights in this post are based on RunSafe Security’s 2025 AI in Embedded Systems Report, a survey of embedded systems professionals across critical infrastructure sectors. 

Explore the full report to see the data, trends, and strategic guidance shaping the future of secure embedded systems development.

The post The Top 6 Risks of AI-Generated Code in Embedded Systems appeared first on RunSafe Security.

Key Takeaways

• The 2025 SBOM minimum elements represent significant progress since the 2021 baseline.
• New fields, such as license, hashes, and generation context, push SBOMs beyond check-the-box compliance.
• Licensing data closes a critical blind spot in software supply chain risk management.
• Generation context highlights build-time SBOMs as the industry gold standard.
• Embedded software remains at risk of being overlooked unless file-level SBOMs are explicitly recognized.

In August 2025, the Cybersecurity and Infrastructure Security Agency (CISA) and the Department of Homeland Security (DHS) released a new draft of the Minimum Elements for a Software Bill of Materials (SBOM). It’s the first major revision since 2021, when the National Telecommunications and Information Administration (NTIA) outlined a simple baseline of just seven fields.

The new draft is a genuine turning point. It raises the bar for SBOMs, pushing them beyond check-the-box compliance and closer to being a real tool for managing risk. But while these changes are a big step forward, they still leave embedded systems—built largely in C and C++—struggling to fit into a framework designed with modern package-managed software in mind.

As Kelli Schwalm, SBOM Director at RunSafe Security, puts it: “The recommended 2025 SBOM minimum elements show how far the industry has come since 2021. We’ve moved from a theoretical checklist to practical requirements that reflect how SBOMs are actually used in the real world.”

However, Kelli warns, the implicit assumption in the draft recommendations is that a software component equals a package. For embedded systems, that’s not the case. Without explicit recognition of file-based SBOMs, we risk leaving critical systems out of the picture.

Listen to the Audio Overview

The post The 2025 SBOM Minimum Elements: A Turning Point But Embedded Systems Still Risk Being Left Behind appeared first on RunSafe Security.

Security can either be your biggest margin killer or your most powerful profit enabler. From the beginning, our goal at RunSafe has been to put control back into the hands of the defenders. And that means building solutions that meaningfully reduce risk across your product portfolio. As cyber defense champions, we can quantify economic benefits to security solutions that improve your product line profitability.

Listen to the audio overview below: 

The Cost of Reactive Security

Security incidents now average $4.88 million per breach according to IBM’s 2024 Cost of a Data Breach Report, but that figure only scratches the surface. The real damage comes from the operational drag that reactive security creates long before any breach occurs.

Consider an example from a software manufacturer, one of RunSafe’s customers. Implementing RunSafe’s runtime code protection saved the company over $1 million per year, with reduced patching representing the largest cost saving. 

Calculate your potential Total Cost of Ownership here.

Being proactive about security (deploying RunSafe Protect) rather than reactive (relying on patching) saved this company a significant amount of money. And it’s not just money. It’s also about opportunity cost.

The hidden costs of reactive security include:

• R&D Resource Drain: Effort is put into code scanning/review, penetration testing, subsequent remediation, and then coordinated release of patches to customers. These issues spawn lengthy retesting cycles and gobble up R&D resources that would otherwise be able to work on new features and products.
• Market Access Barriers: Companies lose significant contracts when their security posture can’t meet customer requirements. Consider how Zoom was initially excluded from certain DoD environments due to its security posture not meeting baseline requirements.
• Developer Productivity Loss: Engineering teams spend 30-40% of their time on security remediation instead of innovation.

Competitive Disadvantage: Slower release cycles compared to competitors, who ship features faster with built-in security.

Are You Spending to Patch or Investing to Prevent?

The problem with scan-and-patch security is inefficiency and ineffectiveness. For example, in our work on embedded devices, we see on the daily that memory safety vulnerabilities account for 40-70% of identified vulnerabilities in embedded code. 

A study by North Carolina State University shows that for Linux operating system software over a 10-year period, only 2.5% of memory vulnerabilities were identified in vulnerability scanning tools. This shows us that scanning, a widely adopted practice, leaves one vulnerable.

Similarly, multiple studies say companies and users generally aren’t patching on time due to a lack of knowledge, the effort to coordinate change, the process slowing progress, fear of breaking the current setup, and other barriers. At its best, patching is reactive. More often, costs and other barriers mean patching is delayed, if done at all.

Even when vulnerabilities are found, patching faces massive barriers:

• Coordination Costs: Cross-team alignment, testing cycles, and deployment logistics
• Customer Resistance: Nobody wants to patch, especially when it might break existing functionality
• Timing Mismatches: Critical vulnerabilities discovered right before major releases
• Risk Accumulation: Delayed patches create growing attack surfaces

The math is brutal. If you’re patching reactively, you’re not just paying for the patch—you’re paying for the disruption, the delays, the testing cycles, and the opportunity costs of having your best engineers chasing down someone else’s vulnerabilities instead of building your next breakthrough feature.

The Runtime Security Advantage

Here’s where the economics flip completely. Runtime security—integrating code protection directly into your development process—transforms security from a margin killer to a competitive advantage.

RunSafe’s approach demonstrates this transformation. RunSafe Protect eliminates an entire class of vulnerability common in embedded software to defend your software from the very beginning and dramatically reduce your attack surface. Protect safeguards your systems during runtime without compromising performance or requiring post-deployment modifications.

The results speak for themselves. RunSafe deployed code protection to dramatically reduce the attack surface by 70% for an industrial automation leader deploying HMI products. The company was able to measurably reduce risk and protect software in very difficult-to-update facilities within critical infrastructure.

Understand the total exposure of your embedded software and quantify your risk reductions with RunSafe Protect. Give your code a scan.

The broader business impact includes:

• Faster Time-to-Market: No more security-driven delays in release cycles
• Predictable Operations: Controlled patch timing instead of emergency responses
• Enhanced Customer Relationships: Fewer disruptions, more reliable products
• Engineering Focus: Teams building features instead of fixing vulnerabilities
• Market Differentiation: Security as a selling point, not a compliance checkbox

Security as a Revenue Driver

Beyond cost savings, the right security approach actually opens new revenue streams. Companies with robust security profiles win contracts that others can’t touch. In RunSafe Security’s 2025 Medical Device Cybersecurity Index, we saw that 83% of healthcare organizations now integrate cybersecurity standards directly into their RFPs and 46% have declined to purchase medical devices due to cybersecurity concerns. A lack of security quickly leads to lost revenue in this competitive market. 

On the other hand, it opens the door to increased product line profitability. 79% of healthcare buyers are willing to pay a premium for devices with advanced runtime protection. Similarly in the automotive industry, RunSafe’s 2025 Connected Car Cyber Safety & Security Survey, 87% of survey participants said a car brand that offers strong cybersecurity and privacy would influence their purchase decision, with 35% willing to pay more.

Customers are saying security is worth the cost. That’s good news for product teams looking to make smart investments.

The Bottom Line

Security doesn’t have to be a necessary evil that drains profitability. When implemented early, systematically, and with business impact in mind, security becomes a competitive advantage that drives margin improvement and sustainable growth.

The companies that figure this out first will have operational advantages their competitors can’t match: faster development cycles, lower operational costs, stronger customer relationships, and access to markets that others can’t reach.

Can you afford to keep subsidizing reactive security approaches that are killing your margins and slowing your growth?

See how runtime security can transform your product line profitability. Calculate your potential ROI with RunSafe Protect or schedule a call with our team to discuss your specific business impact.

The post Is Your Security Helping or Hurting Your Product Line Profitability? appeared first on RunSafe Security.

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

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

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

1. Harden Software at the Binary Level

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

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

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

2. Treat SBOMs as a Living Security Asset

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

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

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

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

3. Protect Legacy Systems Without Rewrites

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

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

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

4. Build Cyber Resilience, Not Just Perimeter Defenses

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

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

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

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

5. Make Security a Build-Time Discipline

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

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

A Smarter Path Forward for Embedded Software Security

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

RunSafe Security gives you the tools to:

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

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

See how it works

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

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

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

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

1) The Trillion-Dollar Code Problem

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

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

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

2) Expanding the Attack Surface with Connectivity

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

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

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

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

3) Securing Legacy Systems

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

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

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

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

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

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

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

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

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

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

What Is ASLR and How Does LFR Differ?

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

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

Applications of Load-time Function Randomization  

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

Proprietary Software Protection  

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

Embedded Systems Security  

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

Application Security Hardening  

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

Benefits of RunSafe’s Implementation of LFR

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

1. Comprehensive Security  

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

2. No Performance Impacts  

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

3. Developer-Friendly Deployment  

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

4. Broad Compatibility  

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

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

Why LFR Is Essential for Software Security

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

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

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

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

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

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

What Is Runtime Application Self-Protection (RASP)?

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

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

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

Why Is Runtime Exploit Prevention Critical?

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

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

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

How Does Runtime Exploit Prevention Protect Embedded Systems?

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

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

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

Vulnerabilities Runtime Exploit Prevention Addresses

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

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

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

What Types of RASP Tools Are Available?

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

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

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

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

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

How RunSafe’s RASP Solution Stands Out

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

Here’s what sets RunSafe apart:

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

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

Final Thoughts on Adopting Runtime Exploit Prevention

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

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

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

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

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

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

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

1. Redefine Your Relationship with Vulnerabilities

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

How to Leverage Vulnerabilities as Feedback 

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

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

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

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

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

2. Embed Resilience Instead of Chasing Compliance

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

How to Build Resilience That Meets Compliance 

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

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

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

3. Focus on Vulnerability Paths, Not Just Individual Flaws

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

How to Identify and Break Exploit Paths 

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

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

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

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

4. Shift Vulnerability Ownership Across the Organization

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

How to Foster Organizational Ownership 

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

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

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

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

How to Combine Automation with Expertise 

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

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

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

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

The Cost of Inaction: Addressing Open Source Vulnerabilities 

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

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

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

Conclusion: Security as a System 

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

Take the next step today: 

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

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

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.

As we move forward into 2025, this focus is extremely promising for the future. We see change all around us and uncertainty in every arena. However, forward momentum is what we need to build more resilient products that can stand the test of time. 

Looking ahead, here are five predictions on how product security will evolve in 2025.

View the five predictions as an infographic here.

1. 200 More Companies Will Pledge Their Commitment to Secure by Design

As of December 2024, 256 companies have already signed CISA’s Secure by Design pledge, including companies like Cisco, IBM, Google, and Microsoft. RunSafe Security has also signed the pledge, which includes seven goals for software manufacturers to work toward to improve the security of their products. 

Secure by Design will certainly shape the future of product security and development for decades to come. We’re already seeing the effects with notable signees detailing their progress toward the pledge goals. Overall, Secure by Design will continue to encourage software manufacturers to focus on areas like software supply chain security and memory safety to reduce the risks to and attack surface of embedded devices. As we at RunSafe emphasize, we want to reshape the economics of security to favor defenders. Secure by Design helps to make this possible by focusing on security from the earliest stages of design and development, and we believe hundreds more companies will take up the challenge in the year ahead.

2. Asset Owners Will Begin to Demand Secure by Design

Product security is on the minds of manufacturers, but what about the buyers of software who deploy these products within their organizations and across critical infrastructure? 

As we look ahead to next year, software buyers will begin to get curious about their software supply chain and the steps their vendors are taking to reduce risk within their products. As part of this, asset owners should ask suppliers to provide Software Bill of Materials (SBOMs) to gain insight into potential exposures and vulnerabilities within software across asset owner infrastructure.
One example of an area for asset owners to focus on is CISA’s Roadmap to Memory Safety, which urges software manufacturers to publish a memory safety roadmap by January 1, 2026. Asset owners can use the memory safety roadmap as a starting point to talk with suppliers and discuss how they will approach eliminating this class of vulnerabilities.

3. Product Liability Will Come Into Focus

While Secure by Design and other CISA guidance is voluntary, as more organizations adopt these principles, there is a strong possibility that approaches to  product liability and cyber insurance within the software industry will begin to shift. Though it would be surprising to see a new executive order on critical infrastructure and product liability issued in 2025, we are seeing an immediate response to the EU Cyber Resilience Act.  Perhaps the market will seek to  increase cybersecurity warranties, guarantees, and insurance.

As software manufacturers take on more of the security burden, the way liability is distributed between suppliers and their customers in the event of a security incident will change. Device manufacturers will need to consider what the liability shift means for their business and adopt a new financial perspective to address downside liability.

4. Software Manufacturers Will Prioritize Immediate Solutions for Memory Safety

A key aspect of Secure by Design guidance issued by CISA is memory safety, and it plays a critical role in the overall security of embedded devices. Yet for many, memory safety is not as achievable by simply rewriting products..

Going into 2025, we expect an alternative  to memory safe languages to enter more prominently into the product security discussion. Although Secure by Design guides device manufacturers to rewrite all of their C and C++ software into a memory safe language like Rust, doing so would take decades and require a significant expenditure of resources and human power to accomplish. For companies who produce dozens or hundreds or even thousands of embedded software products  deployed across critical infrastructure (often with 10-30 year lifespans), it is neither feasible nor practical for them to simply rewrite all their products in memory safe languages. Not doing so, however, leaves the door open for attack in the near term.

For this reason, it’s important that software manufacturers insert memory protections, such as load-time function randomization,  intoexisting devices today rather than wait the time it would take to rewrite code. Commercial solutions, like RunSafe’s Protect solution, already exist to provide immediate protection and prevent the exploitation of devastating memory safety vulnerabilities.

5. Companies Will Become More Transparent in Sharing SBOMs

High-profile software supply chain attacks like SolarWinds and Log4j spurred the need for organizations to have visibility into their software components. SBOMs emerged as a tool for managing and mitigating software supply chain risks.

For companies that are committed to Secure by Design and product security best practices, we believe there is great value in publicly sharing SBOMs or sharing SBOMs between asset owners and suppliers. Doing so signals honesty and transparency in software development practices and makes it easier to understand where potential vulnerabilities lie.

Advancing the Resilience of Software in the Year Ahead

2025 is shaping up to be a big year for product security and the implementation of Secure by Design. We can be certain that nation-states, adversaries, and APTs will continue to target the software supply chain. I remain optimistic that software manufactures, software buyers, and the cybersecurity industry on the whole can work together to advance the resilience of software deployed in embedded devices to safeguard critical infrastructure and our world.
Learn more about best practices for safeguarding code. Download our guide to get the knowledge and tools you need to address memory safety challenges and protect your code today and into the future.

The post RunSafe Security’s 2025 Product Security Predictions appeared first on RunSafe Security.

If you’ve made a recent trip to San Francisco, it can feel like you’ve stepped into the future when you spot an autonomous vehicle navigating the streets, picking up passengers, and cruising the city’s famous hills. But as autonomous vehicles move from concept to reality and vehicle connectivity becomes the norm, embedded systems, the technology that makes it all possible, are an often overlooked but critical piece of automotive security.

Citing national security concerns, the Biden Administration proposed two bans in September 2024 that draw attention to the software supply chain within the automotive industry and the potential risks of autonomous and connected vehicles. Because modern cars include microphones, cameras, GPS tracking, and more, there is a very real threat that nation-state actors could exploit software to conduct surveillance, collecting data on vehicle movements, for example. Further, it’s possible that a bad actor could gain access through a software backdoor and disable an entire fleet of vehicles at one time, posing an immediate risk to drivers and disrupting society.

The bans, if approved, seek to address this, first by prohibiting new vehicle software originating within China or Russia by 2027 and  second banning the imports and sales of vehicles with automated driving hardware created in the countries to go into effect by 2030.

While the implications of the bans and others like it will shake out in the years ahead, the reality for today is that we need solutions that will keep autonomous and connected vehicle software resilient and secure against known threats and those yet to come.

Why Embedded Systems Matter for Automotive Security

Embedded systems are integral to modern vehicles, processing sensor data and controlling everything from engine performance to collision avoidance. However, as vehicles become more connected and automated, embedded systems face mounting security challenges and are vulnerable to a range of threats, including unauthorized access, data breaches, and potential manipulation of vehicle controls. 

“The automobile is becoming more and more of a computer on wheels and, in addition, it’s connected to a lot of different things,” explained Dave Salwen, VP of Embedded Systems at RunSafe. “While its use is great for the consumer with new features and new capabilities, it’s becoming more and more software-centric. More software vulnerabilities are coming into the system and more vulnerabilities can be exploited by bad actors.”

One of the biggest threats to embedded systems is memory-based vulnerabilities. Memory safety is a foundational aspect of software development, ensuring that programs operate reliably and securely without accessing or manipulating memory incorrectly. 

Vehicle software is vulnerable to memory safety threats in four key systems:

• • Electronic Control Units (ECUs) in Autonomous Vehicles: Responsible for critical driving functions (e.g., braking, acceleration, steering). A buffer overflow attack could lead to unauthorized access and control and erratic vehicle behavior.
  • In-Vehicle Infotainment Systems (IVI): Infotainment systems need to be safeguarded from heap-based overflow vulnerabilities, which could be exploited to execute arbitrary code and gain access to other vehicle systems.
  • Advanced Driver Assistance Systems (ADAS): ADAS software needs to be protected from stack-based buffer overflows that could alter sensor data or decision-making algorithms, endangering the vehicle’s safety.
  • Connectivity Systems: Connectivity through 4G/5G cellular, bluetooth, wireless CarPlay/Android Auto open the door for memory corruption attacks that can lead to remote access to vehicles.

How to Secure Automotive Embedded Systems and the Software Supply Chain

The need for automotive software supply chain integrity, data security, and automotive safety standards like ISO 26262 and the emerging ISO/SAE 21434 are driving the industry to seek solutions for security and compliance. Here’s where to start.

1. Prioritize Software Bill of Materials (SBOMs) to Evaluate the Software Supply Chain

Software Bill of Materials (SBOMs) are essential tools for demonstrating regulatory compliance, tracking all components, libraries, and modules used in software applications, and enabling quick responses to security concerns. With the proposed bans from the Biden Administration on the horizon, SBOMs will be invaluable for vehicle manufacturers needing to evaluate their software supply chain to ensure they are not incorporating prohibited software. SBOMs provide detailed inventories of software components within a software binary, enabling quick compliance assessments.

2. Secure Embedded Systems from the Ground Up

Secure by Design principles are no longer optional in automotive software development. As vehicles become more  complex and interconnected, retrofitting security measures after development is both costly and ineffective. Following Secure by Design principles will include threat modeling during design phases, implementing secure coding practices, conducting regular security testing, and building in mechanisms for secure updates throughout the software lifecycle.

3.  Adopt Automated Vulnerability Identification and Advanced Code-Hardening Techniques 

Fortifying critical systems against cyber attacks, like braking and steering in an autonomous vehicle, means protecting the millions of lines of code that allow them to function. Automated vulnerability identification and code-hardening protects software against attacks that could compromise vehicle operations and safety while reducing the attack surface.

Specifically, memory relocation techniques prevent memory-based vulnerabilities from being exploited in embedded systems. Known as load-time function randomization, the technique ensures that each instance of the software has a unique memory layout, making it extremely difficult for attackers to predict the location of specific functions, proactively neutralizing common exploit techniques like Return-Oriented Programming (ROP) and buffer overflow attacks.

The Road Ahead: Building Secure and Resilient Vehicles

The increased focus on embedded systems and the automotive software supply chain is a positive one. Ultimately, adopting stronger cybersecurity practices now is an enabler of new vehicle technology, greenlighting innovation and allowing vehicle manufacturers and suppliers to protect their products and customers from the growing landscape of cyber threats.

Learn more about techniques for using SBOM data to track and mitigate security risks in our guide to creating and utilizing SBOMs.

The post Buckle Up: Addressing Embedded Systems Security in the Automotive Software Supply Chain 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.

Challenges and Solutions for OT and ICS to Secure Software Development

Challenges in Securing Critical Embedded Systems and Industrial Control Systems

The Importance of Secure by Design Principles

Strategies for Securing Critical Embedded Systems

Future Trends and Emerging Technologies Protecting CES

Tips to Implement Secure Software Development Measures

Ensuring Critical Embedded Systems Security: Overcoming Challenges in OT and ICS

Challenges and Solutions for OT and ICS to Secure Software Development

In today’s digital landscape, securing critical embedded systems (CES) and industrial control systems (ICS) is imperative, especially for organizations whose technology, if compromised, could have severe consequences. CES, like medical devices and nuclear infrastructure, demand 100% uptime and robust security due to their essential nature. ICS, a subset of CES, regulates industrial processes from manufacturing to power generation.

These systems face unique vulnerabilities, including legacy software and limited resources, making them targets for cyberattacks. Memory-based attacks pose significant threats, potentially causing system failures with catastrophic results.

Secure software development requires a proactive approach that addresses vulnerabilities at the root level. Traditional cybersecurity measures often fall short in this regard, necessitating innovative solutions tailored to the unique requirements of critical embedded systems and ICS.

RunSafe Security offers critical embedded systems security that enhances traditional software security without compromising system performance. Through code hardening and memory protection, RunSafe defends against known and unknown vulnerabilities, safeguarding critical infrastructure and providing robust software supply chain security. 

Challenges in Securing Critical Embedded Systems and Industrial Control Systems

Ensuring the security of all technology is crucial, but CES and ICS face unique challenges. These systems embed software in physical devices, making updates complex and difficult due to the need for uninterrupted performance. Moreover, CES and ICS are deployed across diverse hardware platforms, requiring tailored security approaches.

CES confronts challenges in updating and patching vulnerabilities, often operating in environments where frequent updates are impractical. Performance constraints further limit traditional security measures. The diverse hardware architectures and operating systems add complexity to security efforts, demanding adaptable solutions.

Security breaches in CES and ICS can have dire consequences, affecting various sectors from medical devices to power plants. Breaches could result in data manipulation, operational disruptions, equipment damage, or threats to human safety. The interconnected nature of modern infrastructure amplifies the impact of vulnerabilities, affecting entire supply chains and critical services. Securing these systems demands a comprehensive approach tailored to their unique requirements, emphasizing innovation and adaptability.

The Importance of Secure by Design Principles

In the realm of software supply chain security, the Secure by Design paradigm ensures that the entire organization is aligned in building software that is impeccably planned, designed, tested, and maintained.

This approach entails proactive threat modeling, multi-layered defense mechanisms, vulnerability scanning, and various other strategies to prioritize security and mitigate threats. When developing software for CES or ICS, organizations must integrate security as a critical priority from the outset. This involves implementing best practices to establish safeguards against potential threats, conducting multiple rounds of security-focused testing during the quality assurance phase, and regularly performing threat modeling and vulnerability exercises on released products.

For developers, utilizing a Software Bill of Materials (SBOM) is a valuable practice. An SBOM generates a comprehensive list of all software components and their versions, aiding in the identification of dependencies that may introduce security vulnerabilities. 

RunSafe offers an efficient solution by generating an SBOM and identifying any components that may increase the attack surface of a project. Integrating RunSafe into a developer’s workflow streamlines the process, facilitating proactive security measures and ensuring the resilience of critical systems against cyber threats.

Strategies for Securing Critical Embedded Systems

Critical embedded systems security demands a multifaceted approach to address unique challenges. While human error is inevitable, strategies like automated code hardening and memory corruption prevention mitigate risks. RunSafe’s solution offers memory protection and serves as a Moving Target Defense (MTD), adjusting code structure at runtime to thwart hackers.

Automated code hardening injects unique binary diversification into software builds, protecting against memory-based attacks without system performance impact. Memory corruption prevention disrupts exploitation techniques at runtime, neutralizing threats without impairing functionality.

Supporting diverse platforms streamlines maintenance and updates, while staying updated on evolving threats is crucial. RunSafe’s solutions, compatible with various platforms including LynxOS, VxWorks, and Linux, fortify CES against known and unknown vulnerabilities.

By integrating these strategies and RunSafe’s technologies, organizations enhance CES security, safeguarding critical systems against cyber threats and ensuring uninterrupted operations.

Future Trends and Emerging Technologies Protecting CES

In the realm of cybersecurity, upcoming trends and emerging technologies are poised to revolutionize the protection of CES. One significant trend is the integration of artificial intelligence (AI) into security solutions, enabling real-time threat detection and response through advanced data analysis.

Moreover, the proliferation of Internet of Things (IoT) devices in critical infrastructure introduces both challenges and opportunities. While expanding the attack surface, IoT integration also presents avenues for innovative security measures, including device-level encryption and authentication protocols.

Tips to Implement Secure Software Development Measures

For organizations aiming to bolster their software supply chain security, implementing secure software development measures is paramount. Below are some practical recommendations:

• Adopt a Secure by Design approach: Integrate security considerations into every stage of the software development lifecycle, prioritizing security from design to deployment.
• Implement automated code hardening: Leverage tools like RunSafe’s automated code hardening solution to fortify software against memory-based attacks without compromising performance.
• Conduct regular vulnerability assessments: Perform comprehensive vulnerability scans and audits to identify and address potential weaknesses in CES and ICS environments.
• Ensure diverse platform support: Support a variety of hardware platforms and operating systems to facilitate easier maintenance and updates across environments.
• Stay informed about emerging threats: Keep abreast of evolving cybersecurity threats and trends, and continuously update security measures to adapt to changing landscapes.
• Integrate RunSafe Protect: Utilize RunSafe Protect to streamline software security processes, automate cybersecurity measures, and seamlessly integrate security into developers’ workflows.

By implementing these practical recommendations, organizations can significantly improve the security posture of their critical systems, safeguarding mission-critical infrastructure against cyber threats.

The post Ensuring Critical Embedded Systems Security: Overcoming Challenges in OT and ICS appeared first on RunSafe Security.

New Survey Results: Cyber Decision Makers Are Unaware about the State of Firmware Security

Are Cyber Risk Decision Makers Truly Informed?

What Tools Are Available to Fill Cyber Knowledge Gaps?

The software world continues to undergo dramatic change. From digital transformation to devops and shift left, organizations are re-inventing their software development lifecycle processes with an eye for automation and agile or continuous practices.

With that said, understanding risk across your software infrastructure includes understanding the supply chain in detail.  Most organizations are still struggling to secure the embedded firmware their devices and supply chains rely upon, leaving themselves extremely vulnerable. 

Are Cyber Risk Decision Makers Truly Informed?

Eclypsium conducted a survey to determine how much cyber risk decision makers in financial services companies know (or don’t know) about the state of firmware security in their device fleet and supply chains. 

Eclypsium surveyed a total of 350 IT security DM respondents, from organizations with a minimum of 1,000 employees in May 2022. The respondents originated from a variety of locations, including the US (150), Canada (50), Singapore (50), Australia and New Zealand (50) and Malaysia (50). All respondents were from organizations in the financial services sector.

Key Findings

• 76% of IT security decision makers (DMs) in the finance industry have gaps in their awareness concerning their organization’s firmware blind spot.
• 91% are concerned about the gap in firmware security in their organization’s digital supply chains.
• 92% admit that cyber criminals are better equipped to attack firmware than their organization is at protecting it.
• 88% are aware that their organization has been the victim of a firmware- level attack in the last two years.
• 93% of IT security DMs are surprised by the lack of insight into current firmware threats.

What Tools Are Available to Fill Cyber Knowledge Gaps?

RunSafe Security protects firmware for several organizations and specializes in reducing risk across your software supply chain—whether open source, third party, or proprietary code. See what RunSafe’s product lineups can do for you with a hassle-free trial.

The post New Survey Results: Cyber Decision Makers Are Unaware about the State of Firmware Security appeared first on RunSafe Security.

• Greg Kurtzer, CEO of Ctrl IQ, original CentOS author, and founder and creator of Rocky Linux, a community-driven effort to offer enterprise-grade, production-ready Linux
• Brad LaPorte, former analyst at Gartner, a technology research and consulting company
• Doug Britton, CTO of RunSafe Security, a solution that immunizes software from cyber attacks and disrupts bad actor economics without developer friction

Linux Open Source Software Evolutions Can Leave You Vulnerable

Linux is a prevalent component of nearly every workload: more than 90% of cloud workloads and 70% of web servers run on it. Like all technology solutions, Linux has continued to evolve over time, potentially opening you up to new cyber security threats. Bad actors often have an advantage because they are working against known security measures and the cloud has made it easier to share information on successful entry points. That means it’s vital you stay on top of known and potential vulnerabilities.

LaPorte offered some sobering data when commenting on how the security landscape has changed:

• Malware families alone have grown 40% year over year since 2019 and 500% over the past decade.
• The IBM Exforce Threat Intelligence Index shows exploits are now the main attack vector, bumping phishing from its decade-long run as the #1 entry point.
• Somewhere in the past 30+ years, Linux went from “secure by default” to showing up in the breadcrumbs of more than 90% of software security breaches.

Despite the obvious rise in bad actors exploiting vulnerabilities in Linux operating systems, the increase can’t be chalked up to any brand new techniques—buffer overflows are still the biggest threat. What has changed, according to Kurtzer, is the sheer scope of this popular open source software, which leads to additional entry points and increased risk. Containers compound these vulnerabilities, allowing user spaces to be packed up and moved around independently of the core operating system.

According to Kurtzer, two big container missteps that can reduce security are: not having good provenance that allows you to see where the containers come from, and the byte rot associated with continuous deployment without management, updates, or visibility.

With Linux driving more workloads that run the cloud, it’s important to remember that the same types of attacks work across containers, cloud-based systems, and physical servers. As Kurtzer noted, the cloud often provides a double threat to security, making cyber security attacks more effective and easier to scale while simultaneously making the job of effectively monitoring and managing entry points more difficult.

Addressing Vulnerabilities in Open Source Software

Risk is directly related to how much visibility you have into the depths of your software. The nature of open source software means people not employed by you or your company have the ability to submit code, which in turn means you could be blind to risks contained within it. Put plainly, what you don’t know can hurt you.

Distilling down to the essentials, Britton offered two key questions that can help determine your level of risk:

• Do you have a complete bill of materials for your software, including open source? Being able to see and explain the purpose of every piece of code in all of your software helps you lay the foundation for understanding and mitigating vulnerabilities.
• Do you have visibility into the kind of malicious activity each type of code is vulnerable to? The web app on top of the stack might be the easiest to notice, but the compiled code and aspects of an operating system that exist underneath it constitute latent risks.

These questions get to the heart of why visibility is so vital—because bad actors are always trying to get one level below where your software security efforts are located. That means that attacks are progressively moving farther down the stack while a lot of focus has been on the surface level like antivirus protection, multi-factor identification, and Linux-based solutions for endpoint protection.

LaPorte noted that most industry solutions are almost the inverse of how software security should work. He and Britton both agreed that traditional security methods have huge gaps and the focus should be on hardening the software to prevent changes and stop attacks at the code level.

“Too many times, we’ve seen people think that because they’ve tied off one layer that vulnerabilities elsewhere in the stack just don’t matter,” said Britton. “And what I think that history has shown us that it’s a bit of a naive assumption because bad actors are good at taking your assumptions and turning them on their ear. Being able to provide that hardening for everything that is in memory is essential.”

RunSafe Builds in Software Security from the Bottom Up

RunSafe Security’s patented Alkemist technology helps secure software during the build, leveraging both Moving Target Defense (MTD) and Runtime Application Self-Protection (RASP) techniques to prevent bad actors from weaponizing vulnerabilities. According to both Kurtzer and Britton, MTD models are proving to be incredibly helpful in mitigating buffering overflow attacks by removing predictability. RunSafe Security and CIQ have teamed up to integrate RunSafe’s Alkemist:Code technology within CIQ’s platform.

Now, cyber hardening technologies offered by Alkemist:Code are available to Rocky Linux users with no extra effort. The virtually unbreakable code won’t slow down development or runtime speeds and offers new ways to leverage containers for security. By adding RunSafe’s Alkemist: Code into a build, Rocky Linux users effectively bake in the most advanced cybersecurity protection tools that will move with that container wherever it goes.

In addition, access to the mighty but easy-to-use Alkemist: Code means that Rocky Linux users can take advantage of protections while maintaining accessibility for those who don’t have decades of expertise in open source software security, making it a truly turnkey solution that mitigates vulnerabilities from the bottom up.

As the Linux landscape evolves, software security is getting harder. Learn from expert panelists how you can identify software security vulnerabilities and implement security protections, in this webinar.

FAQ:

How has the security landscape changed?

• Malware families alone have grown 40% year over year since 2019 and 500% over the past decade.
• The IBM Exforce Threat Intelligence Index shows exploits are now the main attack vector, bumping phishing from its decade-long run as the #1 entry point.
• Somewhere in the past 30+ years, Linux went from “secure by default” to showing up in the breadcrumbs of more than 90% of software security breaches.

How do you determine your level of risk?

• Do you have a complete bill of materials for your software, including open source? Being able to see and explain the purpose of every piece of code in all of your software helps you lay the foundation for understanding and mitigating vulnerabilities.
• Do you have visibility into the kind of malicious activity each type of code is vulnerable to? The web app on top of the stack might be the easiest to notice, but the compiled code and aspects of an operating system that exist underneath it constitute latent risks.

How can you easily prevent software vulnerabilities?

Now, cyber hardening technologies offered by Alkemist:Code are available to Rocky Linux users with no extra effort. The virtually unbreakable code won’t slow down development or runtime speeds and offers new ways to leverage containers for security. By adding RunSafe’s Alkemist: Code into a build, Rocky Linux users effectively bake in the most advanced cybersecurity protection tools that will move with that container wherever it goes.

The post Prioritizing Software Security in the Changing Linux Landscape appeared first on RunSafe Security.

Just last year, CWT Global set a world record for the largest ransom ever paid by surrendering $4.5 million in bitcoin to the Ragnar Locker ransomware gang. More recently, Colonial Pipeline comes in second, with paying $4.4 million to their attackers in May of 2021.

Consumers are seeing the effects of these attacks play into their daily lives, as the Colonial Pipeline incident caused a week-long disruption to the East Coast’s gasoline supply.

This won’t be an uncommon occurrence. What’s coming next? Jackware.

There is a rapidly-growing risk of “jackware”, a type of ransomware that takes over the physical devices and machines that we use in our modern, everyday lives. And as hard as it may be to imagine, this new breed of ransomware could be 10 times more dangerous than the current threat of ransomware we face today.

How Jackware Disrupts Embedded Devices

Malware hijacks computers. But in today’s world, there are tiny computers placed into every type of machine and device that the general public uses, both personally and professionally, adding connectivity and “smart” features to our everyday technologies. These are called “embedded devices.”

They may be tiny, but their role in critical infrastructure is massive. Embedded devices are the drivers behind the operating systems for cars, health care, corporate enterprises, mass transit, home life, and much more. Since they function similarly to traditional computers, they’re just as vulnerable to malware attacks—known as the infamous jackware.

The part about jackware that makes it so devastating? It has direct, physical effects and consequences when placed into action. The cyber threat has the ability to completely shut down embedded devices, putting larger physical systems (that we heavily rely on) to a complete and immediate halt. The supply chain disruption we’ve recently experienced due to ransomware is just the beginning—permanent damage to our operating systems, our wellbeing, and disruptions in essential services are all on the line.

The Journey of Jackware isn’t Just Beginning

There are a vast number of ways that this type of cyber threat can disrupt our lives, and it’s actually been happening for several years. For example, jackware can literally stop cars in their tracks by hijacking their operating systems and accessing their brakes, or do this with the planes, trains, and the subway you take to work. This story is written by the person who was driving a hijacked car in 2015.

Ukraine experienced an attack on their power grid a few years ago through a physical malware attack. This undeniably has far-reaching effects, but even small substation attacks within the industry’s facilities could trigger a fire or explosion, causing danger in multiple ways.

An attacker could infiltrate the operating system for medical devices in a hospital, putting patients’ lives at risk. It’s known that between 10-15 connected devices are at each hospital bed. Pacemakers, insulin pumps, and drug infusion pumps are some of the most susceptible devices to attack.

In 2011, an attacker named Jay Radcliffe hacked his own implantable insulin pump to demonstrate the ease of doing so. He found it was a simple task to take over control and deliver a lethal dose to a patient. Later, Radcliffe discovered the same ease in delivering a lethal electric shock through a hacked pacemaker. Same story goes for drug infusion pumps and delivering fatal doses to patients.

Moral of the story—the danger of this type of ransomware is insurmountable and, unfortunately, at large.

A Proactive Approach We All Need to Implement

This blog isn’t all bad news, though. We have to understand the true volume of the problem to deliver the best solution. We’d like to introduce you to RunSafe’s Alkemist technology.

It’s more important than ever to move to a proactive approach rather than a reactive one. Manufacturers are continuously looking for ways of manufacturing devices with security already built-in to defend against threats such as jackware.

Alkemist rapidly immunizes the software within embedded devices without changing source code. This immediately reduces the IoT (Internet of Things) attack surface (which, by the way, holds the title for the greatest attack surface expansion our world has seen) without depending on lengthy patching timelines for when an attack occurs.

For new embedded device creation, the Alkemist cyber immunization technology is directly embedded into the build process with native Yocto and embedded Linux implementations, reducing zero-day vulnerabilities and protecting manufacturers from liability in the case of a successful jackware attack.

The advantages of this type of protection include:

• Immediately protect existing devices
• Deploy remotely at scale
• Native Yocto toolchain integration
• Easily deployed
• Zero runtime penalty, minimal footprint

It’s the solution we’ve needed for years, and it’s finally time to put it to work. Today’s attackers aren’t in the mood to wait. To see how the technology works in action, schedule a free trial of RunSafe’s Alkemist today.

The post An Embedded Devices “Doomsday” is Upon Us: How to Prevent Jackware appeared first on RunSafe Security.

Current technologies exist to help in finding vulnerabilities, but unfortunately, they’re not sufficient. Here are the problems we’re facing:

• Software is passing scanning tests while the technology is missing 50% of present vulnerabilities and weaknesses in code
• Runtime app monitoring technology misses deep indicators of lurking threats
• Heartbeat checks aren’t reliably reporting system performance and stability
• Low-level activity is sneaking by, undetected, and causing disruptions in service
• There is an increasing dependence on open source packages, but organizations don’t have a way of mitigating the vulnerabilities that threaten infrastructure

Have you ever wondered how exposed your systems are to vulnerabilities?

What’s needed is a way of reliably and accurately monitoring the health and stability of systems at runtime so that you can flag failures or potential attacks before a disruption of service occurs.

How the Technology Works

Our team at RunSafe Security set out to make indicators of instability and unreliability visible at runtime that most technologies miss today.

And so, Alkemist:Flare came to be. Like a signal flare, Alkemist:Flare delivers a bright, real-time indicator of application failures related to cyber attacks and software weaknesses, capturing at runtime what scanning tools don’t identify at testing time.

Now, IT managers, security operations, and development teams can see events that are causing system reliability issues, performance degradation, service availability risk, and attack vectors that lead to disruption in service. Users receive alerts identifying process instability and vulnerability indicators, providing the opportunity to fix code weaknesses, report vulnerabilities to software vendors, build additional layers of protection, and share telemetry data to security operations for automated responses or detailed research.

Alkemist:Flare delivers continuous monitoring of:

• Cloud workloads
• Software applications
• Open source packages
• IT/OT infrastructure
• Endpoint devices
• Embedded systems

Who’s Using Security Monitoring?

Across all industries, the first step in preventing service disruption is being instantly aware of vulnerabilities within software. Here are a few ways that different organizations have used vulnerability monitoring to improve their operations:

For a FinTech SaaS company, it’s imperative to protect sensitive customer data—not just for compliance, but for reputation purposes. The organization implemented reliable monitoring technology to enhance their ability to identify vulnerabilities before they became problems.

An embedded software provider in the energy space needs to monitor its distributed energy resources to ensure bad actors aren’t exploiting existing vulnerabilities in the software. By using technology that accurately indicates stability while instantly flagging failure and potential attacks, they are able to trust their distributed energy resources are healthy.

To ensure their customers’ open source software was not being exploited, a managed services security provider combined cyberhardening tools with monitoring technology. The team was able to increase the speed and effectiveness of their response if an attack did occur by knowing about it immediately.

Applying Reliable Monitoring to Higher Business Objectives

Alkemist:Flare captures runtime application failures and alerts your team members, so you’re able to monitor the overall stability and reliability of your systems at runtime, and increase the speed and effectiveness of your cyber attack response.

Are you aware of all of your vulnerabilities? Get a free 30-day analysis of your software with Alkemist:Flare today.

The report includes:

• An assessment of the stability and reliability of the software across your systems
• A prioritization of vendors or open source packages that could put your infrastructure at risk
• Recommendations on how to mitigate exposure to cyber attack for your most vulnerable software

The post How to Harness the Power of Software Security Monitoring appeared first on RunSafe Security.

Automated run-time protections are crucial for cyber defense that scales. Protecting critical infrastructure is too vast an undertaking for human-based monitoring and response alone. As an example, there are approximately 54,000 drinking water systems in the United States, and many do not have someone watching IT operations 24/7 as KrebsOnSecurity reports.

The Ubiquitous Buffer Overflow Vulnerability

Some of my colleagues at RunSafe used to be secret agents—well, modern-day ones, in that they were on the cyberattack side for the U.S. Government. They spent a long time preparing and searching software for vulnerabilities. Ultimately, they crafted sophisticated attacks in the form of cyber kill chains (as defined by Lockheed Martin), running from reconnaissance through actions on objectives.

One of their go-to techniques was the exploitation of a memory corruption vulnerability, such as stack overflow, heap overflow, and use-after-free. Most of the time their cyber kill chains included these exploits.

Why the popularity of memory exploitation? Is it because they had access to classified tools and they’re super smart? Well, they did and they are, but that’s not the reason. In fact, memory corruption vulnerabilities are ubiquitous, persistent, and exploitable for remote code execution. Here are three pieces of evidence:

1. Google reported in February of 2021: 70% of security updates for Google’s Chrome database and Microsoft products relate to memory corruption vulnerabilities.
2. CVE database showed in the summer of 2020: 40% of the published CVEs for the studied C/C++ projects are related to memory.
3. Armis discovered in July of 2019: 55% of the 11 zero-day vulnerabilities in VxWorks®, used by over 2 billion devices including critical industrial, medical, and enterprise devices, are classified as critical and enable Remote Code Execution (RCE).

The Power of DevOps in Embedded Systems

DevOps is bringing a cultural and technological shift to software development. The goal is a holistic team, including developers and operators, using automated tools to achieve CI/CD (continuous integration and continuous delivery). It recognizes that software is never done, should not be created by developers working in a vacuum, and requires constant iteration.

The U.S. Department of Defense has a powerful DevOps initiative called PlatformOne. It’s about cultural change, which in the case of the DoD, includes a change to acquisition policy. It’s about technology, having a unified technology stack as key to modularity, and avoiding vendor lock.

Ultimately, it’s about speed, with one of its ambitious goals being to update the operational flight program (OFP) on an in-flight fighter jet. This agility is not for show, but necessary given peer adversaries.

Many have expanded DevOps to DevSecOps, indicating cybersecurity is part of this holistic, iterative, automated approach. That’s a great goal. Unfortunately, traditional cybersecurity practices are not a good fit. Static scanning is a standard tool for cybersecurity, although it is known to be woefully incomplete in its ability to identify errors. More damaging in the DevOps context, the practice undermines the team culture by pointing a finger at the developers, while cybersecurity is still on the outside.

Equally important, scanning undermines important automation and speed objectives. Scanning generates alerts that software developers must address or ignore. This find and fix approach takes valuable time for an incomplete solution. Scanning is not like the handy spell check I’m using rigt now…I mean right now.

How Can RunSafe Help with Your Embedded Devices?

Remember my colleagues who used to be secret agents? At RunSafe, they’ve switched to cyber defense using their spooky experience. I’ve seen this dynamic before in electronic warfare. The best electronic protection (defense) experts began as electronic attack experts.

First, they break adversary stuff, then they defend our stuff. Attack gets more attention, just like offense in sports (touchdowns, goals, baskets), but it’s often defense that delivers the win.

RunSafe takes a new approach to cyber defense to ensure critical infrastructure keeps operating through attacks, using sophisticated automation and mitigation, rather than brute force find and fix. RunSafe design tenets are: do no harm to the original software, be scalable, be widely applicable. As a result, RunSafe’s cyber defense is tightly aligned with the DevOps movement and the reality of the constant attack.

Our defense software integrates easily into a DevOps CI/CD toolchain. Software developers set flags in their compilation process to make a call to our software. That’s it—done. DevOps culture and speed are enhanced. Security is embedded into the process rather than criticizing from the outside.

RunSafe’s approach means embedded systems are protected against both known and unknown, yet-to-be-exploited vulnerabilities. The benefit is mitigation of memory corruption vulnerabilities, those ubiquitous vulnerabilities comprising 40-70% of identified vulnerabilities, depending on the code stack. Mitigation happens automatically at run-time when embedded devices are under constant attack, ensuring the smooth operation of critical infrastructure.

To learn more about the superpower next-level technology, read our whitepaper today: RunSafe Security and Memory Threats: Using Alkemist® to Fight the Exponential Growth in Memory Vulnerabilities and Immunize Software from Attacks.

The post Embedded Systems Need Embedded Security appeared first on RunSafe Security.

RunSafe is in the business of helping developers – and the organizations that employ them – to reduce risk. A key part of purpose is making sure our customers have the right tools that work in an optimal way, which can vary by use-case.

There is a whole universe of memory-based attacks like stack, heap, buffer and a myriad of other types of overflow and memory abuse attacks that can be potential attack vectors. At RunSafe, our technology limits risk by not enabling attackers to weaponize memory bugs, even as those memory bugs continue to exist in the underlying software.

Among the many environments where RunSafe supports customers is in Yocto build environments, which are commonly used in the embedded space.  The Yocto Project is run by the Linux Foundation and is an open source effort that has found increasingly broad adoption. 

With our Alkemist:Source product, RunSafe provides load time function randomization (LFR) capabilities. It’s a security feature that can be added to compiled binaries, such that whenever the binary is loaded, it randomizes memory allocation and prevents certain types of attacks. RunSafe has a delivery model that enables the easy integration of the LFR into the Yocto build process, so that when you get your image at the end of the Yocto build, it has built-in protection.

With Yocto and  Alkemist:Source,  every time you boot your device, every time applications load, they look different to an attacker.  And no, this isn’t theoretical – it’s a simple 5 minutes process (we’ve outlined the process in a previous blog post – )

The Yocto Resource Utilization Challenge

We have many customers that use Alkemist: Source for one or two binaries. With Yocto, it’s not just one or two binaries that are being protected, it’s everything in the system and full image protection. 

When dealing with embedded devices that have limited resources, there can be different challenges than running a single binary that needs to be protected on a big server. That’s what happened with one of our customers that deployed Alkemist:Source for a Yocto build project on a resource constrained device.

What the organization found is when their image was built with LFR enabled, there was a measurable performance hit on startup; and, applications were taking longer to load than what they wanted. Now in this case, our customer had a really heavy startup procedure, which is not always the case for most embedded devices, so they were running on a slow processor.

We knew we had to come up with a solution to this problem. That’s where the caching daemon comes into the picture.

How the Caching Daemon Works

With Alkemist: Source, when a binary is loaded into memory it’s randomized.  With a shared library that creates some additional resource utilization. What happens is the randomization is actually a copy of that shared library existing in memory, because there’s a copy-on-write protection for the shared library.

So what in effect occurs is when the shared library loads, RunSafe randomizes it and it then copies it to a new memory location. So if 10 different applications are all using that shared library, they end up making 10 copies and randomizing it 10 different times. That leads to some memory bloat and can lead to a potential performance hit, especially on resource constrained devices, like the Yocto example that our customer was using.

The solution we came up with at RunSafe is to minimize the shared library memory randomization hit is the caching daemon. With the caching daemon, there is only one copy of the shared library that is randomized in memory. The one randomized copy in turn is used by all the other binaries that might link to the shared library.

Basically we keep a record of things in memory. Rather than re-randomize when we see a given shared object used again, we pass the location of that shared object already in memory for re-use.

Technical Details on Caching Daemon

RunSafe has a provisional patent on the caching daemon as it introduces a number of unique innovations. We took great pains to secure the daemon itself writing it in the open source Rust programming language, which has its own built-in security feature and is considered to be typesafe.

LFR Library Caching consists of two major components: a new cache daemon that keeps memory mappings for each loaded library and enforces security policy, and the existing libLFR, modified to communicate with the cache daemon. 

The cache daemon is responsible for caching code randomized by LFR. Before libLFR randomizes a library in a client process, it asks the daemon for a cached copy. If the daemon has a cached copy, it sends the file descriptor and additional relocation metadata for that library to the client process. 

To control the resource usage of the cache daemon and avoid caching libraries that are no longer in use, the daemon will have a tunable maximum cache size, specified in memory size or number of libraries. The daemon will evict libraries from the cache using a least recently used (LRU) strategy, so that frequently used libraries always stay in cache, as long as there is space. When the daemon evicts a library from the cache it will close the file descriptor. The kernel will then free the memory when the last process with that file mapped exits (or unloads the library).

Memory Safety that Respect Performance Demands

There is no shortage of academic research about how to limit the risks of memory attacks. While research is all fine and good, with Alkemist:Source, RunSafe is able to help organizations implement memory security in a practical way.

We have moved from just solving the first challenge of helping to mitigate memory risks, to help our customers with deeper underlying issues of performance and how we impact minimal resource systems.

You can have performance and you can have security.

RunSafe provides a simple and seamless option to completely eliminate zero-day and other memory-based vulnerabilities, without patching, for yocto developers. With a 5-minute one-time implementation into the native yocto build stage, RunSafe’s Alkemist technology immunizes binaries from memory attacks, so that every image is functionally identical but logically unique. This changes hacker economics back in favor of the manufacturers and users of embedded devices.

You can get started today by registering at alkemist.runsafesecurity.com.

The post The Devil in the Details: How The Caching Daemon Keeps Our Yocto Customers Running Safe appeared first on RunSafe Security.