Google projects the number of reported Android memory safety flaws to be 36 by the end of 2024, down from 220+ in 2019, after adopting memory safety in new code
https://security.googleblog.com/ ... Chandler Carruth / @chandlerc@hachyderm.io : Proud to start sharing Google's strategy for tackling our remaining memory safety challenges: https://security.googleblog.com/ ... It's high level, but it outlines the long-term strategy. We'll be sharing more detailed posts in this series. — #CPlusPlus #RustLang #CarbonLang X: Richard Geldreich / @richgel999 : Looks like C++ is on the way out for many larger commercial projects. Turns out security matters. https://security.googleblog.com/ ... [image] Alex Rebert / @ayper : Excited to share Google's memory safety strategy! We're working to build safer software by migrating to memory-safe languages like Rust as well as hardening our existing C++: https://security.googleblog.com/ .... We'll be sharing more details in upcoming posts. Heather Adkins / @argvee : A few words about @Google's approach to memory safety from the engineers on the front lines! It's important we not leave the same mess that the generations before us left us. https://security.googleblog.com/ ... Chandler Carruth / @chandlerc1024 : Proud to start sharing Google's strategy for tackling our remaining memory safety challenges: https://security.googleblog.com/ ... High level, but it outlines the long-term strategy. We'll be sharing more detailed posts in this series. #CPlusPlus #RustLang #CarbonLang
Context & Ripple Effects
Google’s Android work has been building toward language-level prevention rather than relying solely on exploit mitigations: the Android Open Source Project added Rust support for OS development in 2021. That approach follows earlier evidence that memory errors made up a large share of serious bugs in C/C++ code, including Google’s Chrome security-bug analysis.
The new projection extends a September update in which Google attributed a sharp decline in Android’s vulnerability mix to moving new code to memory-safe languages. It matters because it connects that engineering strategy to the remaining volume of reported Android flaws, not just a percentage share.
First-order effects
- Android engineering and security teams can concentrate remediation effort on the shrinking set of legacy memory-unsafe components while keeping new code on memory-safe paths.
- The projected reduction gives Google a concrete measure for judging its combined approach of adopting memory-safe languages and hardening existing C++.
Second-order effects
- Teams maintaining Android-adjacent native code face stronger incentives to adopt memory-safe components or improve C++ hardening, since new-code choices become part of the platform’s security baseline.
- Security investment may shift from repeatedly mitigating classes of memory bugs toward finding the legacy areas and integration boundaries that remain exposed.
Third-order effects
- If this pattern persists, memory safety is likely to become a standard platform-engineering requirement rather than a language preference, raising the long-term cost of retaining unsafe native code.
- The transition will be incremental: the remaining risk is concentrated in existing code, so results will depend on migration and hardening execution rather than new-language adoption alone.
The trend: Large software platforms are treating memory-safe development as foundational security infrastructure while managing the long tail of legacy C++ code.