Rewrite in Rust or harden the C? A decision guide by component

Do not decide for the whole code base. Rank components by exposure, then pick per component: new code in a memory safe language, a rewrite of the riskiest exposed parsers, hardening for stable code, and retirement for dead code. That matches the guidance from CISA, the ONCD report and Android's documentation.

What the sources recommend

• CISA's bad practices guidance says new product lines should be developed in memory safe languages when readily available, and that existing products need a prioritized plan, starting with network facing and cryptographic code.
• The ONCD report suggests a hybrid approach for existing code: identify critical functions or libraries by risk criteria and rewrite those first.
• Android's documentation says rewriting all existing unsafe code is not feasible, and that Rust complements the tools.

The decision table

• New feature or service. Any exposure, high change rate. Use a memory safe language from day one.
• File or network parser. High exposure, medium change rate. Rewrite first, or isolate it and fuzz it.
• Cryptographic code. High exposure, low change rate. Use a vetted library, then review your wrapper.
• Stable internal tool. Low exposure, low change rate. Harden with flags, sanitizers and library checks.
• Dead or duplicated code. No exposure. Remove it.

Questions to ask for each component

1. Does it process input from outside your trust boundary?
2. How often did it have memory bugs in the past? Use your own bug history, not a general feeling.
3. How big is it, and who understands it?
4. Does a mature library already do the same job in a memory safe language?
5. What does the interface to the rest of the code look like? A narrow, well defined boundary is cheap to cross.

Costs the team will meet

Rewrites take staff time and carry their own bugs. Chromium notes that bridging a new language to C++ has its own expense. Mixed code bases also need two toolchains and some training. Counting those costs up front prevents a half finished migration.

Reading the bug history

The best input for the decision table is your own past. Pull the last two years of fixed vulnerabilities and tag each with its component and weakness class. If three components account for most of the memory bugs, those are your first candidates, whatever their size. If memory bugs are rare in a component that is stable and unexposed, hardening is probably the better use of staff time.

Add reachability to the picture. A vulnerable function that no input can reach is a lower priority than one on a network path. A tool that traces calls from your entry points can help you tell them apart before you plan a rewrite.

Signs a rewrite is the wrong choice

• The component is small, stable and unexposed.
• Nobody on the team can review the new language yet.
• The interface to the rest of the system is wide and unstable.
• A vetted library already does the job.

Interim hardening

While a rewrite is pending, use the compiler flags, library hardening and sanitizer runs from the earlier posts. CISA's guidance also lists interim steps such as compiler and hardware controls.

Try it yourself

Click through it at your own pace, or open it full screen. Look at how reachability changes which findings you would fix first.

Quick check

Sources

• CISA, Product Security Bad Practices
• Back to the Building Blocks, ONCD, February 2024
• Android memory safety documentation
• Chromium memory safety page

Last reviewed: 19 October 2026.