For decades, defenders have tried to make software written in C and C++ safer through code review, fuzzing, sandboxing, hardened allocators, compiler checks, and exploit mitigations. Those measures remain useful, but they have not removed a persistent class of defects: reads and writes outside valid memory, use of memory after it is freed, and data races that corrupt program state.

The policy response is changing. Memory safety is increasingly treated as an architectural property to select at the beginning of development, rather than a bug category to manage at the end.

A Repeated Source of Severe Vulnerabilities

Memory-unsafe languages give programmers direct control over allocation and pointers, which is valuable in kernels, drivers, browsers, and embedded systems. The same freedom allows code to access memory incorrectly. An attacker can sometimes turn that error into information disclosure or arbitrary code execution.

Microsoft reported in 2019 that roughly 70 percent of the security issues to which its response center assigned CVEs were memory-safety issues (Microsoft Security Response Center). The U.S. National Security Agency cited similar industry evidence when it recommended memory-safe languages in 2022. Its guidance was unusually direct: “We have to consistently use memory safe languages” (NSA).

Languages such as Rust, Java, C#, Go, and Swift prevent or constrain broad classes of invalid memory access. They use different mechanisms—ownership and borrowing, garbage collection, bounds checks, or managed runtimes—and therefore suit different workloads. Memory-safe does not mean bug-free. Logic flaws, authorization errors, unsafe foreign-function calls, vulnerable dependencies, and denial-of-service conditions remain possible. The narrower claim is important: code cannot express many dangerous memory operations in ordinary safe language constructs.

Evidence From Production Code

Android provides one of the clearest public case studies. Google began prioritizing memory-safe languages for new platform code around 2019 and added Rust support to the Android Open Source Project. In 2024, Google reported that memory-safety defects had fallen from 76 percent of Android vulnerabilities in 2019 to 24 percent, while most existing code was still memory-unsafe (Google Security Blog). The result supports an incremental strategy: stop adding large quantities of new unsafe code, allow older code to age, and replace risky components at natural boundaries.

The same account offers a useful operational counterpoint to fears that safety necessarily costs performance. Google said rollback rates for Rust changes were less than half those for C++, and described a Rust QR-code component in Chromium that could run without its former sandbox and was substantially faster. A separate Android firmware case study found Rust comparable to C in performance and code size while supporting no-overhead interoperability at carefully designed interfaces (Google Security Blog). These are vendor measurements, not universal laws, but they show that migration can produce engineering benefits beyond security.

Policy Is Creating Organizational Pressure

Memory-Safe Programming Languages Are Becoming a Security Priority — supporting image
Memory-Safe Programming Languages Are Becoming a Security Priority — supporting image

The White House Office of the National Cyber Director's February 2024 technical report called memory-safe languages a secure building block and encouraged their use for new products (ONCD). CISA then urged manufacturers to publish memory-safety roadmaps and extended the discussion to critical open-source dependencies (CISA). In June 2025, NSA and CISA emphasized that adoption need not require a wholesale rewrite and described interoperability as a practical migration tool (NSA).

That distinction matters. A rewrite can recreate old logic bugs, interrupt feature work, and fail before it delivers security value. A roadmap should instead classify code by exposure and consequence. Parsers handling untrusted network data, cryptographic key services, privileged agents, and new kernel modules deserve earlier attention than stable, isolated code with strong containment.

Migration Is a Systems Program

Language choice alone is insufficient. Organizations need supported toolchains, reproducible builds, dependency review, observability, developer training, and rules for `unsafe` blocks and foreign-function boundaries. They must decide which runtime and certification constraints apply to firmware or real-time systems. Existing C and C++ still require fuzzing, sanitizers, control-flow protections, and rapid patching throughout a long transition.

Procurement can accelerate the shift by asking vendors for measurable roadmaps: the share of new privileged code written in memory-safe languages, the inventory of unsafe dependencies, controls at language boundaries, and vulnerability trends. These measures are more informative than demanding an immediate percentage of an entire legacy codebase be rewritten.

Memory safety is becoming a security priority because it changes the economics of defense. Preventing a defect class at compile time is generally more scalable than repeatedly finding, patching, and mitigating its consequences. The durable strategy is not a slogan about one language; it is a managed reduction of unsafe code where failure matters most.

Sources