Moving from C/C++ to Rust: you don't need to rewrite everything

"Rewrite everything in Rust" sounds appealing, but for a codebase with millions of lines of C/C++ it's almost never feasible: it takes years, halts feature work, and the rewrite brings new bugs of its own. The good news is you don't need to. Android's data shows a far cheaper strategy that works surprisingly well: write new code in a memory-safe language and leave old code alone. US and allied cybersecurity agencies also urge companies to publish roadmaps along these lines.

The key finding: vulnerabilities "decay" with code age

• Most vulnerabilities live in new or recently modified code. The older code is, and the longer it's been used and tested, the more its bug density drops exponentially, like a half-life.
• From around 2019, Android prioritised writing new code in memory-safe languages, without rewriting old code.
• The result: memory safety bugs as a share of Android vulnerabilities fell from 76% (2019) to 24% (2024), and per preliminary 2025 data dropped below 20% for the first time, even though most existing code is still C/C++.

The implication: switching languages for new code pays off much sooner than intuition suggests.

A four-step roadmap

1. Measure the baseline: categorise vulnerabilities by type and component; find out what share are memory bugs.
2. Stop the inflow of new bugs: require new code in Rust (or another suitable memory-safe language), starting with new components.
3. Replace selectively: rewrite the highest-risk parts first: parsers, codecs, code handling data from untrusted networks or files.
4. Harden the rest: legacy C/C++ keeps using fuzzing, sanitizers, sandboxing and checked libraries.

A roadmap per CISA/NSA guidance

The guide "The Case for Memory Safe Roadmaps" (CISA, NSA, FBI and the cyber agencies of Australia, Canada, the UK and New Zealand) urges software makers to publish a roadmap including: phases with dates and concrete outcomes, a date for using memory-safe languages in new systems, developer training, and a plan for interoperation between old and new code.

Letting Rust and C/C++ coexist

The FFI boundary is where bugs hide most easily: data crossing it is no longer fully protected by the Rust compiler, so review it carefully.

Automatic translation with AI?

DARPA's TRACTOR programme aims to automatically translate C to Rust at the quality of a skilled Rust developer, combining static analysis, dynamic analysis and LLMs. Assistants like Claude Code can also translate small modules. But machine-translated output often leans on unsafe or isn't idiomatic Rust; treat it as a draft, with tests comparing behaviour against the C version, reviewed like human-written code.

Risks and caveats

• Learning curve: ownership and borrowing take time; Google's free Comprehensive Rust course is used for internal training.
• Ecosystem and toolchains: some embedded platforms and specialised compilers may not be fully supported.
• Don't rewrite for "cleanliness": rewriting stable, low-bug legacy code can introduce new bugs.
• Measure results: track the share of memory bugs among new vulnerabilities each quarter to show the roadmap is working.

How to apply it

• Dev: Pick a small, self-contained module that handles external input as your first Rust component; integrate with cxx or FFI.
• Tech Lead: Write a "new code in Rust" policy with a clear list of exceptions; set up Rust CI (clippy, tests, dependency audits).
• PM: Build a dated memory-safety roadmap following the CISA framework; report the memory-bug share as a quality metric.