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

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

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

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

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

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

What Motivated the Conversion of C++ to Rust?

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

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

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

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

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

Challenges in Converting to Rust

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

Code and Library Compatibility Issues

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

Dealing with Mutable State

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

Platform Support

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

Steps to Transition Your Code from C++ to Rust

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

Step 1. Evaluate and Prepare

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

Step 2. Plan the Conversion Approach

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

Step 3. Build a Skeleton in Rust

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

Step 4. Refactor and Optimize

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

Outcomes: What RunSafe Found

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

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

Should You Rewrite Your Code in Rust?

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

Here are some critical factors to consider:

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

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

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

The software industry faces a persistent challenge: how to address memory safety vulnerabilities, one of the most common and exploited flaws in modern systems. Memory safety vulnerabilities expose systems to remote control, data breaches, and disruptions, often with devastating consequences. In response, Secure by Design principles offer a forward-thinking solution to the challenge by embedding security into the foundation of software development.

In a recent webinar hosted by RunSafe Security, industry experts Doug Britton, EVP and Chief Strategy Officer at RunSafe, and Shane Fry, Chief Technology Officer at RunSafe, provided insights into the critical role that Secure by Design can play in mitigating these vulnerabilities. 

Here are the key takeaways from their discussion and how RunSafe’s approach supports a proactive cybersecurity model.

Access the full webinar discussion on memory safety here.

Memory Safety: A Persistent Threat

Memory safety vulnerabilities are among the oldest and most widespread issues in software development. Doug Britton emphasized how these vulnerabilities, despite being known for decades, persist in many codebases and continue to be exploited by attackers.

“The classic memory safety issues are among the oldest and most insidious in software,” Doug explained. “We’ve known about them for decades, but they persist, and attackers continue to exploit them.”

According to Jack Cable, senior technical advisor at CISA, two-thirds of vulnerabilities in compiled code are related to memory safety. Attackers frequently weaponize these flaws, leading to widespread breaches and disruptions. Even advanced testing tools and compilers often fail to detect all vulnerabilities, leaving organizations exposed. These vulnerabilities include buffer overflows, which Doug and Shane referenced as a common point of exploitation.

What Is Secure by Design?

Secure by Design is an approach to software development that prioritizes security from the very beginning. Rather than bolting on security measures after the fact, Secure by Design integrates security into every stage of the development lifecycle. The method aims to reduce the likelihood of vulnerabilities by making security an inherent part of the system architecture.

In the case of memory safety, this often involves transitioning to memory-safe languages like Rust and Go, which can drastically reduce the risk of memory-related bugs. However, as Doug noted, transitioning entire codebases to these languages is not a quick fix. “Most vendors we’ve spoken to have said it’s going to take them at least eight years to get a significant portion of their code running in memory-safe languages,” he shared.

This timeline introduces a significant challenge: organizations cannot afford to wait for years while attackers continue to exploit existing vulnerabilities. Immediate solutions are needed to bridge the gap.

RunSafe’s Contribution to Secure by Design

RunSafe Security provides a practical, scalable solution to address memory safety vulnerabilities while organizations work toward the long-term goal of transitioning to memory-safe languages. Instead of requiring developers to rewrite their entire codebase, RunSafe’s technology mitigates vulnerabilities without changing a single line of code.

As Shane Fry explained, RunSafe’s approach focuses on randomizing code layouts in memory. This method prevents attackers from predicting where code is located, making it significantly harder to exploit memory vulnerabilities such as buffer overflows.

“What we do is randomize where the code is in memory,” Shane said. “Even if an attacker finds a buffer overflow, they won’t know where to point the processor to execute their malicious code because everything has been randomized.”

This process, known as Moving Target Defense, effectively protects against both known and unknown vulnerabilities at runtime. RunSafe’s solution can be integrated in as little as 30 minutes, making it accessible for organizations of all sizes without disrupting development workflows.

Challenges in Adopting Secure by Design

Despite its clear benefits, adopting Secure by Design principles is not without its challenges. One of the most significant barriers is the transition to memory-safe languages. As Doug and Shane discussed, this process is resource-intensive and requires specialized expertise, which many organizations do not yet possess.

“To implement Rust or Go, developers need to learn these languages, and that takes time,” Doug pointed out. “It’s not as simple as downloading a module and instantly knowing Rust. It’s going to take an equivalent amount of time and effort as it took to build the original C and C++ codebases.”

Additionally, there are significant economic barriers to rewriting code, especially in industries reliant on legacy systems. Shane highlighted that while Secure by Design offers a path toward a safer future, organizations need interim solutions to protect themselves in the present.

This is where RunSafe’s solution becomes invaluable. By randomizing code layout, organizations can protect their existing systems while planning for the long-term transition to memory-safe languages. This hybrid approach allows companies to mitigate immediate risks without requiring massive investments in rewriting code from scratch.

The Benefits of Secure by Design

While Secure by Design requires upfront investment, its long-term benefits make it a critical strategy for organizations looking to build more secure and resilient systems. 

Shane emphasized that acting now is crucial, as attackers won’t wait for organizations to fully transition to memory-safe languages. “The bugs that exist today are going to be exploited tomorrow,” he warned. “It’s essential that we take immediate steps to protect our systems.”

Key advantages include:

1. Reduced Vulnerabilities: By embedding security into the development process, Secure by Design helps eliminate vulnerabilities before they become exploitable, reducing the need for costly patches later.
2. Lower Costs: Addressing security during the design phase can significantly reduce the need for emergency updates, saving organizations time and money.
3. Improved Developer Efficiency: With security integrated from the start, developers can focus on innovation rather than constantly fixing vulnerabilities post-launch.
4. Increased Customer Trust: Organizations that prioritize Secure by Design demonstrate a commitment to safety, which builds trust among customers, partners, and stakeholders.
5. Future-Proofing: Secure by Design helps organizations stay ahead of emerging threats, ensuring that their systems are prepared to withstand future cyberattacks.

Building a Resilient Future

Secure by Design principles offer a clear path forward for organizations looking to protect themselves from memory safety vulnerabilities. RunSafe Security provides a critical solution that helps companies bridge the gap between today’s risks and the long-term goal of transitioning to memory-safe languages.

By embracing Secure by Design and leveraging RunSafe’s technology, organizations can build more resilient systems, reduce their exposure to vulnerabilities, and protect their operations from the ever-present threat of cyberattacks.

For a deeper dive into Secure by Design strategies and memory safety solutions, download our full webinar and learn from industry experts Doug Britton and Shane Fry how to protect your codebase and future-proof your organization’s cybersecurity strategy. 

The post Secure by Design: Building a Safer Future Through Memory Safety appeared first on RunSafe Security.

Security Challenges and the Secure by Design Report:

The increasing frequency and sophistication of cyber threats have exposed vulnerabilities in digital systems, prompting the need for a proactive and holistic approach to cybersecurity. The Secure by Design initiative emerged in response to these challenges, aiming to transform the cybersecurity landscape by embedding security principles into the very fabric of digital systems.

The Secure by Design Report is a crucial document outlining the principles and strategies that form the foundation of this initiative. Released by CISA, the report delves into the importance of secure design practices and highlights their critical role in mitigating cyber risks.

What is Secure by Design?

Secure by Design, as defined by the CISA report, is an approach that integrates security considerations throughout the product development lifecycle. It emphasizes the proactive incorporation of security features and practices during the design phase, ensuring that cybersecurity is not an afterthought but an inherent aspect of the system.

The importance of Secure by Design cannot be overstated. 

In an interconnected world where digital systems permeate every aspect of our lives, vulnerabilities in one area can have cascading effects. The Secure by Design approach seeks to address this by building resilient systems that can withstand cyber threats from the outset.

Manufacturers of digital products play a pivotal role in this paradigm shift. Failing to embrace Secure by Design principles can result in dire consequences, ranging from data breaches and financial losses to reputational damage. The urgency for product manufacturers to prioritize security in their design processes has never been greater.

What is Secure by Default?

Secure by Default is another critical aspect of CISA’s initiative. It entails configuring products and systems with the most secure settings as the default, minimizing the need for users to make manual adjustments to enhance security. This approach aims to reduce the risk of misconfigurations and ensure that security is not compromised due to user oversight.

Secure by Design and Secure by Default are interconnected concepts, but they address different product life cycle phases. Secure by Design is concerned with integrating security into the design and development stages, while Secure by Default focuses on ensuring that products are configured securely from the outset.

Together, these principles create a robust defense against a wide array of cyber threats.

How RunSafe Fulfills Secure by Design and Secure by Default:

RunSafe aligns closely with the principles of Secure by Design and Secure by Default, notably advocating for making products resilient against the most prevalent threats and vulnerabilities without requiring end-users to take additional actions.

RunSafe emphasizes proactive security measures in the early stages of product development with the manufacturers, integrating security into the design process. In doing this, RunSafe ensures that the products are inherently resistant to a wide range of cyber threats. This approach safeguards against known vulnerabilities and anticipates emerging risks, providing a dynamic defense mechanism.

RunSafe goes beyond conventional practices with code hardening to ensure the highest level of security protocols as the default. This minimizes the likelihood of recurring incidents after patches that could continue to compromise security. 

RunSafe’s commitment to Secure by Default reflects a dedication to delivering solutions that prioritize critical infrastructure safety and security.

Recommendations for Software Manufacturers:

CISA’s Secure by Design initiative outlines three fundamental principles that software manufacturers should embrace to enhance the security posture of their products. Each principle serves as a roadmap for creating resilient and secure digital systems.

Principle 1: Own Security Outcomes

Take ownership of customer security outcomes and evolve products accordingly. The burden of security should not fall solely on the customer. 

The report emphasizes that software manufacturers should integrate application hardening through processes and technologies that increase the difficulty for malicious actors attempting to compromise applications. Application hardening protocols and procedures are vital in enabling products to withstand attacks from intelligent malicious actors. Concepts such as hardening, product security, and resilience are closely intertwined with product quality, emphasizing the necessity for security to be seamlessly integrated rather than added as an afterthought.

Two ways that RunSafe demonstrates this principle are:

1. Responsibly using open source software: Beyond standard vetting, fostering code contributions back to dependencies, and helping sustain development and maintenance for critical components, RunSafe Code™ utilizes patented Moving Target Defense (MTD) techniques to fortify software during the design phase. This involves dynamically relocating where functions load into memory, creating a unique configuration for every software load and each deployed instance.

Since this is implemented in the design phase, no new software is introduced through patches, and no alteration of lines of code occurs. Consequently, there is no impact on system performance or functionality.

To provide additional transparency across the software supply chain, RunSafe offers an automated software bill of materials (SBOM) through its Gremlin product. Generated at compilation time, the comprehensive SBOM ensures developers have a clear snapshot of all software components at play.

2. Providing secure defaults for developers: Manufacturers should make the default route during software development secure by providing safe building blocks for developers. RunSafe solutions, applied to the build root like the way LYNX MOSA.ic is secured, become the default settings, ensuring protection against 70% of the most common vulnerabilities with no developer impact.

Principle 2: Transparency & Accountability

Embrace radical transparency and accountability. Software manufacturers ought to provide products that prioritize safety and security. This differentiation may involve the transparent sharing of insights gained from customer deployments, such as the widespread adoption of robust authentication mechanisms by default.

Additionally, manufacturers should exhibit a dedicated effort to maintain the completeness and accuracy of vulnerability advisories and associated Common Vulnerability and Exposure (CVE) records. However, caution is advised against viewing CVE counts solely as negative metrics, as these numbers can also signify a robust and active code analysis and testing community.

Runsafe’s solutions contribute to the recommended secure product development practices, particularly the advice to Embrace vulnerability transparency and Publish Software Bills of Materials (SBOMs). Due to RunSafe’s dedication to full compliance and proactive software immunization, it’s advantageous for manufacturers to publish vulnerabilities with the associated mitigations labeled as “protected by RunSafe.” 

In addition, RunSafe’s automated SBOMs through Gremlin fulfill CISA’s recommendation to “build and maintain SBOMs for each product, request data from their suppliers, and make SBOMs available for downstream customers and users.” It’s important to consider varying types of SBOMs – build-time vs. binary-based – to determine which provides the most benefit to creating supply chain transparency.

One pro-security business practice that RunSafe supports is the publication of a memory-safety roadmap. Leveraging memory-safe languages enables manufacturers to make progress toward eliminating one of the largest classes of vulnerabilities.

Principle 3: Leadership

Build organizational structure and leadership to achieve these goals. While technical subject matter expertise is critical to product security, senior executives are the primary decision-makers for implementing organizational change. Executives need to prioritize security as a critical element of product development across the organization, and in partnership with customers.

RunSafe embodies the principles of Secure by Design and Secure by Default. Leading the charge and advocating for premium security measures, RunSafe stands as a reliable and trustworthy source of information for executives looking to better understand the best practices to implement Secure by Design practices.

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

Conclusion

CISA’s Secure by Design initiative presents a transformative approach to cybersecurity, emphasizing the integration of security into the very fabric of digital systems. Given the escalating cyber threats in today’s landscape, the urgency for product manufacturers to adopt these principles is evident.

The long-term benefits of embracing Secure by Design and Secure by Default are profound. As digital systems become increasingly integral to our critical infrastructure, a proactive and comprehensive security approach will not only safeguard against current threats but also future-proof products against emerging risks. The collaborative efforts of organizations like CISA and companies like RunSafe are instrumental in creating a resilient and secure digital ecosystem for generations to come.

The post Secure by Design: Building a Safer Digital Future appeared first on RunSafe Security.