The United States Cybersecurity and Infrastructure Security Agency (CISA) and National Security Agency (NSA) recently published a joint guide, “The Case for Memory Safe Roadmaps: Why Both C-Suite Executives and Technical Experts Need to Take Memory Safe Coding Seriously.” The guidance, authored in collaboration with several other national and foreign security agencies, emphasizes the gravity and scope of memory safety vulnerabilities, which make up around 70% of Microsoft CVEs and vulnerabilities identified by Google’s Chromium project.
High-profile failures in memory safety like the Heartbleed and BadAlloc vulnerabilities have affected hundreds of thousands of sites and millions of individuals and devices. These incidents have highlighted the significant impact of memory safety and the implications that this type of vulnerability can have for national security.
What Are Memory-Safe Languages?
A memory-safe language (MSL) is one that is designed to prevent some kinds of bugs from being introduced into the code. While traditional languages like C, C++, and assembly are memory-unsafe, some that are memory-safe include Rust, Go, Java, Python, and Swift. These languages have built-in features to prevent memory-related bugs, including:
- Bounds checking: ensuring that requests for out-of-bounds data return error messages, rather than pulling from the memory contents that may include other people’s data.
- Garbage collection: reclaiming memory that has been allocated by the program but is no longer in use, lifting some of the burden of manual memory management.
- Ownership models: managing memory via ownership rules checked by the compiler, rather than using garbage collection.
Modernization Challenges: The Real-World Roadblocks
While adopting MSLs is an important move toward software security, this transition is not as simple as just deciding to do it. There are a number of logistical and operational reasons that modernizing programs to use memory-safe programming languages can be difficult and involved, hindering efforts toward improved memory safety. “While memory-safe languages like Rust and Go provide excellent built-in protections against buffer overflows and use-after-free vulnerabilities, the reality is that most organizations will be running mixed environments for years to come,” says J Stephen Kowski, Field CTO at SlashNext.
Many organizations use legacy systems and architecture that relies on non-memory-safe languages. In these cases, adopting MSLs would require significant—potentially total—overhauls on critical systems. Implementing MSLs comes with trade-offs in real-time performance and scalability and creates challenges in interlanguage communications. There are also significant gaps in tooling, developer expertise, and third-party libraries to aid in transitioning toward memory-safe languages, especially in constrained environments like OT and IoT systems.
CISA and NSA’s Prescriptive Recommendations
The joint guidance released by the CISA and NSA offers in-depth advice for mitigating memory safety issues. It recommends developing and following roadmaps for the transition to MSLs, using appropriate MSLs and methods of migration for the organization’s needs, capabilities, and goals. The guide suggests a layered migration strategy, urging organizations to prioritize crucial areas like developing new programs in MSLs, replacing memory-unsafe components, and addressing code that is critical for security.
It also highlights the importance of performing a risk-based analysis when rewriting a critical component, as any significant change that could have major security repercussions demands. Organizations are also encouraged to fortify supply chains by using MSL-based libraries where possible, and to take steps to invest in cross-language tooling and community growth.
Why This Isn’t Just a Developer Issue
While program developers should address the problem of memory safety by using MSLs and overall prioritizing secure coding practices in their development, it is crucial to recognize that the responsibility falls on other involved parties as well. The issue of memory safety “isn’t just about choosing the right language - it’s about having comprehensive visibility into your entire software supply chain to identify where these vulnerabilities exist in the first place,” according to Kowski.
There are broad implications for national security, public safety, and infrastructure resilience in the conversation surrounding MSLs. Such an impactful and fundamental change as widespread MSL adoption requires executive support, organization-wide commitment to secure development as a core business imperative, and collaboration between the private and public sectors.
The Road Ahead: Resilience Through Code
Looking ahead on the track toward widespread MSL adoption, it is vital to remember that MSLs are part of a broader secure-by-design movement, emphasizing the importance of secure coding and infrastructure. The long-term benefits of ensuring memory safety include fewer vulnerabilities, lower cost of remediation, and better system reliability. It is necessary for organizations and developers alike to take steps to prepare for a memory-safe future.
