A new joint report issued by the Cybersecurity and Infrastructure Security Agency (CISA) and the National Security Agency (NSA) once again raises the issue of transition to memory-safe languages, as both a secure-by-design principle and a target for rewrites.
The report follows many calls by both members of the cybersecurity industry and government agencies for a transition to languages like Rust, Ruby, Java and C# due to their inherent minimization of memory-related classes of vulnerabilities like buffer overflows. It notes that substantial barriers remain, however, such as lack of necessary third-party libraries and tooling.
Swapping into memory-safe languages considered “foundational,” but serious barriers persist
The NSA and CISA have been pushing memory-safe languages since 2022, with each agency issuing information sheets and guides annually culminating in a 2024 technical report issued from the White House laying out a more detailed plan for pushing widespread adoption.
The push is founded on the fact that non memory-safe languages, such as C and C++, simply cannot ever be fully secured against memory-related vulnerabilities. These languages put the onus on developers to secure against these possibilities, while the code structure of memory-safe languages precludes them from developing.
The new report cites numbers that indicate the great majority of vulnerabilities that develop are memory safety issues, such as a recent Google Project Zero report finding that 75% of CVEs used in the wild involved memory exploits. Microsoft is an example in which CVEs involving memory safety have actually dropped from about 70% in 2016 to 50% in more recent studies, but 50% is still a very substantial share. Frequent examples of these issues that continue to crop up include buffer overflows, data races and initialization safety exploits. The report notes that memory-safe languages build in an assortment of features specifically designed to prevent these issues from developing unintentionally, such as bounds checking and guardrails against unsynchronized concurrent access to pieces of data that create race conditions.
Google’s Android OS provides a case study in the efficacy of prioritizing memory-safe languages to address these sorts of numbers. In 2019, Android was in the same boat with many of its big tech fellows; it reported that 76% of all Android vulnerabilities involved memory issues. That prompted Google to shift a great deal of Android development to memory-safe Rust and Java. By 2024, this number was down to 24%. This did not require a rewrite of all existing code, but rather simply adopting the two safe languages in new code and leveraging interoperability to integrate with existing codebases.
Though Android is a heartening success story and provides at least something of a roadmap, there are still substantial adoption barriers. One big issue is dependency management when existing libraries were not developed with memory-safe languages or even with them in mind. Another is tightly coupled code in legacy systems, and another still is the hit to performance when memory-safe components have to communicate with those that are not.
Making memory-safe languages work
The report acknowledges that the reality of memory-safe languages is that for many organizations there will be a substantial up-front investment in tools, training and refactoring. That cost will also likely be realized in savings with time, but it may be over a long period and hard to specifically qualify (for example, fewer vulnerabilities emerging). Codebases, API and external libraries must also be carefully reviewed to ensure that selected memory-safe languages will integrate well with them.
As the Android example demonstrated, a relatively simple and low-risk way to introduce memory-safe languages is to prioritize their adoption in new projects. The report notes that rewriting existing codebases will often be an impractical choice for organizations, so the new languages should instead be gradually onboarded by writing new components and features with them. Targets for rewrites can be limited to high-risk components and modules likely to be focused on due to attack surface opportunity and critical to operations (such as cryptographic elements and file parsers).
The report ties into CISA’s broader “Secure By Design” campaign, which has been in motion since the Biden administration. Measures remain voluntary at this point, but the agency has asked private industry software designers supporting critical infrastructure to take a pledge to commit to a set of initial design principles that include working from a base of memory-safe languages. The intent is that broad adoption will “drift” into standardizing these principles in other areas, such as cloud infrastructure.
However, memory-safe languages are hardly a “silver bullet” and are still vulnerable to problematic coding practices. Thomas Richards, Infrastructure Security Practice Director at Black Duck, notes that adoption of new languages also means ensuring developers have a good handle on their particular requirements: “Programming languages like C have been the backbone of our modern computing world, however, insecure coding practices have created critical vulnerabilities. Moving away from unsafe languages is a great step to reducing certain classes of software vulnerabilities. This should not be taken as assuming all code written in MSLs is fully secure; they are still insecure coding practices that could create other vulnerabilities. Developers should always be aware of secure coding guidelines in the specific language they are using to reduce the risk of a vulnerability in their code and ensure uncompromised trust in software.”
Jason Soroko, Senior Fellow at Sectigo, notes that the broader push in this direction means that developers should expect to be familiar with the popular languages that are adopted going forward: “Regulators are no longer framing memory safe languages (MSLs) as a coding style debate. They’re treating them as a structural control that collapses whole vulnerability classes before software ever ships. By embedding bounds checks, lifetime rules, and race-detection directly into the language runtime or compiler, MSLs function like an ambient intrusion-prevention system that operates at build time, shifting risk from operational firefighting to tooling choices. That shift dovetails with forthcoming secure-by-design procurement rules and SBOM transparency. Organizations that can prove their codebase is generated with a memory-safe toolchain will be able to quantify and insure residual risk far more cheaply than those stuck chasing buffer-overflow advisories. Rust exemplifies this economic flip because it offers C-level performance while forcing every pointer to carry an ownership lineage the compiler can verify effectively turning the borrow checker into a static zero trust policy for memory. Its unsafe blocks cordon off the remaining high risk code and make that perimeter explicit, auditable, and small. Instead of scattering latent use after free conditions across millions of lines, Rust localizes what can go wrong into reviewable silos, turning hidden technical debt into a measurable and therefore contractible surface.”
J Stephen Kowski, Field CTO at SlashNext, notes that the Android success story contains lessons beyond simply shifting to the right language: “The CISA-NSA guidance represents a long-overdue recognition that traditional approaches to memory safety have hit their limits. 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. The key insight from Android’s success story 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. Smart organizations are already implementing automated analysis tools that can detect memory safety issues across both legacy and modern codebases, giving them the intelligence they need to prioritize their modernization efforts effectively.”
And Ngoc Bui, Cybersecurity Expert at Menlo Security, notes that rapid adoption of a new language can present its own unique security challenges: “Ransomware was big into using memory safe languages (MSLs), such as Rust and Go, for a while more than a decade ago. Several factors contribute to the adoption of these newer languages by malicious actors. It was speculated at one time that it was an anti-analysis technique as analysts had a learning curve to adjust to the new usage. This learning curve creates a window of opportunity for attackers. Rust also has cross-platform capabilities, so it can simultaneously target Windows, Linux, and ESXi computers. This efficiency is particularly attractive in the ransomware landscape, where maximizing impact is a key objective.”
