DevLogTechnical writing
Blogs

Memory Safety Isn't a Campaign Anymore — It's the Default Assumption

September 26, 2026

For a decade the loudest argument in security was about whether memory safety mattered enough to change how we build software. That argument is over. It did not end because someone won a debate. It ended because the numbers came in, the companies changed how they build, and then the governments and even the Linux kernel committed on paper.

The evidence that settled it was dull in the best way. A December 2023 CISA technical advisory committee report found that roughly 70% of serious security vulnerabilities reported to Microsoft and Google (Chrome) are memory-safety issues. Chromium puts its own high-severity figure around 70%, and about half of those are use-after-free bugs. Hardly anyone disputes the share anymore. The real question became what to do about it.

The answer came fastest from private industry, and Android is the clearest case study. Google reported on September 25, 2024 that memory-safety vulnerabilities fell from 76% of Android's vulnerabilities in 2019 to 24% in 2024. The severity picture was darker before the shift: a late-2022 Google note flagged that memory-safety issues were 86% of Android's critical-severity and 89% of its remotely-exploitable vulnerabilities that year. But the mechanism matters more than the headline. Android 12 introduced Rust as a platform language in 2021, and Android 13 was the first release where a majority of new code was memory-safe.

That last point is the real lesson. Google did not rewrite Android. It stopped writing new C and C++ for the riskiest layers and let old code age out, because the vast majority of vulnerabilities live in new or recently modified code. Turn off the tap of new memory-unsafe code and the total risk drops even while legacy code lingers. That is a playbook any team can follow without a grand rewrite.

Then the institutional commitments followed. CISA published "The Case for Memory Safe Roadmaps" in December 2023, and in February 2024 the White House's ONCD released "Back to the Building Blocks," arguing that manufacturers should build in memory-safe languages and treat the rest as a transition to manage. The Linux kernel merged initial Rust support in 6.1 in late 2022.

It would be dishonest to present the kernel story as frictionless. Rust for Linux lead Wedson Almeida Filho resigned in September 2024 citing "nontechnical nonsense," and Asahi Linux lead Hector Martin stepped down in February 2025. The path carried real human cost. Which makes the ending matter: at the December 10, 2025 Kernel Maintainers Summit, the assembled maintainers concluded that the Rust experiment is over — Rust is a core part of the kernel, here to stay.

The honest caveats still hold. This is no silver bullet. C and C++ are not disappearing, and rewriting mature code is usually a poor use of time. Mixed-language systems carry their own friction, and memory-safe languages still have plenty of other bug classes. But the cost of doing nothing is now measurable, and the industry has a workable playbook.

Here is the pragmatic takeaway for working developers: write your new code in a memory-safe language where you can. You do not need permission or a rewrite. Android proved the compounding payoff, the governments made it policy, and the kernel made it permanent. The debate is over. Build accordingly.

← More Blogs