A memory-safe migration succeeds when the roadmap reaches dependencies and operations

The documented foundation

CISA and partner agencies' December 2023 roadmap guidance recommends planned transitions to memory-safe languages, with scoped pilots, training, dependency plans, and published progress. It emphasizes choosing languages appropriate to a use case and notes that memory-safe languages still permit other kinds of vulnerabilities.

The agencies' 2024 open-source study explains memory-safety defects such as buffer overflows and use-after-free. Its analysis of three projects written in memory-safe languages found dependencies containing memory-unsafe code. That finding illustrates why a migration must examine the complete dependency path, not just the language of a project's own files.

Source: CISA and partners: The Case for Memory Safe Roadmaps · CISA and partners: Exploring Memory Safety in Critical Open Source Projects

Analysis: Choose a boundary with a useful outcome

A migration project is easier to evaluate when its scope corresponds to an understandable function. A bounded component can have inputs, outputs, and behavioral expectations that reviewers can compare before and after a change. The boundary should be selected deliberately rather than defined only by whichever files are easiest to rewrite.

Consider a hypothetical service that accepts uploaded documents and extracts a small set of fields. A pilot might focus on one parsing stage. The team would need to say which inputs enter that stage, what the result must preserve, and which surrounding components remain outside the migration. That creates a concrete claim about progress without suggesting that the entire service has changed.

Follow the dependency that carries the risk

The open-source study supports a narrow but important observation: a project written in a memory-safe language can still depend on components written otherwise. It does not establish that every such dependency is exploitable or that every project has the same exposure.

For the illustrative parser, the next practical question would be what code actually processes the input along the chosen path. If the new component still delegates the relevant operation to an unchanged dependency, the intended reduction needs closer examination. The result may still have value, but it should be described accurately. A useful review distinguishes the changed code, retained components, and assumptions about their interaction.

Source: CISA and partners: Exploring Memory Safety in Critical Open Source Projects

Analysis: Preserve behavior while changing implementation

A security-motivated migration still has to provide the service people rely on. An implementation that handles memory differently but silently changes valid outputs can create a separate operational problem. The acceptance criteria should therefore include both the targeted risk reduction and the behavior that must remain intact.

A pilot could compare representative valid inputs, malformed inputs, and interrupted operations under a documented procedure. Differences should be investigated rather than automatically labeled regressions or improvements. Some differences may be intentional corrections; others may expose an undocumented requirement. The important practice is to decide which behavior is expected and record the reason, instead of allowing whichever implementation happens to run to define correctness.

Make the team part of the design

The roadmap guidance includes developer training, debugging, tooling, build integration, and quality-control processes. That is a reminder that changing a language also changes the work needed to maintain the software.

An actionable pilot should leave behind more than a functioning replacement. Another engineer should be able to build it, investigate a failure, and understand the migration boundary. A team could use those tasks as explicit completion criteria. This is a proposed evaluation method, not a claim that a particular language requires a fixed learning period. It makes operational readiness observable and reduces the temptation to declare completion when only the original author can support the new component.

Source: CISA and partners: The Case for Memory Safe Roadmaps

Report progress without claiming complete safety

A useful progress report can identify the migrated function, remaining dependencies, relevant test evidence, and unresolved work. It should keep the memory-safety objective distinct from other security properties, such as authorization or business-logic correctness. A migration can make a meaningful contribution without settling all of them.

The most useful next milestone is one that changes a specific, inspectable part of the risk picture. That might be replacing a dependency on the selected input path, documenting an unavoidable interface, or completing a pilot that another team can maintain. A roadmap organized around such outcomes can support sustained work. A percentage of rewritten lines, by itself, would leave readers unsure whether the code that mattered most was included or whether the operational burden was understood.