Full Report
Posted by Alex Rebert, Security Foundations, Ben Laurie, Research, Murali Vijayaraghavan, Research and Alex Richardson, SiliconFor decades, memory safety vulnerabilities have been at the center of various security incidents across the industry, eroding trust in technology and costing billions. Traditional approaches, like code auditing, fuzzing, and exploit mitigations – while helpful – haven't been enough to stem the tide, while incurring an increasingly high cost.In this blog post, we are calling for a fundamental shift: a collective commitment to finally eliminate this class of vulnerabilities, anchored on secure-by-design practices – not just for ourselves but for the generations that follow.The shift we are calling for is reinforced by a recent ACM article calling to standardize memory safety we took part in releasing with academic and industry partners. It's a recognition that the lack of memory safety is no longer a niche technical problem but a societal one, impacting everything from national security to personal privacy.The standardization opportunityOver the past decade, a confluence of secure-by-design advancements has matured to the point of practical, widespread deployment. This includes memory-safe languages, now including high-performance ones such as Rust, as well as safer language subsets like Safe Buffers for C++. These tools are already proving effective. In Android for example, the increasing adoption of memory-safe languages like Kotlin and Rust in new code has driven a significant reduction in vulnerabilities.Looking forward, we're also seeing exciting and promising developments in hardware. Technologies like ARM's Memory Tagging Extension (MTE) and the Capability Hardware Enhanced RISC Instructions (CHERI) architecture offer a complementary defense, particularly for existing code.While these advancements are encouraging, achieving comprehensive memory safety across the entire software industry requires more than just individual technological progress: we need to create the right environment and accountability for their widespread adoption. Standardization is key to this. To facilitate standardization, we suggest establishing a common framework for specifying and objectively assessing memory safety assurances; doing so will lay the foundation for creating a market in which vendors are incentivized to invest in memory safety. Customers will be empowered to recognize, demand, and reward safety. This framework will provide governments and businesses with the clarity to specify memory safety requirements, driving the procurement of more secure systems. The framework we are proposing would complement existing efforts by defining specific, measurable criteria for achieving different levels of memory safety assurance across the industry. In this way, policymakers will gain the technical foundation to craft effective policy initiatives and incentives promoting memory safety. A blueprint for a memory-safe futureWe know there's more than one way of solving this problem, and we are ourselves investing in several. Importantly, our vision for achieving memory safety through standardization focuses on defining the desired outcomes rather than locking ourselves into specific technologies.To translate this vision into an effective standard, we need a framework that will:Foster innovation and support diverse approaches: The standard should focus on the security properties we want to achieve (e.g., freedom from spatial and temporal safety violations) rather than mandating specific implementation details. The framework should therefore be technology-neutral, allowing vendors to choose the best approach for their products and requirements. This encourages innovation and allows software and hardware manufacturers to adopt the best solutions as they emerge.Tailor memory safety requirements based on need: The framework should establish different levels of safety assurance, akin to SLSA levels, recognizing that different applications have different security needs and cost constraints. Similarly, we likely need distinct guidance for developing new systems and improving existing codebases. For instance, we probably do not need every single piece of code to be formally proven. This allows for tailored security, ensuring appropriate levels of memory safety for various contexts. Enable objective assessment: The framework should define clear criteria and potentially metrics for assessing memory safety and compliance with a given level of assurance. The goal would be to objectively compare the memory safety assurance of different software components or systems, much like we assess energy efficiency today. This will move us beyond subjective claims and towards objective and comparable security properties across products.Be practical and actionable: Alongside the technology-neutral framework, we need best practices for existing technologies. The framework should provide guidance on how to effectively leverage specific technologies to meet the standards. This includes answering questions such as when and to what extent unsafe code is acceptable within larger software systems, and guidelines on structuring such unsafe dependencies to support compositional reasoning about safety.Google's commitmentAt 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. In addition, as outlined in our Secure by Design whitepaper and in our memory safety strategy, we are deeply committed to building security into the foundation of our products and services.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++.Let's build a memory-safe future togetherThis effort isn't about picking winners or dictating solutions. It's about creating a level playing field, empowering informed decision-making, and driving a virtuous cycle of security improvement. It's about enabling a future where:Developers and vendors can confidently build more secure systems, knowing their efforts can be objectively assessed.Businesses can procure memory-safe products with assurance, reducing their risk and protecting their customers.Governments can effectively protect critical infrastructure and incentivize the adoption of secure-by-design practices.Consumers are empowered to make decisions about the services they rely on and the devices they use with confidence – knowing the security of each option was assessed against a common framework. The journey towards memory safety requires a collective commitment to standardization. We need to build a future where memory safety is not an afterthought but a foundational principle, a future where the next generation inherits a digital world that is secure by design.AcknowledgmentsWe'd like to thank our CACM article co-authors for their invaluable contributions: Robert N. M. Watson, John Baldwin, Tony Chen, David Chisnall, Jessica Clarke, Brooks Davis, Nathaniel Wesley Filardo, Brett Gutstein, Graeme Jenkinson, Christoph Kern, Alfredo Mazzinghi, Simon W. Moore, Peter G. Neumann, Hamed Okhravi, Peter Sewell, Laurence Tratt, Hugo Vincent, and Konrad Witaszczyk, as well as many others.
Analysis Summary
The provided context is the header and navigation structure of a Google Online Security Blog post titled "Securing tomorrow's software: the need for memory safety standards." The main body of the article detailing the standards, recommendations, and practical steps is truncated.
Therefore, the following summary is based on the *implication* of the title—that the content advocates for and details standards related to memory safety in software development—and uses logical cybersecurity best practices associated with that topic, as no concrete details were available in the excerpt.
# Best Practices: Adopting Memory Safety Standards
## Overview
These practices address the critical need to secure future software by mandating and implementing memory safety standards to mitigate vulnerabilities arising from unsafe memory management (e.g., buffer overflows, use-after-free errors) commonly found in languages like C/C++.
## Key Recommendations
### Immediate Actions
1. **Inventory Current Memory-Unsafe Codebases:** Immediately catalog all applications and libraries written in languages susceptible to memory safety issues (e.g., C/C++) that directly interface with critical systems or handle sensitive data.
2. **Increase Static Analysis Coverage:** Mandate the use of static application security testing (SAST) tools configured specifically to detect memory safety violations (e.g., buffer overflows, pointer arithmetic errors) on all high-risk C/C++ projects.
3. **Establish Criticality Thresholds:** Define clear criteria (e.g., internet-facing, processing PII) to prioritize which existing memory-unsafe components require the most urgent mitigation or rewriting effort.
### Short-term Improvements (1-3 months)
1. **Adopt Memory-Safe Language Migration Strategy:** Develop a formal roadmap to transition high-risk, frequently updated code components from memory-unsafe languages to memory-safe alternatives (e.g., Rust, Go, C/C++ with strict compiler/runtime checks).
2. **Implement Compiler Hardening Flags:** For all new development and recompilation of existing C/C++ code, enforce aggressive compiler flags that enable security features like Address Sanitizer (ASan), Memory Sanitizer (MSan), and stack protection mechanisms (e.g., -fstack-protector-all).
3. **Integrate Fuzz Testing:** Begin integrating memory-safety-focused fuzzers (e.g., libFuzzer, AFL++) into the CI/CD pipeline for all critical components to automatically discover logic errors related to memory handling.
### Long-term Strategy (3+ months)
1. **Mandate Memory-Safe By Default Policy:** Establish an organizational policy stating that all new internal service development and external-facing features must be implemented using languages or frameworks providing inherent memory safety guarantees (e.g., Rust).
2. **Develop Internal Memory Safety Standards:** Formalize organizational coding standards that specify mandatory use of proven memory-safe libraries and configurations, banning unsafe idioms in legacy languages unless strictly necessary and peer-reviewed.
3. **Invest in Developer Training:** Create mandatory, recurring training programs focused on modern memory safety concepts, secure coding practices in chosen languages, and the proper configuration and interpretation of memory-safety testing tools.
## Implementation Guidance
### For Small Organizations
- **Prioritize Open Source Dependencies:** Focus initial efforts on updating or replacing any third-party C/C++ libraries used that are known to have memory vulnerabilities, leveraging community-supported memory-safe alternatives where available.
- **Utilize Free/Low-Cost Tools:** Leverage free versions of strong static analysis tools or built-in compiler checks (like AddressSanitizer during testing phases) rather than investing immediately in expensive enterprise suites.
### For Medium Organizations
- **Pilot Migration Projects:** Identify one non-critical but actively maintained C/C++ service for a complete rewrite/migration into a memory-safe language to establish internal tooling, processes, and cost metrics for larger migrations.
- **Enforce CI/CD Gates:** Integrate SAST scanning and fuzz testing results as mandatory quality gates in the Continuous Integration/Continuous Deployment (CI/CD) pipeline, blocking merges if severe memory safety violations are detected.
### For Large Enterprises
- **Establish a Platform Migration Team:** Form a dedicated engineering team tasked solely with defining best practices, creating standardized memory-safe boilerplate code (templates), and assisting other product teams with large-scale codebase migration efforts.
- **Engage with Standards Bodies:** Actively participate in industry working groups or open-source projects advocating for memory-safe standards (e.g., contributing to Rust projects or contributing upstream fixes to C/C++ libraries).
## Configuration Examples
*Note: Specific tools are inferred from general industry best practices related to memory safety standards.*
- **Compiler Flags (for C/C++):** Compile with flags such as: `-fsanitize=address,undefined` (enabling ASan and UBSan) and `-fstack-protector-strong` (or `-fstack-protector-all`).
- **Build System Integration (Example using CMake):** Ensure the build definition explicitly sets these flags for debug or testing builds globally across the project structure.
## Compliance Alignment
- **NIST SP 800-53 (Rev. 5):** Alignment with controls related to Software, Data, and System Integrity (e.g., SI-7 monitoring and control of system resources, SA-11 developer security training).
- **ISO/IEC 27034-1 (Application Security):** Directly supports the principle of specifying requirements for application security at the design and implementation phases, emphasizing secure coding practices.
- **CIS Critical Security Controls v8:** Supports CSC 14 (Security Skills Training) and CSC 16 (Application Software Security), specifically targeting the reduction of exploitable flaws during development.
## Common Pitfalls to Avoid
- **"Lift and Shift" without Review:** Simply compiling old C/C++ code with new sanitizer flags without understanding the underlying vulnerabilities—sanitizers help find issues, but do not fix the root cause in production release builds unless explicitly configured.
- **Underestimating Migration Scope:** Assuming memory-safe replacement is trivial; languages introduce new paradigms, and rewriting core logic requires significant re-architecting and testing.
- **Treating Training as Optional:** Failing to enforce widespread adoption of memory-safe development training, leading to new memory bugs being introduced in the very code that was meant to replace older, unsafe code.
## Resources
- **[Tooling Documentation]:** Documentation or guides for setting up and running AddressSanitizer (ASan) for your toolchain (GCC/Clang).
- **[Language Resources]:** Official documentation and best practices guides for memory-safe programming languages like Rust.
- **[Fuzzing Frameworks]:** Guides on integrating OSS fuzzers (like AFL++) into CI pipelines for vulnerability discovery.