In February 2024 the White House Office of the National Cyber Director published Back to the Building Blocks. It argues that the programming language is the most effective place to remove memory safety vulnerabilities, with memory safe hardware and formal methods as complementary tools, and calls for better software measurability.
The core argument
The report says fixing known vulnerabilities is not enough, because undiscovered ones remain. A better move is to eliminate whole classes. It names memory safety as one of the most pervasive classes and points to the Morris Worm of 1988, Slammer in 2003, Heartbleed in 2014 and the BLASTPASS exploit chain of 2023 as examples facilitated by memory safety bugs.
On languages, it says using memory safe languages can eliminate most memory safety errors, and that for most cases it is the most efficient way to improve software security. It also says there are no silver bullets and a memory safe language cannot remove every risk.
Three approaches
- Memory safe languages. Build new products in them from day one. For existing code, take a hybrid approach: pick critical functions or libraries by risk and rewrite those first.
- Memory safe hardware. The report mentions memory tagging (MTE), which can detect memory bugs but is not a comprehensive fix, and CHERI, an architecture that changes how software accesses memory.
- Formal methods. Techniques such as sound static analysis, model checkers and assertion based testing can show that classes of bugs are absent, though deployment remains limited.
The space systems edge case
The report examines space systems, where a language must sit close to the kernel, behave deterministically and not rely on a garbage collector. At the time, the most widely used languages with all three properties were C and C++. Rust has the properties but had not yet been proven in space systems, so hardware approaches were suggested in the interim.
The measurability half
The second half argues that the industry lacks good metrics for software security quality, citing three challenges from a 2016 NIST workshop: metrology, software behavior and software analysis. This part is less about code and more about incentives.
What to take from it
- Pick the language at design time. It is an early architecture decision.
- Migrate the riskiest code first, not everything.
- Use hardware and tooling as a bridge, not a destination.
- Record your own measures, since the report says good ones are still missing.
How the report frames responsibility
A theme running through the report is that defenders should not carry the whole burden. It ties the memory safety argument to the National Cybersecurity Strategy, which calls for rebalancing responsibility toward those best placed to reduce risk and for realigning incentives toward long term investment. In practice that means software and hardware makers, not their customers, are the audience for the language advice.
The report also asks manufacturers to publish timely, complete and consistent CVE data including the weakness identifier. That is useful to you as a reader too: if a vendor records the weakness class, you can count memory safety fixes yourself. If it does not, you cannot.
What the report does not claim
It does not say that memory safe languages are free, or that migration is quick. It says the effort is ambitious and needs persistent, multi sector focus for years. It does not claim that hardware tagging solves the problem. And it does not set a deadline for anyone. If you see a post that cites it as a mandate, read the report text instead.
Quick check
Does the report say a memory safe language removes all risk?
No. It says memory safe languages cannot eliminate every cybersecurity risk, but are a substantial step toward removing broad categories of vulnerabilities.
What does it recommend for existing codebases?
A hybrid approach: identify critical functions or libraries by risk and rewrite those first.
Sources
Last reviewed: 19 October 2026.
