Memory-safe code mandates are reshaping how Google, Microsoft, and the Linux kernel write systems software

In February 2024, the White House Office of the National Cyber Director published a report with an unglamorous title and a blunt argument: roughly 70 percent of the vulnerabilities Microsoft and Google each patch every year trace back to memory-safety bugs — buffer overflows, use-after-free, out-of-bounds reads — the exact class of error that C and C++ make easy to write and hard to catch. Two years later, that argument has stopped being a talking point and become a line item in how the biggest software vendors plan new work.

Google's own transparency reporting on Android is the clearest evidence this isn't just rhetoric. In 2019, memory-safety bugs accounted for roughly 76 percent of Android's serious vulnerabilities. By the most recent reporting, that share has fallen to the low 20s — not because old C and C++ code was rewritten, but because the policy changed: new code added to Android since 2019 has defaulted to memory-safe languages, mostly Rust and Kotlin, and the vulnerability rate in that new code has tracked near zero. Google's conclusion, stated plainly in its own security blog: the risk in a codebase is proportional to how much new unsafe code you keep writing, not to the total size of the codebase.

Where the rewrites are actually landing

The Linux kernel is the most consequential test case, because kernel bugs are the highest-value target in the industry — a single memory-safety flaw in a driver can become a sandbox escape or a full system compromise. Rust support merged into the mainline kernel in late 2022, and by 2026 it is no longer experimental plumbing. Production Rust drivers now exist for NVMe storage controllers, for Android's Binder IPC mechanism — one of the most heavily attacked kernel surfaces on every Android phone — and for Apple Silicon GPUs through the Asahi Linux project's AGX driver. None of these replace existing C code wholesale; they're new subsystems or rewrites of specific attack-prone components, chosen because they sit directly in the path of untrusted input.

Microsoft has been quieter in public messaging but just as active internally. Azure CTO Mark Russinovich has said publicly that new systems projects at Microsoft default to Rust unless there's a specific reason not to, and components of Windows's text and font rendering stack — historically a rich source of remote-code-execution bugs because fonts are untrusted, attacker-controlled input parsed deep in the kernel — have been rewritten in Rust as DWriteCore. Font parsing is a textbook case for why this matters: it's exactly the kind of code that takes attacker-supplied bytes and does pointer arithmetic on them.

Chrome has taken a narrower but still telling approach. Rather than a wholesale rewrite, Google has pushed Rust into specific high-risk parsers — image codecs, JSON, certain network protocol handling — while leaving the bulk of Chromium's C++ in place and hardening it with techniques like MiraclePtr, which turns use-after-free bugs into safe crashes instead of exploitable memory corruption. That's the realistic middle path for a 30-million-line codebase: new parsers in Rust, old code hardened rather than rewritten.

Why C and C++ aren't disappearing

None of this adds up to the end of C and C++. The economics don't work for a wholesale rewrite: decades of tested, performance-tuned code, enormous hiring pools of C/C++ engineers, and toolchains built around those languages for everything from embedded firmware to game engines. What's changed is narrower and more durable than a language war — it's a policy about where new code gets written, applied selectively to the components that face untrusted input directly: parsers, drivers, network stacks, anything that touches a byte stream from outside the trust boundary.

The new risk this creates is at the seams. Every Rust component embedded inside a larger C/C++ codebase needs an FFI (foreign function interface) boundary, and FFI boundaries are where Rust's safety guarantees stop applying — an unsafe block on the Rust side, or a C caller passing a bad pointer, reintroduces exactly the bug class the rewrite was supposed to eliminate. Security teams at both Google and Microsoft have flagged FFI boundary review as the next hard problem, not a solved one.

What this means if you're not shipping a kernel

Most engineering teams aren't maintaining an OS or a browser, but the underlying lesson generalizes directly:

• New code that parses untrusted input is where the policy should apply first. If you're writing a new parser, deserializer, or protocol handler in 2026, defaulting to Rust, Go, or another memory-safe language is a much easier sell to a security reviewer than it was five years ago — the tooling, library ecosystem, and hiring pool have all matured.
• Legacy C/C++ you can't rewrite should get sanitizer coverage and fuzzing, not a rewrite project. AddressSanitizer, MemorySanitizer, and continuous fuzzing (libFuzzer, OSS-Fuzz) catch the same bug classes a rewrite would eliminate, at a fraction of the engineering cost, and they work today on code you have no plan to touch.
• If you sell software to the US federal government, check your CISA Secure by Design pledge status. Over 300 vendors have signed it, and the pledge includes a commitment to publish a memory-safety roadmap — not full compliance on day one, but a public plan with a timeline. If your company is a signatory and hasn't published that roadmap, that's a gap an auditor or a customer's security team will eventually ask about.
• Treat every new FFI boundary as a reviewable security artifact, not an implementation detail. If a Rust module and a C module talk to each other, that boundary deserves the same scrutiny a new parser would get, because it's where the safety guarantees actually end.