Memory-safe languages: a practical migration roadmap

Memory-safe languages eliminate or constrain vulnerability classes such as use-after-free, double-free, out-of-bounds access and some data races. They do not make an application automatically secure, but they shrink the space in which one coding error can become code execution.

CISA and its partners recommend that software manufacturers publish roadmaps for adopting memory-safe languages. A credible roadmap does not begin by rewriting an entire product.

Find the memory risk first

Map components written in C and C++, then combine that inventory with vulnerability, exposure and privilege data. Prioritise untrusted-data parsers, network services, codecs, drivers, privileged agents and libraries reused across many products.

Ask:

• does the component process internet-controlled input;
• does it run with elevated privileges;
• how often does it produce memory-safety defects;
• how widely is the library reused;
• is there a stable interface around the module;
• can the team operate the replacement safely?

Three migration paths

First, select a memory-safe language for suitable new services and tools. Second, replace high-risk modules incrementally behind a controlled FFI boundary. Third, isolate code that cannot yet be replaced through sandboxing, process separation, least privilege and reduced input complexity.

Rust is a strong option for systems code, while Java, C#, Go, Swift and Kotlin provide suitable memory safety for many workloads. Choose through runtime constraints, latency, ecosystem and team capability rather than fashion.

Treat FFI as a trust boundary

An unsafe block in Rust is not inherently a defect. It is a location that needs a small surface, explicit invariants and stronger review. Validate lengths, object ownership, lifetimes and errors returned by native libraries. Fuzz both sides of the boundary.

A migration that leaves an uncontrolled C dependency underneath merely moves the risk. Connect the programme to software supply-chain security.

Measure meaningful progress

Measure the amount of code exposed to untrusted input, critical components remaining in memory-unsafe languages and new functionality delivered in memory-safe languages. Track unsafe blocks, fuzzing coverage and time to remediate memory-safety findings.

A useful roadmap has owners, budget, milestones and retirement criteria. A percentage of Rust code alone does not prove that the riskiest execution path is safer.

A 90-day starting plan

1. Inventory C/C++ components and exposure.
2. Select one high-risk module with a stable interface.
3. Define FFI, unsafe, testing and dependency standards.
4. Build a prototype and equivalence tests.
5. Run fuzzing and performance measurements.
6. Roll out gradually with a rollback path.
7. Record lessons and expand the programme.

A memory-safe language is a design control, not a replacement for threat modelling, authorisation or application security requirements. It delivers the most value when it removes dangerous defect classes from the most exposed components.

---

The boundary between safe and unsafe code

Migration does not remove risk automatically. unsafe, FFI, binary parsers and drivers need a separate inventory, owners and tests. Keep interfaces between old and new components small, validate lengths and ownership on both sides, and focus fuzzing on those boundaries.

Choose components by exposure and defect history, not language fashion. A network parser or service repeatedly affected by memory flaws is a useful candidate. Measure critical surface in memory-safe code, size of unsafe blocks, performance regressions and defects of the target class. Include libraries, compilers, training and maintenance in the plan.

Sources: CISA — Eliminating Buffer Overflow Vulnerabilities, NSA — Software Memory Safety, Rust Reference.