Google has revealed that its transition to memory-safe languages such as Rust as part of its secure-by-design approach has led to the percentage of memory-safe vulnerabilities discovered in Android dropping from 76% to 24% over a period of six years.
The tech giant said focusing on Safe Coding for new features not only reduces the overall security risk of a codebase, but also makes the switch more “scalable and cost-effective.”
Eventually, this leads to a drop in memory safety vulnerabilities as new memory unsafe development slows down after a certain period of time, and new memory safe development takes over, Google’s Jeff Vander Stoep and Alex Rebert said in a post shared with The Hacker News.
Perhaps even more interestingly, the number of memory safety vulnerabilities tends to register a drop notwithstanding an increase in the quantity of new memory unsafe code.
The paradox is explained by the fact that vulnerabilities decay exponentially, with a study finding that a high number of vulnerabilities often reside in new or recently modified code.
“The problem is overwhelmingly with new code, necessitating a fundamental change in how we develop code,” Vander Stoep and Rebert noted. “Code matures and gets safer with time, exponentially, making the returns on investments like rewrites diminish over time as code gets older.”
Google, which formally announced its plans to support the Rust programming language in Android way back in April 2021, said it began prioritizing transitioning new development to memory-safe languages around 2019.
As a result, the number of memory safety vulnerabilities discovered in the operating system has declined from 223 in 2019 to less than 50 in 2024.
It also goes without saying that much of the decrease in such flaws is down to advancements in the ways devised to combat them, moving from reactive patching to proactive mitigating to proactive vulnerability discovery using tools like Clang sanitizers.
The tech giant further noted that memory safety strategies should evolve even more to prioritize “high-assurance prevention” by incorporating secure-by-design principles that enshrine security into the very foundations.
“Instead of focusing on the interventions applied (mitigations, fuzzing), or attempting to use past performance to predict future security, Safe Coding allows us to make strong assertions about the code’s properties and what can or cannot happen based on those properties,” Vander Stoep and Rebert said.
That’s not all. Google said it is also focusing on offering interoperability between Rust, C++, and Kotlin, instead of code rewrites, as a “practical and incremental approach” to embracing memory-safe languages and ultimately eliminating entire vulnerability classes.
“Adopting Safe Coding in new code offers a paradigm shift, allowing us to leverage the inherent decay of vulnerabilities to our advantage, even in large existing systems,” it said.
“The concept is simple: once we turn off the tap of new vulnerabilities, they decrease exponentially, making all of our code safer, increasing the effectiveness of security design, and alleviating the scalability challenges associated with existing memory safety strategies such that they can be applied more effectively in a targeted manner.”
The development comes as Google touted increased collaboration with Arm’s product security and graphics processing unit (GPU) engineering teams to flag multiple shortcomings and elevate the overall security of the GPU software/firmware stack across the Android ecosystem.
This includes the discovery of two memory issues in Pixel’s customization of driver code (CVE-2023-48409 and CVE-2023-48421) and another in Arm Valhall GPU firmware and 5th Gen GPU architecture firmware (CVE-2024-0153).
“Proactive testing is good hygiene as it can lead to the detection and resolution of new vulnerabilities before they’re exploited,” Google and Arm said.
Found this article interesting? Follow us on Twitter and LinkedIn to read more exclusive content we post.
