Memory-Safe Languages and the Vulnerability Numbers: Vendor Claims Versus Independent Study

A memory-safety vulnerability is a bug that lets a program read or write memory it should not be able to touch — a buffer overflow, a use-after-free, a dangling pointer, an out-of-bounds array access. These bugs have been the single largest category of serious software vulnerabilities for decades, and they are disproportionately the ones attackers turn into working exploits rather than mere crashes. The US Cybersecurity and Infrastructure Security Agency cites figures from several vendors to make this point: Microsoft has said that roughly 70% of the CVEs it assigns each year are memory-safety issues, the Chromium project has put the same figure at around 70% of its serious security bugs, Mozilla found 32 of 34 critical and high-severity bugs in one review were memory-related, and Google's Project Zero found that 39 of 58 (67%) of the zero-day exploits it tracked in the wild were memory-corruption bugs, according to CISA's 2023 memory-safety briefing.

Languages like Rust, Swift and Java prevent most of these bugs structurally: the compiler or runtime refuses to generate code with unchecked raw pointer arithmetic unless a developer explicitly opts out. The question this piece looks at is narrower than "is Rust safer than C++" in the abstract. It is: what has actually been measured, by whom, over what time period, and what do those measurements not tell us.

The most detailed public dataset on this comes from Google's Android team, which has published its own internal numbers on memory-safety vulnerabilities every year since adopting what it calls "Safe Coding" — prioritizing memory-safe languages, chiefly Rust, for new code rather than attempting to rewrite the existing C/C++ codebase. In a 2024 post, Google engineers Jeff Vander Stoep and Alex Rebert reported that the share of Android's total vulnerabilities attributable to memory safety fell from 76% in 2019 to 24% by the end of 2024, a period over which the proportion of new code written in memory-safe languages rose substantially, according to Google's Security Blog.

Google updated the figure again in November 2025: memory-safety vulnerabilities fell below 20% of Android's total reported vulnerabilities for the first time, and the team estimated Rust code in Android carries roughly a 1,000-times lower memory-safety vulnerability density than the platform's C and C++ code — on the order of 0.2 vulnerabilities per million lines of Rust versus roughly 1,000 per million lines in the historical C/C++ baseline, according to Google's November 2025 post. The same post reported that Rust changes in Android spend about 25% less time in code review than comparable C++ changes, need roughly 20% fewer revisions, and have a rollback rate around four times lower for medium and large changes. Google also said that by the third quarter of 2025, the net amount of new first-party Rust code in Android slightly surpassed new C++ code for the first time, and it described one near-miss: a buffer-overflow flaw in the CrabbyAVIF image library, tracked as CVE-2025-48530, that was caught during development, before it shipped to any user, and, separately, would have been blocked at runtime by Android's Scudo hardened memory allocator even if it had shipped.

What independent measurement adds

Those numbers are Google's own telemetry on its own codebase, collected and reported by the team running the migration. That is a legitimate and unusually transparent dataset — Google has published it consistently since at least 2021 — but it is not independently audited, and no outside body has replicated Android's vulnerability counts or re-derived the 1,000x density figure from Google's source and bug trackers. Readers should treat it as a vendor's own measurement of its own program, not a third-party verification.

The closest thing to independent confirmation of the underlying mechanism — rather than Android's specific numbers — comes from academic work on Rust's safety guarantees generally. Hui Xu, Zhuangbin Chen, Mingshen Sun, Yangfan Zhou and Michael R. Lyu examined every publicly reported Rust CVE up to the end of 2020, a set of 186 real-world bug reports, and found that 185 of the 186 required unsafe code — the explicit keyword Rust requires before a programmer can perform raw pointer arithmetic or other operations the compiler cannot verify — according to their study in ACM Transactions on Software Engineering and Methodology (2021). That is independent evidence for the specific mechanism Google's roadmap depends on: memory-safety bugs in Rust code are concentrated in a small, explicitly marked, auditable fraction of the codebase rather than scattered unpredictably through it, as they are in C or C++.

The same study is also a caution against overstating the result. The authors found that buffer overflows and dangling-pointer bugs still occurred inside Rust programs — the language's guarantee is not "no memory bugs," it is "memory bugs require an explicit, auditable escape hatch." Several of the bugs in their dataset were what they term mild soundness issues in supposedly "safe" abstractions built on top of unsafe code, meaning a caller who never writes unsafe themselves can still inherit a bug from a dependency that does.

The policy push and its 2026 deadline

Government guidance has moved roughly in parallel with the vendor data. In December 2023, CISA, the NSA, the FBI and cybersecurity authorities from Australia, Canada, the UK and New Zealand jointly published "The Case for Memory Safe Roadmaps," urging software manufacturers to publish a roadmap for reducing memory-safety vulnerabilities in their products. CISA formalized this into its "Secure by Design" catalog of bad practices, and the January 2025 version of that document — Product Security Bad Practices, Version 2 — states that for an existing product written in a memory-unsafe language, not having published a memory-safety roadmap by January 1, 2026 is considered a bad practice that "significantly elevates risk to national security, national economic security, and national public health and safety." The requirement does not apply to products with an announced end-of-support date before January 1, 2030, and it asks manufacturers to show both a prioritized plan and "reasonable effort" in following it, rather than a hard vulnerability-count target.

This is guidance aimed primarily at federal suppliers and critical-infrastructure vendors, not binding law, and CISA's own document does not claim to measure how many manufacturers have actually published a compliant roadmap. No agency has yet released an audited count of roadmap submissions or a sector-wide before-and-after vulnerability figure comparable to what Google reports for Android. Readers should treat the January 2026 date as a policy deadline that exists in the primary document, not as evidence that industry-wide memory-safety vulnerability rates have moved by any particular amount.

What the numbers don't cover

A few gaps are worth naming plainly rather than glossing over. First, "percentage of total vulnerabilities that are memory-safety issues" is a ratio, and ratios move when either side of the fraction changes — if non-memory-safety bug classes (logic errors, authentication flaws, supply-chain issues) are found and reported more aggressively over the same period, the memory-safety share can fall even without an equivalent absolute drop in memory-safety bugs. Google's reporting presents both the percentage and an estimated density figure for 2025, which partially addresses this, but the density estimate itself is derived from Google's internal code and bug-tracking systems and has not been independently recomputed.

Second, memory-safe languages do not remove memory-unsafe code from a system; they concentrate it. Foreign-function interfaces, legacy C/C++ dependencies, and the unsafe blocks inside "safe" libraries remain real attack surface, which is why CISA's guidance and the academic literature both point to hardware-level mitigations — architectures like CHERI and ARM's Memory Tagging Extension — as a complement to, not a substitute for, language choice. Third, none of the sources here measure whether end users are actually safer in aggregate: Android's numbers describe vulnerabilities discovered and fixed, not exploitation rates in the field, and the CISA roadmap deadline measures a planning artifact, not a vulnerability count.

Taken together, the evidence supports a specific, bounded claim: within Android, a six-year, vendor-reported shift toward Rust for new code has coincided with a large, consistently reported fall in the memory-safety share of its vulnerabilities, and an independent academic study of real-world Rust bugs confirms the mechanism behind that shift — that such bugs cluster almost entirely inside explicitly marked unsafe regions rather than being spread unpredictably through ordinary code. It does not yet support a general, independently verified claim about memory-safe languages' effect on vulnerability rates across the software industry, nor does it tell us how many manufacturers have met, or will meet, the compliance deadline that US and allied cybersecurity agencies set for January 2026.