For decades, programming-language choice was mostly an engineering decision shaped by performance, tooling, developer experience and legacy code. Increasingly, it is also becoming a cybersecurity decision.
Government agencies, major technology companies and security researchers are converging on the same problem: a large share of serious software vulnerabilities originates in memory-unsafe code, especially in systems written in C and C++. Instead of relying only on testing and hardening after software is written, the industry is being pushed toward languages that prevent entire categories of memory errors by design.
That shift is turning languages such as Rust, Go, Java, C# and Swift into more than technical preferences. They are becoming part of secure-software policy.
Governments are pushing security earlier into the language layer
The U.S. National Security Agency and Cybersecurity and Infrastructure Security Agency have explicitly urged software producers to consider memory-safe languages as part of their security architecture.
NSA and CISA say memory-safe languages embed protections such as bounds checking, memory management and data-race prevention, helping prevent memory bugs before they become exploitable vulnerabilities.
Their guidance is particularly aimed at software supporting national-security systems and critical infrastructure, where the agencies recommend that producers plan for and begin using memory-safe languages rather than treating memory safety as a problem to solve only through patching.
CISA has gone further in its Secure by Design guidance. For existing products, it recommends that manufacturers develop a memory-safety roadmap that prioritizes high-risk components, while new product lines should increasingly be built in memory-safe languages.
That changes the engineering conversation. The question is no longer only whether Rust or another language is technically attractive. For some software vendors, language choice is becoming evidence of whether security risks were considered at the architecture stage.
The vulnerability problem is structural, not cosmetic
The reason for this policy shift is straightforward: memory bugs are not rare edge cases.
The White House Office of the National Cyber Director previously noted that industry analysis has found up to 70% of security vulnerabilities in memory-unsafe languages can stem from memory-safety issues. Its report argues that choosing memory-safe languages for new products can deliver security benefits at the architectural level rather than relying exclusively on downstream detection.
Memory-unsafe languages give developers direct control over allocation and access to memory. That flexibility is valuable for operating systems, embedded software and performance-sensitive infrastructure, but it also creates room for defects such as buffer overflows, use-after-free errors and invalid pointer access.
Traditional defenses—code review, fuzzing, sanitizers and compiler protections—can catch many such problems. They cannot guarantee that the bug class disappears.
Memory-safe languages attempt something different: shift part of the responsibility from individual programmers into the language and compiler.
Android shows what that looks like at scale
Google’s Android experience provides one of the clearest real-world datasets supporting the transition.
Google reported in 2025 that memory-safety vulnerabilities had fallen below 20% of Android vulnerabilities for the first time as the platform increased its use of memory-safe languages and reduced the amount of newly written C and C++.
More strikingly, Google said Rust code showed a 1,000-fold reduction in memory-safety vulnerability density compared with Android’s C and C++ code.
The shift also produced development benefits. Google reported that Rust changes had a roughly four-times lower rollback rate and spent about 25% less time in code review than comparable C++ changes.
Those results challenge a long-standing assumption that additional safety necessarily slows engineering down. In Android’s case, fewer revisions and fewer unstable changes appear to reduce operational friction as well.
That matters to engineering leaders because security improvements are easier to justify when they also improve delivery reliability.
Migration does not mean rewriting everything
The strongest policy guidance does not call for companies to delete millions of lines of C++ overnight.
NSA and CISA explicitly state that memory-safe adoption does not require existing code to be completely rewritten. Instead, organizations can introduce safer languages gradually through interoperability and prioritize the components with the highest exposure or privilege.
Google has followed a similar strategy in Android, focusing heavily on new and actively developed code instead of attempting a complete replacement of the existing platform.
Microsoft is taking the approach into cryptographic infrastructure. In 2025, Microsoft Research announced that it was rewriting its SymCrypt cryptographic library in Rust while incorporating formal verification. SymCrypt is used across Windows, Azure Linux, Xbox and other Microsoft platforms.
That project illustrates the likely migration pattern: start with code where vulnerabilities would be especially costly, then gradually expand memory-safe components around existing systems.
Rust is safer, but unsafe Rust still matters
Memory safety is not automatic simply because a project uses Rust.
Rust deliberately permits developers to use unsafe blocks when they need operations that cannot be proven safe by the compiler, including raw-pointer manipulation, low-level data structures and interoperability with C or C++.
That boundary is now becoming an important research area.
At USENIX Security 2026, researchers evaluating the top 1,000 Rust packages with their CULPA analysis system found 55 previously unknown memory-safety bugs, 29 of which developers confirmed.
The researchers emphasized that Rust’s compile-time guarantees do not extend to unsafe Rust, where developers can bypass compiler protections and reintroduce vulnerabilities.
This is an important correction to simplistic claims that adopting Rust automatically solves memory security. It dramatically reduces the attack surface, but developers still need secure engineering practices around the code that escapes the language’s normal guarantees.
Mixed-language systems create the next security boundary
For most large organizations, migration will produce mixed systems rather than pure Rust codebases.
That means Rust will increasingly interact with decades of C and C++ software through foreign-function interfaces, or FFIs.
USENIX Security 2026 research on SafeFFI highlights this boundary directly. The authors note that unsafe Rust is necessary for interoperability with C and C++ libraries, but can introduce memory-safety violations into otherwise safe Rust applications.
Their SafeFFI system moves runtime checks toward the boundary between safe and unsafe code and was able to reduce sanitizer checks by up to 79.63% while still detecting all memory-safety violations in its vulnerable-code dataset.
This points to the real engineering challenge of the next decade.
The hardest problem may not be deciding that memory-safe languages are better. It may be securing the transition period in which old and new software must coexist.
Programming-language strategy is becoming security strategy
For CTOs and engineering leaders, this changes how technology stacks should be evaluated.
Programming-language decisions affect hiring, libraries, performance and developer productivity. They now increasingly affect vulnerability exposure, regulatory expectations and the security posture customers expect from software vendors.
Organizations do not need to rewrite every legacy system. But they may increasingly need to explain why new security-critical software is still being written in a memory-unsafe language when safer alternatives exist.
That is a significant shift.
Memory-safe languages are no longer simply competing on syntax, ergonomics or developer preference. They are becoming part of the architecture of secure-by-design software—and increasingly, the choice of programming language itself is becoming a cybersecurity control.
