Memory safety bugs are "eroding trust in technology and costing billions," argues a new post on Google's security blog — adding that "traditional approaches, like code auditing, fuzzing, and exploit mitigations — while helpful — haven't been enough to stem the tide."
So the blog post calls for a "common framework" for "defining specific, measurable criteria for achieving different levels of memory safety assurance." The hope is this gives policy makers "the technical foundation to craft effective policy initiatives and incentives promoting memory safety" leading to "a market in which vendors are incentivized to invest in memory safety." ("Customers will be empowered to recognize, demand, and reward safety.")
In January the same Google security researchers helped co-write an article noting there are now strong memory-safety "research technologies" that are sufficiently mature: memory-safe languages (including "safer language subsets like Safe Buffers for C++"), mathematically rigorous formal verification, software compartmentalization, and hardware and software protections. (With hardware protections including things like ARM's Memory Tagging Extension and the (Capability Hardware Enhanced RISC Instructions, or "CHERI", architecture.) Google's security researchers are now calling for "a blueprint for a memory-safe future" — though Importantly, the idea is "defining the desired outcomes rather than locking ourselves into specific technologies."
Their blog post this week again urges a practical/actionable framework that's commonly understood, but one that supports different approaches (and allowing tailoring to specific needs) while enabling objective assessment:
At Google, we're not just advocating for standardization and a memory-safe future, we're actively working to build it. We are collaborating with industry and academic partners to develop potential standards, and our joint authorship of the recent CACM call-to-action marks an important first step in this process... This commitment is also reflected in our internal efforts. We are prioritizing memory-safe languages, and have already seen significant reductions in vulnerabilities by adopting languages like Rust in combination with existing, wide-spread usage of Java, Kotlin, and Go where performance constraints permit. We recognize that a complete transition to those languages will take time. That's why we're also investing in techniques to improve the safety of our existing C++ codebase by design, such as deploying hardened libc++. ...
[>>>]