As software supply chains grow in complexity and ICS devices take on more digital functionality, operators face risk from vulnerabilities buried deep within firmware, dependencies, and proprietary code. Strengthening security and demonstrating compliance begins with improving the integrity, transparency, and resilience of that software. 

RunSafe helps industrial organizations achieve this by hardening code against exploitation, increasing visibility into software components through build-time Software Bill of Materials (SBOM) generation, and extending protection to systems that can’t easily be patched or rebuilt. 

These capabilities align directly with the technical controls required across major ICS cybersecurity standards, helping operators close gaps in their security posture.

Listen to the Audio Overview

Key ICS Cybersecurity Standards RunSafe Supports

IEC 62443 Security Requirements

IEC 62443 defines security levels (SL-1 to SL-4) to counter cyber threats to ICS systems. Security Requirement 3.4 requires mechanisms to ensure software and information integrity by detecting and preventing unauthorized modifications, which is essential for defending against zero-day exploits. 

RunSafe Security supports this with runtime code protection and automated defenses that maintain software trustworthiness in ICS devices, aligning with these IEC 62443 integrity requirements.

NIST 800-82 Control Families

NIST SP 800-82 is a specialized guidance document focused on Industrial Control Systems (ICS) and Operational Technology (OT) environments. It defines 19 control families tailored to these unique contexts, addressing operational, technical, and management controls relevant to ICS security. 

RunSafe’s Protect solution assists in meeting NIST standards by hardening software across firmware, applications, and operating systems to reduce vulnerabilities, especially memory-based and zero-day threats. This aligns with minimizing risks outlined in NIST 800-82, such as unauthorized modifications, malware infections, and system exploitation.

NERC CIP standards

NERC CIP applies to bulk electric systems and mandates stringent access control, security monitoring, and incident response to protect critical grid infrastructure.

RunSafe’s automated software hardening strengthens embedded software against vulnerabilities, including zero-day attacks, helping to meet NERC CIP mandates for cybersecurity system management and reducing the attack surface of BES Cyber Systems.

EU Cyber Resilience Act

The EU Cyber Resilience Act imposes mandatory cybersecurity requirements on manufacturers placing products with digital elements into the European market. The regulation requires comprehensive SBOM documentation, vulnerability disclosure processes, and Security by Design principles throughout the product lifecycle.

RunSafe empowers organizations to meet EU CRA requirements through automated build-time SBOM generation, embedded software hardening, and proactive vulnerability identification.

UK’s Cybersecurity and Resilience Bill

The UK’s proposed legislation extends cybersecurity obligations across critical national infrastructure sectors. The bill emphasizes supply chain security and mandates incident reporting within strict timeframes, creating accountability for operators and vendors. 

RunSafe Security supports compliance with the UK Cybersecurity and Resilience Bill by providing embedded software security designed specifically for ICS systems and software supply chain transparency through build-time SBOM generation.

How RunSafe Hardens Code & Strengthens the Software Supply Chain to Meet ICS Security Standards

RunSafe improves ICS security posture by providing:

1. Build-Time SBOM Generation: Provides complete visibility into software components and software supply chain risk, especially for C/C++ and embedded toolchains.
2. Runtime Code Protection: Protects ICS devices in the field, even before patches are available, by preventing the exploitation of memory-based vulnerabilities, including zero-day exploits.

Together, these capabilities directly support key ICS cybersecurity requirements.

The Industrial Control System Software Risk Landscape

ICS cybersecurity risks increasingly stem from software complexity. PLCs, HMIs, sensors, gateways, and controllers rely on layered stacks of compiled code, RTOS kernels, communication libraries, protocol implementations, and third-party components. As this software ecosystem expands, several categories of risk emerge:

1. Vulnerabilities in Proprietary and Third-Party Components

Industrial devices often incorporate dozens or hundreds of software elements, both internally developed and externally sourced. Many of these components lack update mechanisms or clear lifecycle management. When vulnerabilities are disclosed, asset owners frequently lack the visibility needed to determine whether their systems are exposed.

2. Memory Safety Issues as a Persistent ICS Threat

Memory safety remains one of the most common contributors to ICS vulnerabilities. Buffer overflows, use-after-free flaws, and out-of-bounds writes still account for a significant portion of CVEs in industrial and embedded software. These weaknesses persist in critical infrastructure because:

• Many devices use older programming languages (e.g., C/C++)
• Patching may be infeasible due to uptime requirements
• Legacy firmware often cannot be rebuilt or re-verified
• Third-party components introduce memory safety risks through the software supply chain.

Andy Kling, VP of Cybersecurity at Schneider Electric, a major player in the ICS/OT space, found that “memory safety was easily the largest percentage of recorded security issues that we had.” 94% of these weaknesses come from third-party components.

While memory safety is not the only category of ICS risk, it remains one of the most damaging, often enabling remote code execution or multi-stage exploit chains.

3. Software Supply Chain Blind Spots

Software supply chain cyberattacks frequently target the software dependencies and build environments behind industrial products. Without reliable SBOMs, operators cannot:

• Determine which libraries exist in a given binary
• Rapidly assess exposure to new vulnerabilities
• Confidently evaluate vendor-supplied code or firmware

The lack of software transparency turns compliance into guesswork and slows incident response.

4. Operational Constraints That Block Traditional Security Measures

Industrial environments face major deployment challenges:

• Air-gapped or intermittently connected networks
• Decades-old firmware with no vendor support
• Real-time performance requirements that limit scanning or patching
• Multi-vendor PLC fleets with inconsistent update workflows

These realities make it difficult to rely solely on patch management, network segmentation, or perimeter defenses.

5. Physical and Operational Consequences

Because ICS software interacts directly with physical equipment, software vulnerabilities can lead to:

• Manipulation of process parameters
• Shutdown of production lines
• Damage to equipment or the environment
• Safety incidents impacting human operators

Software risk in ICS is therefore both digital and physical, with potentially severe outcomes.

Three Steps to Deploy RunSafe in Existing ICS Security Programs

Given the depth of software risk in modern ICS environments, organizations need solutions that both reduce exploitability and produce the evidence required for rising compliance standards. 

RunSafe delivers this by integrating directly into existing development and maintenance workflows, making it possible to improve security posture without operational disruption.

1. Integrate & Automate SBOM Generation at Build Time

Begin by embedding RunSafe’s SBOM generation directly into your CI/CD pipeline or offline build environment. Whether you’re working with embedded Linux, Yocto/Buildroot builds, or legacy RTOS toolchains, RunSafe’s Identify capability produces CycloneDX-compliant SBOMs and supports all mandatory NTIA fields.

You’ll gain full component visibility—down to libraries, files, and versions, including proprietary components—so you can quickly assess exposure, audit supplier code, enforce license policy, and meet SBOM-mandate requirements for ICS environments.

2. Apply Binary Hardening and Runtime Protection

Protecting your software with RunSafe Protect is as easy as installing the packages from our repositories and making a one-line change to your build environment. Once installed, you can automatically integrate Protect into your existing build process.

RunSafe Protect hardens compiled binaries against memory-based exploits and zero-day attacks by applying Load-time Function Randomization (LFR). Even legacy PLC firmware, vendor-supplied binaries, or devices in air-gapped networks can benefit from exploit mitigation. Because the protection works independently of patch status, you’re reducing risk proactively while maintaining operational continuity.

3. Monitor Protected Devices

Deploy RunSafe’s Monitor capability across your hardened device fleet to capture crash indicators, detect unusual behavior patterns, and differentiate between benign failures and potential exploit attempts.

Next Steps to Secure Your ICS Environment

Securing industrial control systems requires more than perimeter defenses or periodic patch cycles. It demands protections that operate inside the software itself—across legacy devices, modern embedded platforms, and complex software supply chains. 

RunSafe provides that foundation by hardening binaries against exploitation, generating accurate SBOMs at build time, and delivering operational insight through lightweight monitoring. Together, these capabilities give ICS operators a practical path to strengthen system integrity, reduce exploitability, and demonstrate compliance with the world’s most important cybersecurity standards. 

With the right protections applied directly to the software running your critical processes, resilience becomes achievable rather than aspirational.

Request a consultation to get started with RunSafe or to assess your embedded software security and risk reduction opportunities.

The post Meeting ICS Cybersecurity Standards With RunSafe appeared first on RunSafe Security.

Embedded engineering teams are aware of the risks and looking for tooling that surfaces license risk early in the development pipeline. RunSafe’s license compliance feature addresses this need by detecting licenses in your code and enforcing your organization’s risk profile to prevent the release of affected code. Teams can ship faster, with the permissions they’ve set, and without risking IP.

Listen to the Audio Overview

Why License Compliance Is Harder for Embedded Systems

Software license compliance means following the legal terms attached to every piece of code in your product, including proprietary, open source, or vendor-supplied. When you ship a device with firmware or deploy a software update, you’re accepting the obligations tied to every component inside. 

Embedded teams face unique challenges:

• Heavy static linking: Increases likelihood of triggering copyleft obligations
• Long device lifecycles (10–20 yrs): Mistakes persist for years and can’t be easily fixed
• Mixed vendor + OSS inputs: Hard to track attribution and inheritance
• No package manifests in C/C++: License detection becomes manual and error-prone

How Copyleft Licenses Raise Compliance Stakes

Copyleft is a licensing approach that uses copyright law to keep software open. If you distribute a program containing copyleft-licensed code, you’re typically required to release your modifications—and sometimes related components—under the same copyleft license. That reciprocal obligation separates copyleft from permissive licenses.

If a copyleft license is violated,  the potential implications include:

• Mandatory source code disclosure: Courts can order you to release not just the copyleft component but also your modifications, build scripts, and sometimes the proprietary code you linked against.
• Increased risk of exploitation once code is public: Once your source code is released, it makes it easier for malicious actors to analyze and exploit any latent vulnerabilities. Embedded devices are already at risk, the last thing teams want is to accelerate exploit development. (While the goal is to prevent reaching this point through license compliance, if a team finds itself in this situation, RunSafe Protect hardens binaries against exploitation, even when source code is exposed.)
• Legal action and settlements: License holders can seek injunctions to halt product sales, plus damages and legal fees that quickly reach six or seven figures.
• Product recall costs: Fixing a license violation after devices ship may require firmware updates, replacement units, or new packaging with proper notices.
• Reputation damage: In regulated industries like medical devices or defense, license violations signal weak governance and can disqualify you from contracts.
• Supply chain disruption: Customers may freeze orders until you demonstrate compliance, and certification bodies may suspend approvals.

The longer violations exist in shipped products, the more devices are affected and the harder remediation becomes.

How Does Copyleft Happen? A Common Scenario

1. A developer adds a library to meet a deadline
2. The project statically links against a GPL component
3. No manifest exists or an SBOM lacks the detail needed for tooling to flag the risk
4. Firmware ships
5. A customer, auditor, or regulator requests the SBOM
6. Legal discovers the violation, and remediation becomes painful and expensive

Without an accurate SBOM and automated license enforcement, it’s difficult to stop copyleft from entering your codebase. That’s why embedded teams need RunSafe’s file-level SBOMs and license compliance, which surface licenses early and then allow you to block or approve them before release based on your specific risk profile.

How RunSafe Improves License Compliance and Addresses Copyleft Risk

RunSafe’s license compliance feature gives embedded teams control over licenses to prevent violations before code ships. We combine build-time Software Bill of Materials (SBOM) generation with automated policy enforcement to simplify and standardize the process.

Step 1: Set Your Organization’s License Rules

RunSafe lets you define clear licensing policies across your entire organization, and will be adding support for project-level license compliance to allow for more granularity and flexibility in how you configure your rules. Specify which licenses are approved, which are banned, and which require review. Whether you need to block GPL variants, flag AGPL dependencies, or restrict any copyleft terms, RunSafe allows you to set rules that make sense for your organization.

In the RunSafe Security Platform, you’ll see a list of all the licenses in your software detected by RunSafe’s build-time SBOM generator. You can also view a list of common open-source licenses and choose which to allow or deny. By defaulting to the licenses actually present in your software’s SBOM, your organization can focus on dependencies in use without getting bogged down by unnecessary compliance reviews.

Step 2: Choose Your Enforcement Posture for New Licenses

This is where RunSafe balances control with practicality. For any license you haven’t explicitly classified (unset licenses), you choose one of two approaches:

Allow by default: New dependencies flow through automatically unless they match your explicitly denied list. This keeps development moving while blocking known copyleft risks.

Deny by default: Any unrecognized license halts the pipeline until you review and approve it. This guarded posture ensures maximum protection as your dependencies evolve.

Step 3: Enable Automatic Pipeline Enforcement and Alerts

Once configured, enforcement happens automatically in your CI/CD pipeline. As your CI tool runs your builds, RunSafe generates SBOMs and checks them against your license policy. Pipelines containing denied licenses will fail with clear output in your logs, identifying exactly which licenses triggered the block. 

Step 4: Adapt as Your Dependencies Grow

As your team adds new libraries or updates existing ones, newly detected licenses automatically appear in your unset list. Depending on your enforcement posture, they either flow through (if allowed by default) or stop the pipeline for review before releasing code (if denied by default). You can adjust individual license decisions at any time, moving them between allowed and denied as your policy matures.

SBOMs: The Prerequisite for License Enforcement

You can’t enforce license policy if you don’t know what’s in your build. SBOMs solve that, but most SBOM tools fail in C/C++ environments because license data lives in:

• File headers
• Top-level LICENSE files
• Repository metadata
• Vendor drop-ins with no manifest at all

Without file-level SBOM accuracy, compliance becomes guesswork. This is where RunSafe differentiates itself. By generating SBOMs at the file level during build-time, RunSafe can accurately capture license information for embedded projects. This then leads to greater confidence in license compliance.

Protect Your Proprietary Code

By enforcing license policy at build time and pairing it with accurate SBOMs, you can reduce copyleft risk before it reaches production. 

Interested in giving it a try? Sign up for a free trial of the RunSafe Security Platform.

The post Stopping Copyleft: Integrating Software License Compliance & SBOMs appeared first on RunSafe Security.

Key Takeaways:

• Legacy devices can’t be patched easily, but compensating controls provide alternatives.
• SBOMs are critical for transparency and accountability.
• The FDA now mandates secure development and life cycle planning.
• Cybersecurity and patient safety are inseparable—breaches harm care.
• Collaboration is the only sustainable path forward.

In healthcare cybersecurity, one of the biggest challenges is protecting medical devices that are difficult to patch and written in memory unsafe languages. Unlike web applications or mobile software, which can be updated overnight, medical devices are often built to last 10–15 years and aredesigned for reliability and patient safety—not constant code revisions.

Yet cyber threats are growing, and FDA regulations are tightening. Manufacturers and healthcare providers are now under pressure to secure legacy systems while keeping patients safe. The question is: how can this be done without rewriting a single line of code?

This was the focus of a recent episode of Exploited: The Cyber Truth, featuring Phil Englert (VP of Medical Device Security at Health-ISAC) and Joseph M. Saunders (Founder & CEO of RunSafe Security). Their insights offer a practical roadmap that blends compensating controls, regulatory awareness, and industry collaboration.

The post Beyond Patching: How to Secure Medical Devices and Meet FDA Compliance Without Changing Code 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.

The regulatory landscape for product security has fundamentally shifted. What was once a “nice-to-have” consideration has become mandatory compliance across industries, with cybersecurity now sitting at the center of product development, risk management, and go-to-market strategies.

Product leaders today face mounting pressure from multiple regulations—the EU Cyber Resilience Act (CRA), FDA cybersecurity requirements, and a growing list of industry-specific mandates—while still needing to maintain innovation speed and profitability. The stakes couldn’t be higher: non-compliance risks include fines up to €15 million or 2.5% of global turnover under the CRA, market access restrictions, and potentially devastating reputational damage.

But here’s the critical insight that forward-thinking product leaders are discovering: these regulations don’t have to be a burden. When approached strategically, regulatory compliance can become a competitive differentiator that strengthens products, builds customer trust, and creates sustainable business advantages.

Listen to the Audio Overview

The Product Compliance Tidal Wave: Understanding the Forces at Play

The 2024-2025 period has seen new cybersecurity regulations appear across sectors, representing a fundamental shift in how responsibility for product security is assigned and enforced.

The most significant change is the shift in liability. Under traditional models, end users often bore responsibility for securing the products they purchased. Today’s regulations flip this dynamic, making manufacturers the primary guardians of product security throughout the entire lifecycle. The CRA rebalances responsibility toward manufacturers and sets new standards across product lifecycles, fundamentally changing how companies must approach product development and support.

Supply chain transparency has become another critical factor. New requirements for Software Bills of Materials (SBOMs) and vulnerability disclosure mean that product leaders can no longer treat their supply chains as black boxes. Every component, every dependency, and every potential vulnerability must be catalogued, monitored, and managed.

As RunSafe Founder and CEO Joe Saunders has emphasized, “If a vendor can’t tell you what’s in their product, chances are, they don’t know either.” This lack of knowledge will no longer fly with consumers, regulators, or internal risk management teams.

Perhaps most importantly, these regulations demand a cultural transformation within organizations. As noted by cybersecurity experts at IMD Business School in a June 2025 Qt Group analysis, “the EU Cyber Resilience Act demands a fundamental cultural and leadership shift in organizations,” moving away from security as a bolt-on feature to security as a foundational element of product design.

The EU Cyber Resilience Act: A New Paradigm for Product Security

The CRA represents the most comprehensive product security regulation to date, with implications that extend far beyond European borders. Understanding its requirements isn’t just about compliance, it’s about understanding where the entire industry is heading.

Timeline and Strategic Implications

The CRA entered into force on December 10, 2024, but the most critical date for product leaders is December 11, 2027, when most obligations become enforceable. This timeline creates both urgency and opportunity: companies that start preparing now will have significant advantages over competitors who wait until the last minute.

The regulation’s scope is deliberately broad, covering all connected products and software sold in the EU, regardless of where the manufacturer is located. This means that any company selling digital products globally needs to consider CRA compliance as a baseline requirement.

Core Requirements That Change Everything

The CRA’s “Secure-by-Design” mandate isn’t just regulatory language but a complete shift in how products must be conceived, developed, and maintained. Security can no longer be retrofitted; it must be integral from the earliest design phases.

Vulnerability management under the CRA requires manufacturers to report vulnerabilities within 24 hours of discovery and implement coordinated disclosure processes. This creates new operational requirements but also opportunities for companies that excel at rapid response and transparent communication.

The documentation requirements are extensive, covering security documentation, risk assessments, and conformity declarations. While this creates an administrative burden, it also forces companies to develop more rigorous security practices that typically result in higher-quality, more resilient products.

Post-market obligations represent perhaps the biggest shift, requiring ongoing security updates for a minimum of five years or the expected product lifetime. This transforms the economics of product development, making long-term security support a core business consideration rather than an afterthought.

FDA Cybersecurity Requirements: Medical Devices Lead the Way

The FDA’s 2025 cybersecurity guidance updates represent a maturation of medical device security requirements, but their implications extend beyond healthcare. As one of the most regulated industries, medical devices often preview compliance approaches that eventually spread to other sectors.

The New Enforcement Reality

The FDA’s latest guidance mandates that cybersecurity must be demonstrated from pre-market design through post-market support, with strong documentation on vulnerabilities and supply chain transparency for all device components. This lifecycle approach mirrors the CRA’s philosophy and suggests a convergence toward comprehensive product security requirements across industries.

The emphasis on SBOM requirements for connected medical devices creates new transparency obligations but also opportunities for companies that can demonstrate superior supply chain security. Companies that proactively implement robust component tracking and vulnerability management will find themselves better positioned for both regulatory compliance and customer trust.

Strategic Impact on Product Development

The FDA’s approach changes go-to-market strategies for medical technology companies. Security documentation is now part of the regulatory submission process, meaning that security considerations must be built into product development timelines from the beginning.

This creates new resource allocation challenges, as companies need dedicated cybersecurity expertise within product teams. However, it also creates competitive advantages for companies that develop this expertise early and can demonstrate superior security practices to customers and regulators.

Learn more about navigating vulnerability identification and postmarket cybersecurity for medical devices in this video: On-Demand Webinar: Medical Device Cybersecurity Challenges

Strategic Focus Areas: Maximizing ROI on Security Investments

With limited resources and expanding regulatory requirements, product leaders must prioritize their security investments strategically. The most successful companies focus on areas that provide both regulatory compliance and business value.

Supply Chain Security and SBOM Management

SBOM requirements appear across multiple regulations—the CRA, FDA guidance, and emerging requirements in other sectors. This makes supply chain transparency a high-leverage investment that addresses multiple compliance requirements simultaneously.

The business case extends beyond compliance. Companies with comprehensive SBOM capabilities can respond faster to supply chain vulnerabilities, reduce incident response costs, and demonstrate superior risk management to customers and partners. The key is implementing automated SBOM generation and continuous component monitoring rather than treating it as a one-time documentation exercise.

Vulnerability Management Excellence

Both the CRA’s 24-hour reporting requirement and the FDA’s lifecycle security obligations demand sophisticated vulnerability management capabilities. Companies that excel in this area gain competitive advantages that extend far beyond compliance.

Proactive vulnerability management reduces breach costs significantly—studies show comprehensive vulnerability management programs can reduce incident costs by millions of dollars. Research indicates that the average cost of a data breach reached $4.88 million in 2024, according to IBM’s Cost of a Data Breach Report. More importantly, companies known for rapid, transparent vulnerability response build trust with customers and partners that translates into business growth.

The implementation challenge is building systems that can automatically detect, assess, and respond to vulnerabilities across complex product portfolios. This requires integration between threat intelligence, asset management, and incident response processes.

Secure Development as Competitive Advantage

The CRA’s Secure-by-Design requirements and the FDA’s lifecycle approach both emphasize building security into products from the ground up. Companies that master secure development practices don’t just achieve compliance—they build products that customers trust and competitors struggle to match.

Key elements include integrated threat modeling, secure coding standards, and security testing throughout the development lifecycle. The goal isn’t just to pass security audits but to build products that are inherently more resilient and trustworthy.

The Benefits of Proactive Product Compliance

The most successful product leaders are discovering that proactive product compliance creates business value that far exceeds the investment required.

Competitive Differentiation Through Security

In increasingly security-conscious markets, products with built-in security capabilities command premium pricing and win more procurement decisions. This trend is particularly pronounced in healthcare, where RunSafe Security’s 2025 Medical Device Cybersecurity Index found that 60% of healthcare organizations prioritize built-in cybersecurity protections when selecting vendors, with 79% willing to pay a premium for devices with advanced runtime protection.

Security-first product positioning also builds long-term customer relationships. Companies that can demonstrate transparent security practices and rapid vulnerability response develop customer loyalty that extends beyond individual product transactions.

Operational Excellence and Risk Reduction

Secure-by-Design development practices reduce technical debt by preventing security issues rather than retrofitting solutions. This approach typically results in lower long-term development and maintenance costs, even accounting for upfront security investments.

Good security practices also streamline regulatory audits and compliance verification. Companies with mature security programs spend less time and resources on compliance activities because their standard practices already meet or exceed regulatory requirements.

Financial Returns and Investment Attraction

The financial benefits of proactive security extend beyond cost reduction. Healthcare organizations demonstrate this market reality clearly, as seen in RunSafe’s 2025 Medical Device Cybersecurity Index. 79% of healthcare buyers are willing to pay a premium for devices with advanced runtime protection, with 41% willing to pay up to 15% more for enhanced security. Additionally, 83% of healthcare organizations now integrate cybersecurity standards directly into their RFPs, while 46% have declined to purchase medical devices due to cybersecurity concerns.

Risk reduction creates additional financial value through lower incident response costs, reduced legal exposure, and improved cyber insurance rates. Companies with strong security programs often achieve significantly lower insurance premiums and better coverage terms. The documented financial impact of attacks like WannaCry, which cost the NHS £92 million, demonstrates that prevention is far more cost-effective than recovery.

What’s Next: Preparing for the Evolving Landscape

The regulatory landscape will continue to evolve, with several emerging trends that product leaders should monitor and prepare for.

1. AI and machine learning governance represent the next frontier of product regulation. As AI capabilities become embedded in more products, expect new requirements for AI security, transparency, and accountability.
2. Quantum-safe cryptography is another emerging area. As quantum computing capabilities advance, current cryptographic standards will become vulnerable, creating new requirements for post-quantum security measures.
3. Cross-border data flow regulations continue to evolve, with new privacy and data localization requirements affecting how products handle and store user data.

Strategic Recommendations for Product Leaders

Based on the regulatory trends and business opportunities outlined above, several strategic recommendations emerge for product leaders navigating this complex landscape:

1. Invest heavily in automation capabilities

Manual compliance processes are unsustainable given the complexity and pace of regulatory change. Companies that build automated compliance capabilities will have significant advantages over competitors still relying on manual processes for monitoring, reporting, and verification.

2. Build strategic security partnerships

Few companies have all the expertise needed to excel across the full spectrum of security and compliance requirements. Strategic partnerships with specialized security vendors can provide access to expertise and capabilities that would be expensive to develop internally while accelerating time-to-market for compliant products.

3. Focus on security solutions that eliminate entire vulnerability classes

Rather than playing defense against individual threats, prioritize technologies that can eliminate broad categories of vulnerabilities. Runtime protection solutions that prevent exploitation at the device level represent this approach—they provide comprehensive protection without requiring constant updates or patches. This strategy significantly reduces risk while simplifying compliance management across product portfolios.

4. Stay informed about regulatory developments through structured processes

The regulatory landscape continues to evolve rapidly, and companies that can anticipate changes rather than just react to them will maintain competitive advantages. Establish dedicated resources for monitoring regulatory trends and translating them into product development requirements.

5. Design for global compliance standards from the start

Rather than building separate compliance programs for different markets, design for the most stringent requirements across all target markets. This approach reduces complexity while ensuring products can be sold in any market without additional compliance engineering.

Product Compliance as a Competitive Advantage

The convergence of the EU Cyber Resilience Act, FDA cybersecurity requirements, and other emerging regulations represents both the greatest challenge and the greatest opportunity facing product leaders today. The companies that view these requirements as innovation drivers rather than compliance burdens will build more secure, resilient, and successful products.

The critical insight is that waiting is not a viable strategy. The December 2027 CRA deadline and evolving FDA requirements create urgency, but companies that start building security capabilities now will discover that the benefits extend far beyond regulatory compliance.

For product leaders ready to turn cybersecurity compliance into a competitive advantage, the path forward is clear: embrace security as a core product differentiator, invest in the capabilities needed to excel at both security and compliance, and build the partnerships needed to stay ahead. The companies that make these investments today will be the market leaders of tomorrow.

Learn more about how to safeguard your code to up your product compliance. Get the white paper: “Safeguarding Code: A Comprehensive Guide to Addressing the Memory Safety Crisis.” 

The post What Product Leaders Need to Know About EU CRA, FDA, and Cyber Regulations appeared first on RunSafe Security.

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

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

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

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

What Is the CRA and Who Does It Affect?

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

New Liabilities and the Cost of Non-Compliance

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

How Are Organizations Preparing?

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

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

The Role of Cyber Insurance in a Post-CRA World

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

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

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

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

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

Preparing to Compete in the Cyber Resilience Economy

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

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

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

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

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

Why SBOMs Are Becoming a Must-Have

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

1. The SolarWinds Attack of 2020 

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

2. The Log4Shell Vulnerability 

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

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

RunSafe Security and Critical Software are partners in delivering comprehensive safety and security solutions for critical sectors in Europe and the US.

Imagine modern healthcare services without medical devices. You can’t? Neither can we. Medical devices perform a vital role in the patient experience, from diagnosis to treatment to follow-up. Advances in tech have enhanced these devices and, in turn, have improved patient outcomes. Personalized treatment plans using data gathered from wearables; real-time monitoring of patients’ conditions allowing healthcare professionals to intervene in a timely fashion; AI-powered surgical systems assisting surgeons during complex operations – all of these have revolutionized the way patients are treated. 

But they have also widened the threat horizon for patients. The ever-increasing range of cyber threats pose serious reputational risks to manufacturers and could mean the difference between life and death for patients. But to combat these threats, different jurisdictions have implemented their own medical device cybersecurity standards, creating friction for manufacturers operating in various markets. 

From the European Union’s Medical Devices Regulation (MDR) to the United States’ Foods & Drug Administration (FDA), medical device manufacturers need to ensure their devices comply with cybersecurity standards outlined in each jurisdiction. But is this getting easier or more complex in an ever-more complex threat environment?

Medical Device Cybersecurity in the EU

The EU’s MDR outlines clear rules with which medical device manufacturers must comply in the domain of cybersecurity, particularly with regards to following risk management practices aligned with ISO 31010 and ISO 14971. 

Post-market surveillance is critical to this: the manufacturer is responsible for keeping track of any cybersecurity vulnerabilities that present themselves in their devices and must work to rectify these once identified.

Harmonization of Medical Device Standards and Regulations

Yet harmonization is already occurring between the two regulators, reducing friction and making manufacturers’ lives easier. ISO 13485 is adhered to by both the MDR within the EU and the US FDA, aligning quality management system regulations between the two markets. This is in addition to the most recent update of harmonized standards made by the EU in March 2024, this being the next step in the bloc’s efforts to align its standards with those applicable globally. 

The International Medical Devices Regulators Forum (IMDRF) plays a role in reducing barriers for manufacturers operating in the EU and US, with shared guidance on clinical evaluation and post-market surveillance making it easier for manufacturers to distribute, monitor, and “sense-check” their devices, ensuring compliance with a harmonized set of standards. This is integral in the cybersecurity domain, ensuring protection against evolving threats in whichever market the devices are placed in.

What Does This Mean for Cybersecurity?

Both the EU’s MDR and the FDA’s regulations require a risk-based approach, ensuring that residual risks are assessed and managed throughout the device’s lifecycle. In terms of cybersecurity, this demands extensive risk management documentation. Similarly, Secure by Design has been implemented in both the EU and the US: the MDR encourages manufacturers to implement cybersecurity measures from the earliest stage of the design process, while the FDA requires Secure Product Development Frameworks (SPDFs) be followed from early design to product release.

There is still much work to do, however. Since 2010, the number of cybersecurity incidents in the EU and the US has increased. From 2021 to 2023, there were over 215 publicly reported cybersecurity incidents relating to medical devices in the EU. In the US, it is estimated that over 53% of devices on the market possess critical cyber vulnerabilities. A 2024 report from Censys found that there are “14,004 unique IP addresses exposing healthcare devices and data systems connected to potentially sensitive medical information on the public internet. These exposures greatly raise the risk of unauthorized access and exploitation.”

The Future of Cybersecurity Regulatory Alignment

Regulatory alignment is heading in the right direction, but as we have seen, there is still more work to be done. While harmonization is progressing, critical vulnerabilities remain in copious amounts of medical devices and healthcare products in the market, which opportunistic hackers and hostile actors can take advantage of.

Want to discover more about the pivotal role of cybersecurity in medical devices? Catch up with Critical Software and RunSafe Security’s recent webinar featuring Afonso Neto from Critical Software and Doug Britton from RunSafe Security, who outlined some of the most pressing cybersecurity aspects underpinning medical device regulations in the EU and USA. Watch the webinar here.

The post Is Regulatory Harmonization on the Horizon? The Medical Devices Cybersecurity Landscape in the EU and the US 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.

It’s for this reason, among other national security, economic, and public health concerns, that the Cybersecurity and Infrastructure Security Agency (CISA) has made memory safety a key focus of its Secure by Design initiatives.

Now, CISA is urging software manufacturers to publish a memory safety roadmap by January 1, 2026, outlining how they will eliminate memory safety vulnerabilities in code, either by using memory safe languages or implementing hardware capabilities that prevent memory safety vulnerabilities.

Though manufacturers are on the hook for the security of their products, the responsibility doesn’t fall solely on the shoulders of the manufacturers. Buyers of software in the OT sector also have an equally important role to play in addressing memory safety to build the resilience of their mission-critical OT systems against attack.

“The roadmap to memory safety is a great starting point for asset owners to talk to their suppliers, saying this is a big concern of mine, especially for my OT software,” said Joseph M. Saunders, Founder and CEO of RunSafe Security. “Then, what we’re looking for from product manufacturers is that they have a mature process to assess how to achieve memory safety.”

Why Memory Safety Should Be on Your Radar

Why all the fuss about memory safety, and why now? Memory safety vulnerabilities consistently rank among the most dangerous software weaknesses, and they are alarmingly common. Within industrial control systems, memory safety vulnerabilities have been steadily rising, growing from less than 1,000 CVEs in 2014 to nearing 3,000 in 2023 alone. 

In one example, programmable logic controllers were found vulnerable to memory corruption flaws that could enable remote code execution. In the OT world, where systems control critical industrial processes, such vulnerabilities aren’t just security risks — they’re potential catastrophes waiting to happen.

Building a Memory Safety Strategy: Collaboration Between OT Software Manufacturers and Buyers Is Needed

CISA has set a clear deadline: January 1, 2026. With this date in mind, OT software manufacturers and buyers can begin to have important conversations about addressing memory safety, both for existing products written in memory-unsafe languages and for new products to be released down the line. 

What should be on the agenda for discussion when building and evaluating a memory safety roadmap? Here are four key areas to look at.

1. Vulnerability Assessments

Start with a comprehensive Software Bill of Materials (SBOM) to identify and prioritize memory-based vulnerabilities in OT software. Think of it as a detailed inventory that helps you:

• Identify existing vulnerabilities
• Map your software supply chain
• Pinpoint products most at risk from memory-based vulnerabilities

2. Smart Remediation Planning

Once vulnerabilities are identified, manufacturers should take next steps to eliminate them. OT software buyers can discuss with manufacturers about remediation options like: 

• Prioritizing addressing systems with high exposure and potential impact
• Evaluating options for rewriting legacy code in memory-safe languages, like Rust
• Considering proactive solutions such as Load-time Function Randomization (LFR) for existing systems when code rewrites are not practical

3. Future-Proofing Your Products

Software buyers should discuss with their suppliers how they are incorporating memory safety into their product lifecycle planning. 

Look ahead by:

• Integrating memory safety into your product roadmap
• Taking advantage of major architectural changes to implement memory-safe languages
• Deploying software memory protection for existing code

4. Building Strong Partnerships

A memory safety roadmap is a great opportunity for software manufacturers and buyers to open up conversations about memory safety and collaborate to find a path forward. When considering working with a supplier, evaluate their willingness to 

• Establish regular communication channels
• Transparently track progress
• Demonstrate a shared commitment to security goals

Moving Forward with CISA’s Memory Safety Guidance

By working together, software buyers and manufacturers can not only meet CISA’s memory safety mandate but also build more resilient OT systems.

“All asset owners should do a study with their suppliers to understand the extent to which they are exposed to memory safety vulnerabilities,” Saunders said.

From there, software manufacturers can build a roadmap to tackle the memory safety challenge once and for all.

Learn more about how RunSafe Security protects critical infrastructure and OT systems from memory-based vulnerabilities. 

The post CISA’s 2026 Memory Safety Deadline: What OT Leaders Need to Know Now 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.

Securing Airborne Systems with Advanced Memory Safety Techniques

How RunSafe Code Works

RunSafe Code Qualification – Development Tool

RunSafe Code Certification – Flight Software

RunSafe Code Certification – Airworthiness Security

Elevating Flight Safety: Software Security in Airborne Systems

Securing Airborne Systems with Advanced Memory Safety Techniques

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

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

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

How RunSafe Code Works

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

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

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

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

RunSafe Code Qualification – Development Tool

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

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

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

RunSafe Code Certification – Flight Software

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

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

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

RunSafe Code Certification – Airworthiness Security

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

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

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

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

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