Rust as a National Security Language: How Memory Safety Became a Policy Issue

Why "Which Language" Became a Security Question

For a long time, picking a programming language was treated as a matter of developer taste and productivity. Since 2022, that has changed: US government agencies have repeatedly published official documents recommending memory-safe languages. What drove that shift isn't ideology or hype — it's more than a decade of accumulated vulnerability statistics. That's where we'll start.

1. Where the "About 70%" Figure Comes From

The starting point of this whole discussion is a talk given by Matt Miller, then of the Microsoft Security Response Center (MSRC), at BlueHat IL in February 2019 — Microsoft's security conference held in Israel. The talk, "Trends, Challenges, and Strategic Shifts in the Software Vulnerability Mitigation Landscape," presented the finding that roughly 70% of the vulnerabilities Microsoft assigns a CVE to and patches each year are memory safety issues. The key point was that this ratio had held roughly constant for over a decade going back to the mid-2000s — fluctuating somewhat year to year, but staying around the 70% mark.

MSRC also published the substance of this in a July 2019 blog post, "A proactive approach to more secure code," which states that the majority of vulnerabilities that get fixed and assigned a CVE are caused by developers inadvertently introducing memory corruption bugs into their C and C++ code. "Memory safety issues" here is a collective term for specific defect classes: heap out-of-bounds access, use-after-free, type confusion, and use of uninitialized memory. All of them arise because C and C++ delegate memory management to the programmer, and all of them have the property that code which is "correct" as far as the language specification is concerned can still break apart at runtime.

What matters is that this was not a Microsoft-specific number. Google's Chromium project security documentation states plainly that an analysis of 912 high- or critical-severity vulnerabilities affecting the Stable channel since 2015 found that around 70% were memory safety problems — and that about half of those were use-after-free bugs. Two different companies, two different codebases (Windows and Chromium), two different time windows, converging on nearly the same ratio. That convergence is what convinced the industry this was not a matter of individual quality control but a structural problem at the language level.

The Chromium document is notably candid on one further point: it acknowledges that sandboxing and site isolation, the existing mitigations, are approaching their limits. Chromium was architected on the assumption that such bugs exist, using defense in depth to contain them — but the document indicates most of the available gain from that approach has already been collected. The conclusion drawn from there was to stop piling on mitigations and move to a language where the bugs don't get written in the first place.

2. The US Government Policy Push: What the Documents Actually Say

The first clear articulation of this technical consensus in government form came from the NSA. On November 10, 2022, the NSA published the Cybersecurity Information Sheet "Software Memory Safety," advising organizations to consider a strategic shift, where possible, away from languages such as C and C++ that provide little or no inherent memory protection, toward memory-safe languages. The examples the document lists are C#, Go, Java, Ruby, Rust, and Swift — it is worth noting that Rust is not singled out.

Then, on December 6, 2023, CISA (the US Cybersecurity and Infrastructure Security Agency), together with the NSA and FBI and with agencies from Australia (ASD's ACSC), Canada (CCCS), the United Kingdom (NCSC-UK), and New Zealand (NCSC-NZ / CERT NZ), published "The Case for Memory Safe Roadmaps." Part of CISA's "Secure by Design" campaign, it asks software manufacturers to create and publish roadmaps for transitioning to memory-safe languages. Being an international joint publication, this is no longer a US-only policy position.

On February 26, 2024, the White House Office of the National Cyber Director (ONCD) published the technical report "Back to the Building Blocks: A Path Toward Secure and Measurable Software." The report rests on two pillars: (1) reduce the attack surface by keeping entire classes of vulnerability out of the ecosystem in the first place, and (2) develop better diagnostics for measuring software quality. The accompanying fact sheet states that using memory-safe programming languages can eliminate most memory safety errors, and positions the highest-leverage action available to manufacturers as securing one of the building blocks of cyberspace: the programming language itself.

The report does name Rust as an example — but the context is more measured than it is often made out to be. In a passage about space systems, it notes that Rust, as one example of a memory-safe programming language, has the requisite properties but has not yet been proven in space systems. In other words, it recommends the direction while simultaneously acknowledging that maturity differs by application domain.

Most recently, on June 24, 2025, CISA and the NSA jointly published "Memory Safe Languages: Reducing Vulnerabilities in Modern Software Development," which states that adopting memory-safe languages offers the most comprehensive mitigation against this class of vulnerabilities, and goes into the barriers to adoption and how to work through them.

3. Where Rust Has Actually Landed

Policy documents and real adoption are two different things. So how far has it actually gone? Here is what can be verified.

The Linux kernel. Linux 6.1, released in December 2022, merged the foundations: Rust toolchain integration, the CONFIG_RUST build hook, and the basic abstractions needed to write Rust against kernel APIs. At that point it was still explicitly an experiment, with no real drivers. Linux 6.8 in 2024 brought the first practical drivers into mainline, starting with the ASIX PHY driver, and 6.13 added driver bindings for PCI, platform devices, and I/O operations. Then in December 2025, Miguel Ojeda, who leads the Rust for Linux project, submitted a patch titled "rust: conclude the Rust experiment," declaring that Rust in the kernel has moved past the experimental stage and is a permanent fixture. Android 16 ships the Rust-written ashmem module on the 6.12 kernel, and the Android binder driver was merged for 6.18.

Ojeda himself attached a clear caveat: this does not mean everything works for every kernel configuration, architecture, and toolchain. gccrs, the GCC-based Rust implementation, is not complete, and by the participants' own assessment a great deal of work remains. It's also worth recording that this process has frequently been contentious within the kernel community.

Windows. At BlueHat IL in 2023, David Weston, Microsoft's Vice President for OS Security, disclosed that parts of the Windows kernel were being rewritten in Rust. Specifically, win32kbase_rs.sys contains a new implementation of GDI regions — the functions used to create and combine rectangles, polygons, and ellipses — and this began shipping with Windows 11 Insider Preview Build 25905 on the Canary Channel. Weston himself described the state of play as "the crawl stage of crawl, walk, run," which is to say: not a rewrite of Windows.

Android. This is where the quantitative effect is most clearly published. In a September 2024 security blog post, "Eliminating Memory Safety Vulnerabilities at the Source," Google reported that the proportion of discovered Android vulnerabilities attributable to memory safety had fallen from 76% in 2019 to 24% in 2024. In absolute terms, the count dropped from 223 in 2019 to fewer than 50 in 2024. The reason is the notable part: Google attributes it not to rewriting existing C/C++ code, but to writing new code in memory-safe languages such as Rust and Kotlin. Vulnerabilities cluster in newer code, so changing the language of new code alone moves the overall ratio substantially. Existing C/C++ code, meanwhile, matures over time, and the rate at which fresh vulnerabilities are found in it declines.

US government and defense. This part needs care. Concrete, verifiable claims of the form "agency X migrated system Y to Rust in year Z" are thin on the ground in public sources. What can be stated with confidence is that DARPA runs a program called TRACTOR (Translating All C to Rust), a research effort to automate the translation of legacy C code into Rust by combining static and dynamic analysis with large language models. Test and evaluation is handled by a team at MIT Lincoln Laboratory, and a benchmark of 150 C programs covering a range of C features has been publicly released. The stated motivation is economic: manual C-to-Rust translation takes years and costs enormous sums, so large-scale legacy migration is not realistic without automation. Read the other way, that means the government's own position is that wholesale rewriting of existing code is currently impractical.

4. The Hard Question: Can COBOL/Java Mainframe Systems Actually Migrate to Rust?

This is the point this article most wants to handle carefully. The short answer is that "rewrite the COBOL mainframe in Rust" is, for the foreseeable future, not a realistic proposition — and the reason has nothing to do with any shortcoming in Rust.

Start with scale. Estimates of how much COBOL is still running in production vary widely; the figure most often cited, traced back to 2017 Reuters reporting, is around 220 billion lines, while larger estimates put it as high as 800 billion. The same family of estimates holds that 43% of US core banking systems and 95% of ATM transactions depend on COBOL, and that roughly $3 trillion in daily commerce passes through COBOL systems. These are estimates that swing considerably by source and should not be treated as settled statistics — but every estimate agrees on the order of magnitude: hundreds of billions of lines.

The government side can be checked against a firmer primary source. The US Government Accountability Office report published July 17, 2025, GAO-25-107795, "Agencies Need to Plan for Modernizing Critical Decades-Old Legacy Systems," identifies 11 of the most critical legacy systems across 10 federal agencies. They range from about 23 to 60 years old and cost roughly $754 million per year to operate and maintain. Eight of the 11 use legacy programming languages, and the report specifically notes that both of the Department of the Treasury's selected systems run on COBOL and Assembly Language Code — languages with a dwindling number of people available with the skills to support them.

More fundamental than scale or staffing, though, is this: Java does not have the problem Rust is designed to solve. This is easy to conflate, so let's be explicit. Java is a garbage-collected language and is memory-safe in the relevant sense. Array bounds are checked at runtime, there is no pointer arithmetic, and the concept of accessing freed memory does not exist. The vulnerability class specific to C and C++ — buffer overflows, use-after-free, type confusion — cannot arise in Java application code as a matter of principle. That is precisely why the NSA's information sheet lists Java and C# alongside Rust in its set of memory-safe languages.

So the argument "migrate the Java backend to Rust for memory safety" does not hold together: the problem it proposes to solve isn't there to begin with. The risks Java carries in enterprise and government backends belong to entirely different classes — unsafe deserialization, access control design errors, supply-chain exposure through dependencies (Log4Shell being the canonical example), and vulnerabilities in the JVM or runtime itself. None of those disappear by moving to Rust.

The situation with COBOL is similar. COBOL is a language built around fixed-length records; it is not organized around C-style pointer arithmetic and manual heap management. The real risk in a COBOL mainframe is not memory corruption but the absence of people who can maintain it, specifications that exist in no one's head in complete form, and surrounding middleware and operating systems drifting out of support. Those are organizational, documentation, and architecture problems — not problems you solve by swapping the language.

On top of that, rewriting a system of that size in one shot — the big-bang rewrite — is an extremely high-risk move regardless of the target language. The most durably cited piece on this in the software industry is Joel Spolsky's "Things You Should Never Do, Part I," published April 6, 2000. His argument has two parts: (1) code that looks ugly often has years of hard-won handling of corner cases and strange bugs baked into it, and a rewrite throws that knowledge away; (2) a rewrite takes a long time, during which you cannot improve the product and competitors close the gap. The example he uses is Netscape rewriting its browser engine and going roughly three years without shipping a competitive release. The essay is 26 years old and is still referenced in essentially every serious discussion of replacing a core system. In practice, organizations almost always choose incremental replacement through interop, or wrapping the legacy system behind an API and leaving it in place, over a full rewrite.

So where does Rust actually fit? The answer is clear enough: new systems-level, performance-critical, and security-critical code where C and C++ are still the default. Kernels, device drivers, cryptographic libraries, media codecs, and network-facing parsers that handle untrusted input directly — the place where attacker-controlled bytes are first touched is exactly where memory safety failures carry the highest price. As the Android numbers showed, switching the language of new code alone shifts the vulnerability mix substantially over time. This is not a story about replacing COBOL or Java. It is a story about no longer writing new C and C++.

5. Neglected Legacy: The Attack Surface That Already Exists

Everything above concerns code yet to be written. The old systems actually in operation today carry a separate, present-tense risk.

The GAO report cited above found that among the 11 critical legacy systems, four contain unsupported hardware or software, and seven are operating with known cybersecurity vulnerabilities. Crucially, in the report's framing, those vulnerabilities can only be addressed through modernization — that is, they cannot be patched away.

This concern has also taken a binding form. On February 5, 2026, CISA issued Binding Operational Directive 26-02, "Mitigating Risk From End-of-Support Edge Devices," which directs federal civilian executive branch agencies not merely to patch end-of-support edge network devices but to update or remove them. The deadlines: inventory devices on CISA's published EOS Edge Device List by May 5, 2026; update or replace them by February 5, 2027; and by August 5, 2027, deal with all unsupported edge devices, including those not on the list. Unlike the language guidance, this one is binding — and that contrast is itself a good indication of what the government regards as an immediate crisis versus a long-term direction.

Which brings us back to memory safety. A large C/C++ codebase whose current maintainers do not understand it in full and which cannot be safely modified is exactly where memory safety bugs survive longest. The reasons are straightforward: (1) static analysis and fuzzing cannot get full coverage of a sufficiently large codebase; (2) the blast radius of a fix is unpredictable, so even known issues go untouched; and (3) with nobody left who knows the original design intent, it is often impossible to determine whether a given behavior is a bug or the specification. In operational technology and industrial control environments, where the downtime required to update is not permitted, this gets considerably worse.

The important point is that this reality does not undercut the question of whether new code should be written in a memory-safe language — it makes it more urgent. Security-critical code written in C or C++ today becomes, ten or twenty years from now, the large, poorly understood, untouchable legacy of tomorrow. Language choice is not something that can be revisited at that point. At the same time, it needs to be equally clear that changing the language does not retroactively make anything already deployed safe. These are two separate problems requiring two separate efforts.

Summary

• The discussion starts from Matt Miller's 2019 BlueHat IL talk at Microsoft, reporting that about 70% of vulnerabilities assigned a CVE are memory safety issues
• Google's Chromium team published nearly the same ~70% figure from an analysis of 912 high-severity vulnerabilities since 2015 — a convergence across companies and codebases
• Government guidance has accumulated: NSA (November 2022), a nine-agency international joint guide led by CISA (December 2023), the White House ONCD report (February 2024), and joint CISA/NSA guidance (June 2025)
• All of these are recommendations and guidance — not a ban on C/C++ and not a legal obligation. The ONCD report itself notes that Rust has not yet been proven in space systems
• Actual adoption is underway: the Linux kernel declared the Rust experiment concluded in December 2025, and Rust is present in parts of the Windows kernel and in Android
• In Android, memory-safety-related vulnerabilities fell from 76% of the total in 2019 to 24% in 2024 — driven by switching the language of new code, not by rewriting existing code
• Migrating COBOL/Java mainframe systems to Rust is not a realistic proposition. Java is already memory-safe, and COBOL's real risk is the loss of expertise and specifications — neither is solved by changing languages
• Rust's realistic domain is new kernels, drivers, cryptographic libraries, and network-facing parsers, where C/C++ remains the default
• The decades-old legacy systems GAO flags, and the end-of-support devices CISA ordered removed in BOD 26-02, are a present-tense attack surface independent of the language debate
• Rust eliminates memory safety bugs, not logic bugs, design errors, or supply-chain risk — and the risk of the rewrite itself should not be underestimated