The number of Android memory safety vulnerabilities has tumbled, and here’s why
Google’s decision to write new code into Android’s codebase in Rust, a memory-safe programming language, has resulted in a significant drop in memory safety vulnerabilities, despite old code (written in C/C++) not having been rewritten.
The number of memory safety vulnerabilities found in the Android codebase per year (Source: Google)
Android evolves, and has fewer memory safety vulnerabilities
“The Android team began prioritizing transitioning new development to memory-safe languages around 2019. This decision was driven by the increasing cost and complexity of managing memory safety vulnerabilities,” Jeff Vander Stoep, from the Android team, and Alex Rebert, Security Foundations, explained.
The choice not to rewrite the old codebase was based on a previous simulation, which was in turn based on a study of vulnerability lifetimes that showed that the average lifetime of a vulnerability is around 4 years, and that most vulnerabilities reside in new or recently modified code.
In short, they bet on the fact that by using a memory-safe language, fewer bugs are getting introduced with new features. As the older ones are “decaying” with time, the number of memory safety vulnerabilities was expected to go down – and it did.
“Despite the majority of [Android] code still being unsafe (but, crucially, getting progressively older), we’re seeing a large and continued decline in memory safety vulnerabilities. The results align with what we simulated (…), and are even better, potentially as a result of our parallel efforts to improve the safety of our memory unsafe code,” Vander Stoep and Rebert noted.
“Memory safety issues, which accounted for 76% of Android vulnerabilities in 2019, and are currently 24% in 2024, well below the 70% industry norm, and continuing to drop.”
From reactive to proactive solutions
As software makers and users cycled through various solutions for combating memory safety vulnerabilities – which are, as Google notes, “more likely to be remotely reachable, more versatile, and more likely to be maliciously exploited than other vulnerability types” – the scale has steadily tipped from reactive measures (patching) to proactive ones: exploit mitigation strategies, vulnerability discovery via sanitizers and fuzzers, and now vulnerability prevention through the use of memory-safe languages.
“The foundation of this shift is Safe Coding, which enforces security invariants directly into the development platform through language features, static analysis, and API design. The result is a secure by design ecosystem providing continuous assurance at scale, safe from the risk of accidentally introducing vulnerabilities,” Vander Stoep and Rebert said.
“Safe Coding improves code correctness and developer productivity by shifting bug finding further left, before the code is even checked in. We see this shift showing up in important metrics such as rollback rates (emergency code revert due to an unanticipated bug). The Android team has observed that the rollback rate of Rust changes is less than half that of C++.”
Earlier this month, the Android Team shared insights on how Rust can be gradually introduced in smartphone firmware.
Memory-safe languages are the way to go
The US Cybersecurity and Infrastructure Agency (CISA) has been beating the drum for the use of memory safe languages for a while now, and has recently found that 52% of 172 critical and widely-used open source projects contain code written in a memory-unsafe language.
CISA’s push for the use of memory-safe languages has been echoed by the White House.
Google’s approach for Android, which is based on forgoing rewrites of the existing codebase and focusing on making interoperability both safe and convenient, is one that other software makers and organizations can embrace without worrying about increasing investments and a slowdown in pushing out new features, the company believes.
Those interested in the various challenges and considerations when it comes to transitioning to memory-safe languages should check out our recent topical interview with Omkhar Arasaratnam, General Manager at the Open Source Security Foundation (OpenSSF).