Click here to visit Original posting
Google has hailed Rust, a memory safe programming language, as a significant factor in its ability to cut down on vulnerabilities as part of its Safe Coding initiative.
Memory access vulnerabilities often occur in programming languages that are not memory safe. In 2019, memory safety issues accounted for 76% of all Android vulnerabilities.
In response, many developers and tech giants are moving towards using memory safe languages that help them produce secure-by-design software and technology.
Vulnerabilities Rusting away
In its blog, Google presented a simulation of the transition to memory safe languages through the gradual use of memory safe code in new projects and developments over a five year period. The results showed that despite a gradual rise in code being written in memory unsafe languages, memory safety vulnerabilities dropped significantly.
This, Google says, is because vulnerabilities decay exponentially. New code that is written in memory unsafe languages often contains bugs and vulnerabilities, but as the code is reviewed and refreshed vulnerabilities are gradually removed making the code safer over time. Ergo, the main source of vulnerabilities is new code, and by prioritizing the use of memory safe programming languages when starting new projects and developments, the number of vulnerabilities drops significantly.
In Google’s own shift towards using memory safe programming languages there has been a significant drop in the number of memory-related vulnerabilities, with memory safe vulnerabilities down to 24% in 2024 - a stark contrast from 2019 and well below the industry norm of 70%.
Using memory safe languages is not a silver bullet however, and Google acknowledges that “with the benefit of hindsight, it’s evident that we have yet to achieve a truly scalable and sustainable solution that achieves an acceptable level of risk.”
The strategies for approaching memory safety vulnerabilities began with reactive patching, where memory safe vulnerabilities are prioritized by software manufacturers, leaving other issues to be exploited more rapidly.
The second approach consisted of proactive mitigating, where developers were encouraged to include mitigations such as stack canaries and control-flow integrity at the cost of execution speed, battery life, tail latencies, and memory usage. Developers were also unable to keep up with attackers' ability to exploit vulnerabilities in new and creative ways.
Third came proactive vulnerability discovery, where the focus was on detecting vulnerabilities through ‘fuzzing’, where vulnerabilities are tracked down through the symptoms of unsafe memory. However, as Google points out, these tools are inefficient and time-intensive for teams to use and often do not spot all vulnerabilities even with multiple passes.
Google’s fourth tactic is to therefore engage in high-assurance prevention and secure-by-design development. By using programming languages such as Rust, developers know and understand the properties of the code they have written and can infer vulnerabilities based on those properties. This reduces the cost on developers by reducing the number of vulnerabilities from the start, including vulnerabilities outside of memory safe issues. This cumulative cost reduction also has the added benefit of making developers more productive.
“The concept is simple:,” the Google blog notes, “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.”