In February 2024, CISA released a roadmap calling on software manufacturers to transition toward memory-safe programming languages. The document is not a mandate. It is a signal, and a significant one, about where government expectations for software security are heading.
The premise is straightforward: memory safety vulnerabilities (buffer overflows, use-after-free, null pointer dereferences, and related classes) account for approximately 70% of critical vulnerabilities in large C and C++ codebases. Microsoft, Google, and Apple have independently confirmed this ratio across their respective products. Eliminating the entire vulnerability class by choosing memory-safe languages is more effective than trying to catch every instance through testing and review.
The 70% Problem
The data supporting CISA's position is robust:
- Microsoft reported that 70% of their CVEs are memory safety issues, consistently, year over year.
- Google Chrome reported that 70% of serious security bugs are memory safety problems.
- Android saw memory safety bugs drop from 76% to 24% of vulnerabilities as the proportion of new code written in memory-safe languages increased.
- Apple has seen similar patterns in iOS and macOS vulnerability distributions.
These are not niche products. They are the most heavily tested, reviewed, and funded software projects in the world. If Microsoft and Google cannot eliminate memory safety bugs through code review and testing alone, smaller organizations certainly cannot either.
What Counts as Memory-Safe
CISA's roadmap identifies languages that provide memory safety guarantees through their type systems and runtime checks:
- Rust provides memory safety without garbage collection through its ownership system. It is the most commonly cited alternative for systems programming currently done in C and C++.
- Go provides memory safety through garbage collection and runtime bounds checking. Widely used for network services and cloud infrastructure.
- Java, C#, Python, JavaScript, Swift, Kotlin all provide memory safety through managed runtimes or language design.
The key distinction is between languages where the compiler or runtime prevents memory safety violations and languages where the programmer must manually ensure correctness.
C and C++ fall into the latter category. No amount of coding standards, static analysis, or code review eliminates memory safety bugs from large C/C++ codebases. The error rate is inherent to the programming model.
The Roadmap Recommendations
CISA's roadmap asks software manufacturers to:
Develop a memory-safe language migration plan. Manufacturers should assess their codebases, identify components where memory safety vulnerabilities pose the greatest risk, and create plans for rewriting or replacing those components in memory-safe languages.
Prioritize new development in memory-safe languages. Even if existing code cannot be immediately migrated, new features and components should default to memory-safe language implementations.
Publish memory safety roadmaps. Software manufacturers should be transparent about their memory safety posture and migration plans, allowing customers to assess the risk.
Invest in tooling for mixed-language codebases. The transition will take years or decades. Tools for safely interfacing between memory-safe and memory-unsafe code are essential for the transition period.
Industry Response
The response has been mixed:
Supportive voices. Organizations already investing in Rust adoption (Google, Microsoft, the Linux kernel project, Amazon) welcomed the roadmap as validation of their direction. The Rust Foundation saw increased interest from organizations evaluating the language.
Skeptics. Some in the C and C++ communities pushed back, arguing that modern C++ features, static analysis tools, and coding guidelines can achieve acceptable safety levels. Others noted the practical impossibility of rewriting billions of lines of existing C/C++ code.
Pragmatists. Many acknowledged the goal while questioning the timeline and feasibility. Rewriting critical infrastructure, including operating system kernels, network stacks, and embedded systems firmware, in memory-safe languages is a generational project.
What This Means for Software Supply Chains
The memory safety conversation intersects with supply chain security in several ways:
Dependency risk assessment. Organizations evaluating open source dependencies should consider the language a component is written in as a risk factor. A C library with a history of memory safety CVEs represents ongoing risk that code review cannot fully mitigate.
SBOM enrichment. SBOMs that include language information for each component enable automated analysis of memory safety exposure across a dependency tree. This is a new dimension of supply chain risk that few organizations currently measure.
Procurement requirements. As government agencies operationalize CISA's recommendations, procurement requirements may begin specifying memory-safe language preferences or requiring memory safety risk documentation from vendors.
Container base image selection. Base images built with memory-safe language toolchains (such as Chainguard's images using Rust-based core utilities) reduce the memory safety attack surface of containerized applications.
The Transition Challenge
The practical challenges of memory-safe language adoption are significant:
Talent availability. Rust developers are in high demand and short supply. Training existing C/C++ developers in Rust requires meaningful investment, and the language's steep learning curve is a real barrier.
Interoperability. Most real-world systems are not greenfield. New memory-safe code must interface with existing memory-unsafe code. The FFI (Foreign Function Interface) boundary between safe and unsafe code is itself a source of potential vulnerabilities.
Performance considerations. For some workloads, the performance characteristics of garbage-collected languages are unacceptable. Rust addresses this for systems programming, but its learning curve is steeper than Go or Java.
Ecosystem maturity. C and C++ have decades of library ecosystems. Memory-safe language ecosystems are younger and sometimes lack equivalents for specialized libraries.
Regulatory lag. Safety-critical industries (aerospace, medical, automotive) have certification frameworks built around C and C++ toolchains. Certifying Rust compilers and toolchains for these domains is underway but not complete.
What Organizations Can Do Now
Even without a complete language migration, several practical steps reduce memory safety risk:
- Default new projects to memory-safe languages unless there is a specific technical requirement for C/C++.
- Identify the highest-risk C/C++ components in your dependency tree, those that parse untrusted input, handle network data, or run with elevated privileges, and prioritize them for migration or replacement.
- Use memory safety tools for existing C/C++ code: AddressSanitizer, MemorySanitizer, fuzzing, and static analysis tools catch some classes of memory safety bugs.
- Track memory safety metrics in your vulnerability data. What percentage of your CVEs are memory safety related? Is the ratio changing over time?
- Include language information in SBOMs to enable automated assessment of memory safety exposure across your supply chain.
How Safeguard.sh Helps
Safeguard.sh provides visibility into the composition of your software supply chain, including the languages and frameworks your dependencies are built with. This enables organizations to assess their memory safety exposure across the full dependency graph.
Through SBOM analysis, Safeguard.sh can identify components written in memory-unsafe languages that have histories of memory safety CVEs, helping prioritize which dependencies represent the highest risk and which alternatives might reduce that risk.
As CISA's roadmap drives procurement and compliance requirements around memory safety, Safeguard.sh provides the inventory and analysis capabilities organizations need to understand their current posture and track their progress.