Memory-Safe Programming: What the White House Wants

The White House wants the U.S. government and software industry to move away from memory-unsafe programming languages in favor of memory-safe ones, especially for new software and high-risk systems. The goal is to reduce vulnerabilities caused by errors such as out-of-bounds access and use-after-free bugs—not to ban particular languages or require every existing program to be rewritten.

What the White House called for

The call gained prominence in a February 2024 report from the White House Office of the National Cyber Director (ONCD), titled Back to the Building Blocks: A Path Toward Secure and Measurable Software. It urged the technology ecosystem to prioritize memory-safe programming languages and secure software development practices. The report framed memory safety as a way to address a persistent source of security defects at their origin.

The recommendation is part of a broader U.S. government effort to improve software security, rather than a standalone law that dictates which language every developer must use. The report encourages software makers, customers, educators, and government organizations to support a transition. It also recognizes that changing the foundations of widely used software takes time.

In short, the policy direction is: use memory-safe languages for new development where practical, reduce memory-safety risks in software that must remain in unsafe languages, and make security measurable and prioritized throughout development.

Why memory safety matters

Programs use memory to store information while they run. In some languages, programmers have direct control over allocating, accessing, and releasing that memory. That control can be useful for performance and low-level system work, but mistakes can let a program read or change the wrong part of memory.

Common memory-safety errors include:

• Out-of-bounds access: reading or writing beyond the limits of an array or buffer.
• Use-after-free: using a pointer to memory after it has been released.
• Double free: releasing the same memory more than once.
• Uninitialized memory: using a value before it has been given a valid initial state.

Depending on the program and circumstances, such mistakes can cause crashes, expose data, or create opportunities for an attacker to influence program behavior. They are not the only kinds of software vulnerabilities: authentication failures, insecure design, and incorrect permission checks can occur in memory-safe code too.

ONCD’s report points to research estimating that memory-safety issues account for a large share of vulnerabilities in some major software projects. Such findings help explain why governments and technology companies have focused on the issue, but they do not mean that every vulnerability—or every security incident—has the same cause.

What makes a language memory-safe

A memory-safe language or runtime prevents or detects certain invalid memory operations, either through design, automatic management, or checks performed as a program runs. Languages commonly cited as memory-safe include Rust, Java, Go, C#, Swift, and Python, though their guarantees differ and depend on how the program is written and what components it uses.

For example, a language may automatically manage memory so developers do not manually free objects. Another may use ownership rules and compile-time checks to prevent many invalid references. Runtime bounds checks can stop an out-of-range array access rather than allowing it to silently affect unrelated memory.

“Memory-safe” does not mean “bug-free” or “secure in every way.” Some languages permit unsafe operations for special cases, and programs can depend on libraries written in memory-unsafe languages. A memory-safe application can still contain logic errors, leak information, or mishandle user input. The term describes a particular class of protections, not a complete security guarantee.

What the transition could look like

Replacing a mature system all at once is often unrealistic. Operating systems, browsers, embedded devices, and other infrastructure may include decades of code, performance constraints, and interfaces with hardware or existing software. A gradual transition can focus effort where it is most useful:

1. Choose memory-safe languages for new components when the language, tooling, performance, and platform needs fit.
2. Prioritize risky or exposed code for rewriting, isolation, or more intensive review.
3. Reduce unsafe code in existing projects through safer libraries, compiler checks, testing, and careful interfaces.
4. Track progress with measures such as the amount of code written in memory-safe languages and the location of remaining unsafe components.

This approach avoids treating a language switch as a magic fix. Teams still need design reviews, testing, dependency management, vulnerability response, and secure development practices. A rewrite can itself introduce defects, so the benefits and risks must be considered for each project.

Is the White House banning C and C++?

No. The ONCD report advocates a direction of travel, not a blanket ban on C, C++, or other languages. These languages remain important in system software and other settings where developers need close control over hardware or existing interfaces. The recommendation is to avoid adding memory-unsafe code unnecessarily and to adopt safer alternatives when they can meet the requirements.

Organizations may also improve existing C or C++ code without rewriting it. Options include using safer subsets and libraries, enabling compiler protections, applying static analysis, fuzz testing, and isolating sensitive components. These measures can lower risk, but they do not provide the same guarantee as preventing a class of memory errors by construction.

What it means for developers and organizations

For an individual developer, the practical question is not simply “Which language is safest?” It is whether a language’s safety model and ecosystem suit the task, and whether the team understands how to use them correctly. A memory-safe language may reduce the burden of checking pointers and lifetimes, while still requiring careful attention to validation, authorization, and dependencies.

For organizations choosing software, the policy discussion encourages asking vendors how they manage memory-safety risks, whether new components use memory-safe languages, and what protections apply to legacy code. The answers should be specific: language choice is one factor among many, and a claim of memory safety is not a substitute for evidence about development and maintenance.

For education and workforce planning, the shift may mean teaching memory-safe approaches alongside the low-level concepts needed to understand existing systems. The aim is not to make programmers ignorant of memory, but to make common mistakes harder to introduce and easier to detect.

Frequently Asked Questions

What does “memory-safe programming” mean?
It means using language or runtime protections that prevent or detect certain invalid memory operations, such as out-of-bounds access and use-after-free. It does not prevent every type of software bug.

Which memory-safe languages does the White House recommend?
The ONCD report promotes memory-safe languages as a general approach; it does not mandate one language for all projects. Rust, Java, Go, C#, Swift, and Python are examples often described as memory-safe, with different protections and trade-offs.

Is the U.S. government requiring companies to rewrite old software?
The report advocates a transition and stronger software security practices, but it is not a universal rewrite mandate. Existing systems can be addressed gradually through safer components, mitigations, and targeted replacement.

Does memory-safe code mean software is secure?
No. Memory safety helps prevent one important category of defects. Software can still have insecure design, flawed access controls, vulnerable dependencies, or other bugs.

Why not just keep using C and C++?
They remain useful and widely deployed, particularly for low-level software. The policy argument is to use memory-safe alternatives for suitable new components and to reduce risks in code that stays in C or C++.

Related

• Why Is This the Best Graphics Card?
• Google vs Perplexity: Which Search Tool Is Better?
• What Should I Do With My Old Mac? Safe Options