Spectra Assure Free Trial
Get your 14-day free trial of Spectra Assure for Software Supply Chain Security
Get Free TrialMore about Spectra Assure Free Trial
Key takeaways
Just over a year ago, the U.S. Cybersecurity and Infrastructure Security Agency and the National Security Agency released their report on the state of memory-safe languages, and since then, momentum has been building for wider adoption of MSLs, fueled by several major technology providers and advances in AI-assisted coding.
The CISA/NSA report emphasized the vital importance of memory safety. It cited a 2019 study estimating that 66% of Common Vulnerabilities and Exposures (CVEs) for iOS 12 and 71% of CVEs for macOS Mojave stemmed from memory safety issues. And it underlined how severe the consequences of memory-safety vulnerabilities can be, ranging from data breaches to system crashes and operational disruptions. It pointed to a Google Project Zero review of exploits detected in the wild, which estimated that 75% of the CVEs used in those exploits were memory safety vulnerabilities.
Of the 58 in-the-wild zero days discovered in 2021, 67% were memory-safety vulnerabilities, Google found. Adopting memory-safe languages, the CISA/NSA report concluded, is a key strategy for improving software security and reducing the risk of costly incidents.
The report argued that defining memory-safety road maps and adopting best practices can meaningfully improve software resilience across the industry, stating, “Strategic [MSL] adoption is an investment in a secure software future.”
All of this has led to real action. Major cloud and software providers are no longer just endorsing MSLs such as Rust — they’re building them into production systems, and AI tools are starting to lower the cost of migrating decades-old code.
But the shift is far from settled. Security practitioners caution that legacy C and C++ code is too widely deployed and deeply embedded to replace wholesale and that MSLs solve only one category of vulnerability, not all of them.
Here’s what you need to know about the state of MSL adoption.
[ Webinar: Go hands on with a red team vs. the build pipeline ]
Boris Cipot, a security engineer at Black Duck Software, said awareness about memory safety is no longer the problem. We’ve stopped debating whether memory-related flaws are among the largest sources of security defects, and the industry is adopting MSLs. “Major technology providers such as Microsoft, Google, Amazon, Cloudflare, and parts of the Linux ecosystem are actively adopting Rust or other memory-safe approaches in production systems,” Cipot said.
“The recent NSA and CISA guidance reflects this shift by focusing not on whether memory-safe languages are beneficial, but on how organizations can realistically adopt them.”
—Boris Cipot
John Strand, owner of Black Hills Information Security, traces that shift to a specific milestone.
“When you started seeing Rust incorporated into the Linux kernel, that was kind of the opening shot in the race to see this become more mainstream. And I think we’re just going to see it become more mainstream moving forward.”
—John Strand
Not everyone expects a quick transition to MSLs. Jeff Williams, chief technology officer and co-founder of Contrast Security, foresees stubborn inertia.
“There is an entire mountain range of software built in non-memory-safe languages. And there is a tiny amount of action in the foothills to switch.”
—Jeff Williams
MSL adoption is best for new development, Williams said; rewriting software that already works is a massive undertaking with an uncertain payoff. Eliminating one class of vulnerability, he added, is likely to introduce others, and there’s no guarantee organizations will abandon software versions already proven in production.
Dmitry Polyakovsky, a lead principal platform software engineer at Oracle, concedes that point but nonetheless expects Rust to continue to make inroads even as legacy C and C++ code remains in place.
“Rust can be a bridge for integrating new features into existing complex C/C++ codebases. As more developers become comfortable with Rust, new projects will be started in Rust from the beginning.”
—Dmitry Polyakovsky
The sheer volume of legacy code is only one factor slowing the shift toward MSLs such as Rust, said Jason Soroko, a senior fellow at Sectigo. Migration is gradual, he said, because teams must learn new tools, preserve compatibility, and verify that replacements meet performance requirements without changing behavior. A full rewrite can introduce new errors and disrupt working systems, which is why the NSA/CISA guidance recommends starting with new code and targeting components that handle untrusted files or network traffic.
“Mixed systems make sense where dependencies or operational constraints prevent replacement, but retained code still needs hardening and testing.”
—Jeff Williams
AI is emerging as a tool for migrating legacy code, Soroko said, pointing to Google’s Gemini-assisted rewrite of giflib, a GIF image library, as an early proof point: Google’s Rust replacement was unaffected by a memory-corruption flaw later disclosed in the original C library, meaning migrated systems never needed a patch for that flaw.
John Bambenek, president of Bambenek Consulting, said the benefit extends beyond the systems that migrate outright.
“Having memory-safe libraries not only protects memory-safe applications, but also helps protect applications written in non-memory-safe languages. … Anything that reduces the attack surface is a win.”
—John Bambenek
The process isn’t fully automated, Soroko cautioned. The initial AI-generated interface in the Gemini rewrite contained memory-handling defects, and human experts had to review the unsafe code before it could ship. “AI helped write the replacement, but deployment still required evidence that it worked,” he said.
Bambanek noted that AI is greatly accelerating vulnerability discovery. That being the case, preventing entire classes of memory bugs can reduce the workload of finding, fixing, and distributing patches one at a time. In effect, he said, it makes memory safety part of managing the patching load, not just a coding best practice. “AI vulnerability discovery really is at-scale fuzzing and code analysis,” he said. “If you take away the possibility of buffer overflows entirely, that’s a huge chunk of the problem space gone.”
Memory-safe code isn’t immune to every flaw, Soroko warned; logic errors and legacy interfaces remain places where memory safety can fail. David Svoboda, a software security engineer at the CERT Division of the Software Engineering Institute at Carnegie Mellon University, made the same point more bluntly.
“Memory-safe languages are not a panacea. While they make memory-safety problems manageable, they can leave code vulnerable to other problems, such as leaking sensitive information.”
—David Svoboda
Black Duck’s Cipot said large-scale rewrites have historically been limited by available engineering resources, but AI may be changing that calculus. “Google’s experiment suggests that AI may become a practical accelerator for modernizing legacy code and migrating security-sensitive components to memory-safe languages,” he said.
That doesn’t mean AI can safely rewrite every C or C++ project on its own, he cautioned; human review, testing, validation, and security analysis remain essential. Still, he said, the experiment offers evidence that AI-assisted migration could become a viable strategy for reducing technical debt and improving memory safety at scale, and it could lower one of the biggest barriers to adoption: the cost of converting existing codebases.
Contrast Security’s Williams called the use of AI to rewrite C libraries in Rust a “fantastic use case that we should try to scale.” Testing a rewrite against an existing library as a model, he explained, makes it possible to verify with a high degree of certainty that the behavior hasn’t changed.
The progress is real, but Williams was careful to put it in context. The shift away from non-memory-safe languages started when Java was released in the 1990s, he pointed out, and three decades later, C and C++ remain everywhere.
“Ultimately, security is only one of a dozen different reasons that a developer might choose a particular language. And it’s probably not the first one on the list. So I’d be willing to bet that we’ll still be dealing with buffer overflows in another 30 years.”
—Jeff Williams
Attackers turned the trusted AsyncAPI CI/CD publishing pipeline against its users, and the provenance checks all came back clean.
AI coding requires the stack be reconstructed with mathematical proofs built in — a task well suited to the Lean language. Here’s the reality.
