Rust turns 10 years old as a stable language in 2025, and it has gone from a Mozilla side project to the language the U.S. government, Google, Microsoft, and AWS all point to as the fix for memory-corruption bugs. Google's Android security team reported that memory-safety vulnerabilities fell from 76% of all Android vulnerabilities in 2019 to 24% in 2024, a drop it directly credits to Rust adoption in new code. The White House Office of the National Cyber Director made the same argument in its February 2024 report "Back to the Building Blocks," urging vendors to migrate away from C and C++. But "memory safe" is not the same as "secure." Rust's own standard library shipped a critical, CVSS 10.0 command-injection bug in 2024 (CVE-2024-24576), and crates.io has already seen real typosquatting and credential-stealing packages. This post separates what Rust actually fixes from what it doesn't, with the specific incidents to prove it.
What Problem Does Rust Actually Solve?
Rust solves memory-corruption bugs — use-after-free, buffer overflows, double-frees, and data races — by enforcing ownership and borrowing rules at compile time instead of trusting developers to manage memory manually. In C and C++, the compiler will happily let you free a pointer and then read from it again; Rust's borrow checker rejects that code before it ever runs. This class of bug has historically been enormous: Microsoft engineers estimated in 2019 that roughly 70% of the CVEs it patched each year in Windows and other products were memory-safety issues. The NSA made the same case in its December 2022 "Software Memory Safety" guidance, explicitly naming Rust, Go, C#, Java, and Swift as memory-safe alternatives to recommend for new development. Rust achieves this without a garbage collector, which is why performance-sensitive teams — AWS's Firecracker microVM, Cloudflare's Pingora proxy, Discord's read-state service, and Linux kernel drivers as of kernel 6.1 — have adopted it in production rather than treating it as an academic exercise.
Does Rust Eliminate Memory Safety Vulnerabilities Entirely?
No — Rust eliminates most memory-safety bugs only in "safe" Rust, and every real Rust codebase still contains some unsafe blocks, FFI boundaries, and standard-library code where the old classes of bugs can resurface. unsafe exists precisely because low-level tasks — calling into C libraries, writing OS kernels, implementing certain data structures — sometimes require bypassing the borrow checker, and every unsafe block is an explicit opt-out that a security review needs to scrutinize like it would a C function. The standard library itself is not immune: CVE-2024-24576, disclosed in April 2024 and fixed in Rust 1.77.2, was a command-injection flaw in std::process::Command on Windows that improperly escaped arguments when invoking batch files, letting an attacker execute arbitrary shell commands through a crafted argument — NVD assigned it a maximum CVSS score of 10.0. An earlier bug, CVE-2022-21658, was a TOCTOU race condition in std::fs::remove_dir_all that let a local attacker delete files outside the intended directory, patched in Rust 1.58.1 in January 2022. Rust shrinks the attack surface dramatically; it does not zero it out.
Can Rust Projects Still Be Hit by Supply Chain Attacks?
Yes, and it has already happened on crates.io, Rust's central package registry, which now hosts well over 150,000 crates. In May 2022, a malicious crate named rustdecimal — a typosquat of the popular rust_decimal library — was published to crates.io and, once installed, ran a script that stole SSH private keys and environment variables from developer machines before the crate was pulled. Because Rust's Cargo.toml dependency model pulls in transitive dependencies automatically, just like npm or pip, a compromised crate three or four levels deep in a dependency tree can end up compiled directly into a production binary without anyone reviewing its source. Memory safety says nothing about whether the code you're compiling was written by the person you think it was. The RustSec Advisory Database, maintained by the Rust Secure Code working group, has logged several hundred advisories since 2016 covering exactly this gap — unsound APIs, unmaintained crates, and malicious or vulnerable dependencies that cargo audit alone won't catch unless a team runs it on every build.
Why Are Governments Now Mandating Memory-Safe Languages?
Governments are mandating memory-safe languages because the cost of memory-corruption bugs has become measurable and attributable at scale, not theoretical. The White House ONCD's February 2024 report went beyond guidance and asked software manufacturers to publish memory-safety roadmaps, explicitly citing Rust as a mature option for systems programming. CISA and the NSA followed their 2022 joint guidance with continued pressure through 2023 and 2024 encouraging vendors shipping C/C++ products to disclose memory-safety plans as part of Secure by Design commitments. Google's data point is the most concrete evidence to date: as Rust grew to represent over 20% of new code in the Android platform, zero memory-safety vulnerabilities have been discovered in Android's Rust code as of Google's September 2024 report, while memory-safety CVEs in the platform overall kept falling year over year. For regulators writing software liability and SBOM requirements, that's a rare case where a language migration produces a vulnerability trend you can actually chart.
What Do Real Rust CVEs Look Like in Practice?
Real Rust CVEs cluster into three buckets: standard-library escapes like CVE-2024-24576, unsound third-party crate APIs that silently allow memory corruption despite being written in "safe" Rust, and dependency-level supply chain issues unrelated to memory safety at all. The second bucket is the one most teams underestimate — RustSec has flagged dozens of crates over the years (including widely used ones in networking and serialization) for APIs that claimed to be safe but exposed undefined behavior when misused, because a crate author can mark a function safe even when it isn't truly sound, and the compiler has no way to verify that promise. This is why security teams can't treat "written in Rust" as a checkbox: a Griffin-style reachability question — is the vulnerable function in this crate actually called anywhere in our compiled binary — matters just as much for a RustSec advisory as it does for a CVE in a Python or Java dependency, because most published advisories affect code paths a given application never exercises.
How Safeguard Helps
Safeguard treats Rust the same way it treats every other ecosystem: by verifying which advisories actually matter for your binary instead of flagging every crate in Cargo.lock. Our reachability analysis traces whether a vulnerable function in a flagged crate — including RustSec advisories and CVEs like CVE-2024-24576 — is actually reachable from your application's call graph, cutting through noise from transitive dependencies that never execute. Griffin AI reviews unsafe blocks and unsound crate APIs during pull requests, flagging patterns that historically preceded advisories rather than waiting for a public disclosure. Safeguard generates and ingests SBOMs for Rust projects so you have an accurate, continuously updated crate inventory instead of a point-in-time snapshot, and when a fix is available, Safeguard opens an auto-fix PR that bumps the affected crate and its lockfile in one step. The result is Rust supply chain coverage that matches the language's actual risk profile — supply chain and unsafe-code review — instead of pretending memory safety alone covers you.