Every few years someone announces that memory-safety bugs are a solved problem. The CVE feeds disagree. Buffer overflows, use-after-free, and out-of-bounds reads and writes are not exotic edge cases; they are the single largest category of serious vulnerabilities in the software that runs banks, browsers, and industrial controllers. This is not a story about a fashionable language. It is a story about where risk actually lives, and what a sober engineering team should do about it.

Why the same bug keeps winning

For well over a decade, large organisations that publish their own numbers have landed on a strikingly consistent figure: roughly 70% of their serious security vulnerabilities are memory-safety issues. Microsoft reported this for its own products years ago; Google has reported similar proportions for Chrome. The specific percentage moves with the codebase and the year, but the shape of the finding does not.

The reason is structural, not a matter of programmer skill. Languages such as C and C++ give the developer manual control over memory, and with it the standing ability to read past the end of a buffer, use a pointer after the memory it referenced has been freed, or miscount by one. Skilled engineers write these bugs anyway, because a single mistake in a codebase of millions of lines is enough, and because the compiler was never asked to stop them. You cannot review your way out of a class of error that any line of code can silently introduce.

What the agencies are now saying

The policy conversation has moved from encouragement to expectation. In June 2025, CISA and the NSA published joint guidance titled Memory Safe Languages: Reducing Vulnerabilities in Modern Software Development. It is not a Rust advertisement. It names the real obstacles to adoption, including interoperability and hiring, and it argues that memory-safe languages (a category that includes Rust, Go, Java, C#, and Python) are the most comprehensive available mitigation for this class of defect.

Crucially, the guidance does not ask anyone to rewrite their codebase. The recommended posture is a published memory-safety roadmap: write new code in a memory-safe language where practical, and prioritise the highest-risk components first, typically network-facing code and anything handling cryptography or untrusted input. This sits inside CISA's broader Secure by Design programme, which treats security as a property built in during development rather than bolted on afterwards.

The evidence that gradual works

The most useful data point comes from Android. Google reports that the share of its vulnerabilities attributable to memory safety fell from about 76% in 2019 to roughly 24% by 2024, and has continued to decline since. What makes this compelling is the method. Google did not rewrite Android. It focused on writing new code in memory-safe languages, Rust among them, under a practice it calls Safe Coding. Because most vulnerabilities are found in newer code, shifting the newest code to a safer language moved the numbers faster than anyone expected, without touching the enormous existing C/C++ base.

That is the headline for teams with legacy systems: you do not need a heroic rewrite to bend your own curve. You need a boundary, and discipline about what goes on each side of it.

An honest account of the trade-offs

Rust earns its reputation by moving whole categories of error to compile time through its ownership and borrowing model. It is not, however, a security cure-all, and pretending otherwise does clients a disservice:

  • Logic and design flaws remain. Rust will not stop you from writing a broken authentication check or a flawed access-control rule. Memory safety is one class of bug, not all of them.
  • unsafe exists for a reason. Interfacing with hardware, C libraries, or performance-critical code often requires unsafe blocks, where the compiler's guarantees are suspended and the old rules apply. These blocks should be rare, small, and reviewed closely.
  • The supply chain is still the supply chain. A memory-safe language does not vet your dependencies. The wider ecosystem tracks its own advisories precisely because a safe language can still pull in a flawed or malicious crate.
  • Adoption has a real cost. The learning curve is genuine, the hiring pool is smaller, and interoperability with existing C/C++ takes engineering effort. These are the very frictions the CISA guidance acknowledges.

What this means for your team

If you own a C/C++ codebase, the pragmatic reading is neither panic nor dismissal. It is this: memory-unsafe code is now a documented, quantifiable liability that regulators, insurers, and increasingly customers will ask about. A credible response is modest and specific. Draw a boundary around your most exposed components. Write genuinely new modules in a memory-safe language where the cost is justified. Keep hardening the existing C/C++ with the tools already available, including sanitisers, fuzzing, and static analysis. And write down the plan, because a short, honest roadmap is worth more than a rewrite you will never finish.

The shift toward Rust is real, and the data behind it is sound. But the deeper change is quieter: memory safety has become something teams are expected to have an opinion about, and a plan for. Having that plan, sized to your actual risk and budget, is now simply part of building software responsibly.