Microsoft analyzed a decade of their security bulletins and found roughly 70 percent of critical vulnerabilities were memory safety bugs. Google found roughly the same number in Android and Chromium. The NSA published an advisory recommending memory-safe languages by name. The conclusion is industry-wide and unusually unanimous: the problem isn't bad programmers, it's the languages.

In 2019, Microsoft Security Response Center engineer Matt Miller presented an analysis of roughly a decade's worth of Microsoft's published vulnerabilities. The number that travelled around the industry was 70%: of Microsoft's serious, externally exploitable bugs, about seventy percent were caused by memory safety errors. Google's Project Zero, looking at Chromium, reported a remarkably similar number. Android's security team, looking at native code, found that memory safety vulnerabilities accounted for the majority of high-severity Android security bugs as well.

In late 2022, the NSA published a Cybersecurity Information Sheet titled "Software Memory Safety," recommending that organizations move to memory-safe languages where possible and listing Rust, Go, Swift, Java, C#, and Python as examples. The CISA followed in 2023 with similar guidance. When an intelligence agency publishes a software engineering style guide, the industry has reached an unusual point of consensus.

What "Memory Safety" Actually Means

Memory safety is the property that a program cannot access memory it has no right to access. In a memory-safe language, the runtime, compiler, or both prevent a series of categorical bugs:

• Buffer overflows — writing past the end of an allocated region
• Use-after-free — accessing memory after it's been returned to the allocator
• Double-free — freeing the same allocation twice
• Null pointer dereferences — using a pointer that doesn't point at a valid object
• Uninitialized memory reads — reading values that were never written
• Type confusion — interpreting a chunk of memory as the wrong type

Each of these is a different mechanism, but they share a common feature: they let an attacker influence values the program treats as trusted. A buffer overflow can overwrite a return address, redirecting control flow. A use-after-free can be massaged so that the freed memory is reallocated as something attacker-controlled, then accessed as the original type. Decades of attacker craft have turned these bugs into reliable exploitation primitives.

Why C and C++ Are Where Most of These Live

C and C++ trust the programmer to be correct. The languages let you take a pointer, do arithmetic on it, and dereference the result. They let you free a pointer and use it again — they don't even warn you. They let you cast between pointer types with no runtime check. Each of these features is a power, and a hazard.

Programmers can write correct C. Some do, for a while, on small programs. At scale, with large teams, deadline pressure, and decades of accumulated code, mistakes are statistically inevitable. The industry's experience is consistent across companies and projects: memory safety bugs slip past code review, slip past testing, and ship.

Not a competence question. The teams writing the affected code at Microsoft, Google, Mozilla, Apple, and the kernel projects are world-class. The persistence of memory safety bugs at those organizations is the clearest possible evidence that the problem isn't programmer skill — it's that the language tolerates errors a more restrictive language would refuse to compile.

The Modern Memory-Safe Languages

Memory-safe languages take one of two general approaches: a runtime checker, or compile-time enforcement.

Java, C#, Python, JavaScript, Go, Ruby, and most modern application languages use garbage collection plus runtime bounds checking. Memory is managed by the runtime; the programmer cannot create dangling pointers or overrun an array without an exception. The trade-off is performance overhead and a runtime dependency — fine for application code, problematic for the lowest layers of an operating system or a cryptographic primitive.

Rust takes the second approach. Its compiler enforces a system of ownership and borrowing that statically prevents the categorical memory errors. There's no garbage collector and no runtime overhead — Rust compiles to native code with performance comparable to C. The price is that you have to convince the borrow checker your code is correct, which is harder than just writing it. Once it compiles, the program is provably free of the bug classes above.

Where Rust Is Replacing C

The places where memory safety matters most — operating system kernels, browser engines, networking code, cryptographic libraries — are exactly where C has dominated for fifty years. Rust is the first credible challenger because it doesn't impose a garbage collector or a runtime, which is what makes C indispensable in those contexts.

• Linux kernel — Rust support was merged in 2022; drivers and modules can now be written in Rust within the kernel tree.
• Android — Google has been writing new native components in Rust since 2021. Their reported result: zero memory safety vulnerabilities in Rust code shipped to production.
• Chromium — Google has begun adopting Rust for new components, with the QR code generator and others now in Rust.
• Firefox — Mozilla developed Rust originally; large parts of Firefox's CSS engine (Servo, Stylo) are Rust.
• Windows — Microsoft has rewritten parts of Windows kernel components in Rust, including portions of the DirectWrite font shaping library that had been a recurring source of exploits.
• cURL — The HTTP/HTTPS backend can now optionally be backed by Rust-written libraries.

The Counter-Arguments, Honestly

No language change comes for free. The serious objections to "just rewrite in Rust" deserve direct answers.

Rewriting C is expensive and risky

Absolutely true. A large, mature C codebase represents enormous accumulated effort and bug-fixing. Rewriting it from scratch loses that history. The pragmatic answer most projects have adopted is incremental: keep the existing C, write new components in Rust. Android's data on this is encouraging — most of their memory safety bugs were in new code, not the long-lived components. Writing new code in Rust closes the dominant pipeline of fresh vulnerabilities without touching legacy.

Rust has its own complexity

Also true. The borrow checker is hard to learn. Async Rust is harder still. Programmers who internalized C's mental model often find Rust frustrating for the first few months. The honest assessment: there is a real learning cost, and the value depends on the domain. For application code that's never going to run on the bare metal, garbage-collected languages remain easier and probably enough. For systems code where C was the only choice, Rust's complexity is a worthwhile trade against C's exploitation history.

What about unsafe Rust?

Rust has an unsafe escape hatch — small blocks where the borrow checker stands down so you can do things like raw pointer arithmetic, FFI, or manual memory management. Critics point out that unsafe Rust is just C-with-extra-steps. Defenders point out that unsafe is typically a tiny fraction of a codebase, audited separately, and grep-able. The mainline of a Rust project is safe; the unsafe blocks are the part you focus security review on.

What About Hardware Mitigations?

The industry didn't sit still waiting for language change. Modern hardware has accumulated layers of mitigation — stack canaries, ASLR, DEP, control flow integrity, pointer authentication on ARM64. These make exploitation harder but don't eliminate the underlying bugs. They're a defense-in-depth layer, not a replacement for safety. The result over time is a slow arms race: each new mitigation raises the bar for exploitation, attackers adapt, the bar rises again. Memory-safe languages cut the loop by eliminating the bug class.

The Industry Trajectory

Why This Matters Beyond Programmers

Memory safety bugs aren't a programmer-only concern. They are the most common mechanism for the privilege-escalation and remote-code-execution bugs that turn into real incidents. The browser tabs you trust, the messaging clients you depend on, the operating systems your devices run — all of them have shipped exploitable memory safety vulnerabilities in the last decade. Moving the foundation toward languages where those bugs are categorically impossible is not a stylistic choice. It is the largest single available improvement in software security, and the industry's biggest names have agreed on it.

The cost is real. The transition is slow. But the trajectory is clear, and twenty years from now, the share of the software stack running in C and C++ will be smaller — by deliberate engineering, not nostalgia.

Originally published at havenmessenger.com