Memory Safety Is Now a National Security Issue — Why the US and EU Want Developers to Stop Writing C

In February 2024, the US Cybersecurity and Infrastructure Security Agency published a 19-page report titled "The Case for Memory Safe Roadmaps." The White House Office of the National Cyber Director followed with a technical report urging software manufacturers to eliminate memory safety vulnerabilities. The UK's National Cyber Security Centre, Germany's BSI, and the Australian Signals Directorate co-signed. The message from all five agencies was identical: stop writing safety-critical software in C and C++.

This is not a fringe position among academics who prefer Haskell. It's the coordinated security policy of the world's major intelligence and cybersecurity agencies, backed by two decades of vulnerability data, and it's beginning to change what software actually ships.

What Memory Safety Means

Memory safety is the property that a program cannot read or write memory outside the intended bounds, access freed memory, or use uninitialized values. Languages enforce memory safety either through garbage collection (Java, Python, Go) or through static ownership rules enforced at compile time (Rust). C and C++ provide neither: the programmer is responsible for managing memory correctly, and the compiler does not verify correctness.

The consequence is a class of bugs that has persisted since C's creation in 1972: buffer overflows, use-after-free vulnerabilities, null pointer dereferences, heap corruption, and type confusion. These are not exotic edge cases — they are the most exploited vulnerability class in the wild, consistently accounting for 60–70% of critical CVEs in major software projects.

Microsoft's Security Response Center reported in 2019 that approximately 70% of all CVEs in Microsoft products over the previous 12 years were memory safety issues. Google's Project Zero reported in 2020 that 67% of Chrome's high-severity bugs were memory safety related. Both figures have remained stubbornly consistent through 2026 despite significant investment in tooling (fuzzing, sanitizers, static analysis) — because the underlying problem is the language model itself, not insufficient quality of the programmers using it.

The Scale of the Inherited Problem

The severity of the current situation is a function of how much critical infrastructure runs on C code. The Linux kernel — the foundation of most servers, Android devices, IoT hardware, and embedded systems — is approximately 97% C. The OpenSSL library that secures most HTTPS traffic is C. SQLite, the most deployed database in the world, is C. The V8 JavaScript engine that runs half the world's web browsing is C++. Windows, macOS, and iOS kernels contain tens of millions of lines of C and C++.

Rewriting any of these is not a multi-month project. The Linux kernel is approximately 30 million lines of code, with contributors across thousands of organizations and a change process that moves at geological speed by design. The Google Chrome codebase is 40 million lines. Asking "why not just rewrite it in Rust?" misunderstands the scale: at a rewrite rate of 1 million lines per year per team, a full codebase rewrite takes decades and introduces new bugs at every step.

The practical approach is incremental replacement: rewrite the highest-risk components first (parsing, network input handling, cryptography), use language interoperability to run Rust modules alongside C, and accept that the legacy C substrate will exist for 20–30 years while being progressively isolated.

Rust's Trajectory

Rust, first released in 2015 by Mozilla, is the primary memory-safe systems language being adopted for this transition. Its ownership-and-borrowing type system prevents the entire class of memory safety bugs at compile time, with no garbage collection overhead and near-C performance. The tradeoff is a steep learning curve: Rust's compiler rejects code that a C compiler would accept, because the Rust compiler proves correctness that C leaves to the programmer.

The adoption curve is now steep enough to represent a structural shift. Google has rewritten significant portions of Android's Bluetooth and WiFi stacks in Rust; the Android team reported in 2024 that new code in memory-safe languages had dropped the memory safety CVE rate for those components to near zero while legacy C components maintained their historical vulnerability rate. The Linux kernel formally accepted Rust as a second implementation language in 2022, and the first Rust drivers have been merged into the mainline kernel.

Microsoft's Windows team is rewriting components of the Windows kernel in Rust, with a long-term goal of preventing new memory safety bugs from entering the kernel codebase. The NSA's 2022 guidance specifically named Rust, Swift, Go, Kotlin, and Java as preferred languages for new development in national security contexts. The EU Cyber Resilience Act, which came into effect in 2025, requires manufacturers of products with digital elements to demonstrate "secure by design" practices — legal language that implicitly penalizes memory-unsafe languages in safety-critical contexts.

What "Memory Safe" Doesn't Solve

The policy push for memory-safe languages is well-evidenced but sometimes oversold. Memory safety prevents a specific class of bugs — but it does not prevent logic errors, authentication failures, injection vulnerabilities, or cryptographic implementation mistakes. A Rust program can have a SQL injection vulnerability just as easily as a C program. A Go program can have a business logic error that allows privilege escalation. Memory safety is a necessary condition for security, not a sufficient one.

There's also a meaningful distinction between "safe" and "unsafe" Rust. The Rust standard library contains unsafe blocks — sections where the programmer explicitly disables the ownership checks for performance-critical code. These unsafe regions must be manually verified, and vulnerabilities in them are possible. The CVE-2022-21658 race condition in Rust's standard library, for example, existed in a carefully reviewed std::fs implementation. Rust makes unsafe code rare and highly visible, but does not eliminate it.

The performance argument against memory-safe languages has largely been resolved empirically. In most workloads, Rust performs within 5–15% of equivalent C code, and in some benchmarks outperforms C because the compiler can make more aggressive optimizations when it has proven aliasing and lifetime guarantees. The overhead that remains is mostly in pathological cases, not in the kind of systems code that handles network packets, filesystem operations, or protocol parsing.

The Next Ten Years

The government pressure is having measurable effects. CISA's Secure by Design initiative, launched in 2023, has collected pledges from over 200 major software vendors to create memory safety roadmaps — concrete plans to migrate specific codebases away from C and C++ on a published timeline. The first annual progress reports from those vendors showed modest but real movement: new modules in Rust, deprecated unsafe APIs, migration of highest-risk parsing components.

The realistic timeline for meaningfully reducing memory safety vulnerabilities across critical infrastructure is 15–20 years. The code being written today in Rust will be in production for decades; the legacy C still running will be the source of critical vulnerabilities for an equivalent period. The policy question is not whether to make this transition — the evidence is overwhelming that C and C++ create unacceptable security risk at scale — but how aggressively to push the transition speed given the engineering costs and the risks of introducing new defects during migration.

What's changed is that this is now a policy question, not an academic one. When CISA calls something a national security issue and the White House signs a technical report, procurement requirements and regulatory guidance follow. The momentum behind memory-safe language adoption is no longer driven only by developer preference — it's being codified into government contracts, EU product liability rules, and insurance requirements. C and C++ will remain in use for decades, but their position as the default choice for new security-critical systems is over.