Rust deletes an entire class of software defect at compile time — the same class that produces most of the vulnerability findings federal programs spend their year triaging. Since 2022 that has stopped being an engineering preference and started being written into federal guidance.
Ask an engineer why Rust and you will get an answer about ownership and borrow checking. Ask someone who has to get a system authorized and the useful answer is shorter: because the federal government has spent four years telling software vendors to stop writing new systems in languages that cannot prevent memory corruption, and because the defects Rust eliminates are the same defects that generate most of the vulnerability findings a program spends its year triaging.
Rust is a systems language. It does the job C and C++ do — close to the hardware, no garbage collector, no runtime to install alongside it — and adds a compiler that refuses to build code containing a whole family of memory errors: buffer overflows, use-after-free, double frees, dangling pointers, and data races between threads. In C those are runtime surprises, found by a fuzzer, a scanner, or an adversary. In Rust they are compile errors. The defect is not shipped and later patched. It never becomes a defect.
Memory-safety defects are not an exotic corner of security. They are the substrate. For decades, roughly seven in ten serious vulnerabilities in large C and C++ codebases have traced back to memory handling, and the industry response was always the same: better static analysis, stricter coding standards, more code review, more fuzzing. Those things help. None of them eliminate the class, because they are all attempts to catch a mistake the language permits.
The cleanest public before-and-after is Android. Google did not rewrite it. It began writing new code in memory-safe languages, Rust among them, and let the old code age in place. The result over five years is the strongest available evidence that the approach works at scale.
What changed is not the engineering argument, which has been settled for a while. What changed is that the argument moved into federal guidance, and it did so steadily enough that it now reads as direction of travel rather than opinion.
NSA published a information sheet on memory-safe languages in 2022 and reissued it jointly with CISA in June 2025. Rust is named in both. In February 2024 the Office of the National Cyber Director published Back to the Building Blocks, which argued that the highest-leverage way to reduce memory-safety vulnerabilities is to change the language rather than to keep auditing the code. In October 2024, CISA and the FBI went further in Product Security Bad Practices: developing new critical-infrastructure product lines in a memory-unsafe language, where a safe alternative exists, is listed as dangerous, and manufacturers of existing products were expected to publish a memory-safety roadmap by January 2026.
DARPA put money behind the same conclusion. Its TRACTOR program funds work on automatically translating legacy C into idiomatic Rust, on the reasoning that manual translation of the government's C estate would take years and cost billions. When an agency starts funding tooling to get off a language, the direction is no longer ambiguous.
The federal question is no longer whether memory safety matters. It is whether you can show what you are doing about it.
This is our read rather than published policy, so treat it as analysis. No language grants an ATO, and no assessor will hand you controls because of a compiler. The effect is indirect and it is real.
A large share of what accumulates on a POA&M during assessment and continuous monitoring is CVE-driven: a scanner flags a vulnerable component, the finding lands under RA-5, someone triages it, patches or justifies it, and defends the milestone. Memory-safety defects feed that stream disproportionately, and they feed it forever, because each new release of a C dependency can introduce another one. Removing the class at compile time does not empty the POA&M — misconfiguration, dependency currency, and access-control findings all remain — but it takes a recurring generator of findings off the board. Controls like SI-16 (memory protection) and SA-11 (developer testing) also get materially easier to evidence when the answer is structural rather than procedural.
Two properties matter in government environments more than they do elsewhere. Rust compiles to a single native binary with no interpreter, virtual machine, or runtime to install, which makes deployment into airgapped and low-to-high environments considerably less painful: one artifact to scan, transfer, and account for, and a smaller hardening surface than a stack that drags a language runtime behind it.
The second is that there is no garbage collector, so there are no collection pauses. For anything with a latency budget — sensor processing, network inspection, cryptographic paths, control loops — performance is predictable in the way C is predictable, which is the reason those systems were written in C to begin with. Rust is one of the few memory-safe options that does not ask you to give that up.
Credibility here requires saying what the enthusiasm gets wrong.
Rewriting working code is usually a bad trade. Federal guidance targets new development and high-priority components, not blanket rewrites. Mature C that has survived twenty years of production has had its bugs found the hard way; a fresh Rust implementation has not. The sound pattern is new components in Rust, and the parsers and network-facing code that handle untrusted input replaced first.
The hiring pool is smaller. Add a clearance requirement and it is smaller still. On a cleared program that constraint can outweigh the language's advantages, and pretending otherwise helps nobody.
The learning curve is real. Engineers fluent in C are productive in Rust in months, not days. Budget for it honestly.
Safe does not mean invulnerable. Rust has an unsafe escape hatch that exists for good reasons and can be misused. It does nothing about logic flaws, injection, bad authorization decisions, or a compromised dependency, and its package ecosystem creates the same supply-chain questions every modern ecosystem does. Memory safety removes one class of bug. It is not a security program.
We made this choice for our own product work rather than only recommending it. Tessera, our own application, is written in Rust — chosen for the same reasons above: a defect class we would otherwise have to defend for the life of the system, a single deployable artifact that behaves well in restricted environments, and predictable performance without a runtime underneath it. It is a small commitment compared with a federal C estate, but it is the same reasoning, and we would rather have run it ourselves before advising anyone else to.
Whether the right answer is Rust, a memory-safety roadmap for code you already own, or neither, we will tell you straight — and what it means for your authorization timeline.
Talk to AusperThis site uses essential browser storage only. With your OK, we’d also use analytics cookies to understand which content is useful. No choice is required — “Essential only” changes nothing. Cookie policy