Updated October 2026: This post has been expanded from its original February 2024 version with a plain-language explanation of memory safety bugs, the evidence behind the policy, and the U.S. guidance that followed through 2025. It is a historical account; details describe the time it covers, not today.
On February 26, 2024, the White House Office of the National Cyber Director (ONCD) published a technical report titled Back to the Building Blocks: A Path Toward Secure and Measurable Software. Its headline message was aimed at the people who write code: stop creating new memory safety bugs by moving to programming languages that prevent them by design.
It was unusual for the White House to weigh in on something as specific as a choice of programming language. But the report argued that a single class of bug had been behind some of the most damaging attacks in computing history, and that the fix was well understood. This post explains what memory safety means, why the government cared, what evidence backed the push, and how the policy developed after 2024.
What a memory safety bug is
Every program stores data in memory and keeps track of where each piece lives. Languages such as C and C++ give programmers direct control over that memory. That control makes them fast and flexible, which is why they run operating systems, browsers, network equipment and embedded devices. It also means a single mistake can let a program read or write memory it should never touch.
The most common kinds of mistakes have names that show up again and again in security advisories:
- Buffer overflow: writing past the end of a block of memory and overwriting whatever sits next to it.
- Out-of-bounds read: reading past the end of a block, which can leak secrets such as passwords or encryption keys.
- Use-after-free: continuing to use memory after the program has released it, when it may now hold something else.
- Double free and uninitialized memory: releasing the same memory twice, or reading memory before anything has been stored in it.
Attackers use these bugs to crash programs, steal data or, in the worst cases, run their own code on a target machine. Memory-safe languages, such as Rust, Go, Java, C#, Swift and Python, add checks or rules that prevent most of these errors before the program ever runs, or stop them safely when they happen.
What the White House report said
The ONCD report made three broad recommendations. Technology manufacturers should adopt memory-safe programming languages to eliminate entire classes of vulnerabilities. Researchers should work on ways to measure software security, so that quality could be compared and tracked. And makers of software and hardware should treat cybersecurity outcomes as part of how products are built, not something added later.
To show what was at stake, the report pointed to a run of famous incidents that share a root cause in memory safety: the Morris worm in 1988, the Slammer worm in 2003, Heartbleed in 2014, the Trident exploit in 2016 and the BLASTPASS exploit in 2023. National Cyber Director Harry Coker framed it as a shared duty, saying the nation has “the responsibility” to reduce the attack surface in cyberspace.
The report also acknowledged limits. Coverage at the time noted that Rust, the language most often cited as a replacement for C and C++, had not yet been proven in some of the aerospace and other specialized systems the government most wanted to protect. Legacy code was another obvious constraint: no one expected decades of C and C++ to be rewritten overnight.
Part of a wider strategy
The report built on the National Cybersecurity Strategy of March 2023, which called for shifting responsibility for security toward the companies that build software, rather than leaving it to end users. It also followed guidance from the NSA, which had urged a move to memory-safe languages and listed examples including C#, Go, Java, Python, Rust and Swift, and a December 2023 paper from CISA and international partners encouraging companies to publish memory safety roadmaps.
The evidence behind the push
Two large software companies supplied much of the data that made the case. In 2019, Microsoft’s Security Response Center reported that about 70 percent of the vulnerabilities it assigns a CVE each year were memory safety issues, a share that had held steady for over a decade.
Google later published the clearest before-and-after example. Around 2019, the Android team began writing new code in memory-safe languages, such as Rust, while leaving most existing C and C++ in place. By 2024, memory safety bugs had fallen from 76 percent of Android’s vulnerabilities to 24 percent.
Google’s explanation of why this worked is the most useful part for anyone maintaining old code. Vulnerabilities cluster in new and recently changed code, and older code becomes safer as bugs are found and fixed. Google estimated that five-year-old code had 3.4 to 7.4 times lower vulnerability density than new code. So simply writing new features in a memory-safe language, without rewriting everything, cut the problem sharply. Google also reported that Rust changes were rolled back for problems less than half as often as C++ changes, a sign that safety did not come at the expense of productivity.
What happened next
- March 2023
National Cybersecurity Strategy calls for shifting security responsibility to software makers - December 2023
CISA and international partners urge companies to publish memory safety roadmaps - February 26, 2024
White House ONCD publishes Back to the Building Blocks - September 2024
Google reports Android memory safety bugs down to 24 percent - October 2024
CISA and FBI list memory-unsafe code without a roadmap as a product security bad practice - June 24, 2025
NSA and CISA publish Memory Safe Languages: Reducing Vulnerabilities in Modern Software Development - January 1, 2026
Target date for software makers serving critical infrastructure to publish a roadmap
In October 2024, CISA and the FBI published draft guidance on Product Security Bad Practices for companies whose software is used in critical infrastructure. It said that building new products in memory-unsafe languages when alternatives exist is dangerous, and that for existing products, not having a published memory safety roadmap by January 1, 2026, is dangerous too. The guidance was voluntary, and analysts were quick to point out that it did not demand an immediate migration from C and C++ to Rust. What it asked for was a plan.
In June 2025, the NSA and CISA followed with a joint information sheet, Memory Safe Languages: Reducing Vulnerabilities in Modern Software Development. It repeated that adopting memory-safe languages does not require rewriting existing code, described how new memory-safe components can work alongside old ones, and offered ways to make C and C++ safer where switching is not practical. It urged producers of national security systems and critical infrastructure software in particular to plan the move.
What this means for developers today
- Write new code in a memory-safe language where you can. Google’s data shows the biggest gains come from new code, not rewrites.
- Put a roadmap in writing. If you sell software to critical infrastructure customers, the U.S. guidance expects a published plan, and customers increasingly ask for one.
- Harden the C and C++ you keep. Turn on compiler warnings and hardening flags, run tools such as AddressSanitizer in testing, and fuzz code that parses untrusted input.
- Focus on the riskiest boundaries. Parsers, network protocol handlers and anything that processes files from strangers are where memory bugs are most often exploited, and the best candidates for memory-safe replacements.
- Use safe interoperability. Mixing languages adds its own risk at the boundary, so keep the interface between safe and unsafe code small and well tested.
And for everyone else
Most people never choose a programming language, but they benefit when vendors do. The practical step is the familiar one: install updates for your phone, browser and operating system promptly. Many of those updates still exist to fix memory safety bugs in older code.
The bottom line
The February 2024 report did not ban any language or set any deadline of its own. Its significance was that it put the White House behind an idea security engineers had argued for years: memory safety bugs are a preventable category, not an unavoidable cost of writing software. The guidance that followed turned that idea into a concrete expectation, a published plan to stop adding new memory-unsafe code, and the Android results showed that the approach works at scale.
Sources
- White House ONCD: press release on Back to the Building Blocks (archived)
- TechRepublic: White House recommends memory-safe programming languages
- Microsoft Security Response Center: A proactive approach to more secure code (2019)
- Google Security Blog: Eliminating memory safety vulnerabilities at the source (2024)
- The New Stack: CISA and FBI product security bad practices and the 2026 roadmap date
- NSA: NSA and CISA release CSI on memory safe languages (June 2025)
Top image: "Pile of Laptop & Desktop RAM Memory Modules" by Wilbysuffolk, CC BY-SA 4.0, via Wikimedia Commons (resized). Charts by Thank You Robot.
0 Comments