AI-Assisted Incremental C-to-Rust Migration Framework for Critical Government Infrastructure

(AI-assisted Rust Migration and Optimization Resource) ARMOR

Executive Summary

The United States government has issued guidance strongly encouraging the adoption of memory-safe programming languages — particularly Rust — for critical infrastructure software. Yet the dominant approach to implementing this mandate remains unclear, and the tooling ecosystem is immature. This document proposes an AI-assisted incremental migration framework designed to make the transition from C to Rust practical, prioritized, and scalable for government agencies and defense contractors managing large, legacy codebases.

1. Background and Motivation

1.1 The Memory Safety Crisis

The majority of critical security vulnerabilities in systems software trace back to memory safety issues — buffer overflows, use-after-free errors, null pointer dereferences, and race conditions. These classes of bugs are endemic to C and C++, the languages that underpin virtually all major operating systems, kernels, and embedded systems in use by government agencies today.

According to data from Microsoft and Google, approximately 70% of all serious security vulnerabilities in their C/C++ codebases are memory safety issues. For national security infrastructure, this represents an unacceptable and persistent attack surface.

1.2 The Government Mandate

In recent years, agencies including the NSA, CISA, and the White House Office of the National Cyber Director (ONCD) have issued formal recommendations urging the adoption of memory-safe languages. Rust has emerged as the leading candidate for systems-level programming due to:

• Its ownership and borrowing model that eliminates entire classes of memory bugs at compile time

• Zero-cost abstractions that preserve the performance characteristics of C

• A growing ecosystem and increasing acceptance within the Linux kernel community

• Active adoption by major technology companies including Google, Amazon, and Microsoft

Despite this momentum, the primary challenge remains: how do you actually migrate decades of battle-tested C code without catastrophic risk?

1.3 The Gap in Current Tooling

Existing tools like C2Rust can perform mechanical transpilation of C code into syntactically valid Rust, but the output is unsafe Rust — essentially C code wearing a Rust disguise. It does not leverage Rust's core safety guarantees and requires substantial manual effort to refactor into idiomatic, safe Rust. There is currently no intelligent, prioritized, workflow-aware solution that bridges this gap at scale.

2. Proposed Framework: ARMOR

(AI-assisted Rust Migration and Optimization Resource)

ARMOR is a conceptual AI-assisted toolchain designed to make incremental C-to-Rust migration practical, secure, and measurable. It is not a fully automated transpiler — it is an intelligent workflow system that augments human engineers with prioritization, analysis, skeleton generation, and validation.

3. Core Principles

3.1 Incremental Over Wholesale

The framework explicitly rejects the idea of rewriting entire codebases at once. Instead, it identifies the smallest meaningful units of migration — individual modules, subsystems, or functions — and converts them one at a time while maintaining full interoperability with surrounding C code via Rust's Foreign Function Interface (FFI).

3.2 Risk-Driven Prioritization

Not all code is equally dangerous. ARMOR prioritizes migration targets based on:

• Historical vulnerability density — modules with prior CVEs or known exploit history

• Attack surface exposure — code that interfaces with untrusted input or network traffic

• Memory complexity — code with heavy pointer arithmetic, manual memory management, or complex ownership patterns

• Criticality — how deeply embedded the module is in security-sensitive execution paths

This ensures that the highest-impact conversions happen first, delivering security improvements incrementally rather than waiting for a complete rewrite.

3.3 Human-in-the-Loop

ARMOR is explicitly designed as an augmentation tool, not a replacement for skilled engineers. AI generates analysis, suggestions, and skeleton code. Humans review, refactor, and validate. The system accelerates expertise — it does not attempt to replace it.

4. System Architecture

4.1 Static Analysis Engine

The first layer performs deep static analysis of existing C codebases to:

• Map the full dependency graph of modules and functions

• Identify memory-unsafe patterns (unchecked pointer arithmetic, unsafe casts, manual malloc/free pairs, etc.)

• Score each module on a composite risk index

• Generate a prioritized migration queue

Tools in this layer would integrate with existing security analysis platforms such as Coverity, CodeQL, or custom LLVM-based passes.

4.2 CVE and Threat Intelligence Integration

ARMOR integrates with the National Vulnerability Database (NVD), MITRE CVE, and agency-specific threat intelligence feeds to cross-reference vulnerable modules against known exploit history. A module with three historical CVEs and active exploitation in the wild ranks far higher than one with theoretical risks.

This layer can also ingest CISA's Known Exploited Vulnerabilities (KEV) catalog and custom classified threat intelligence feeds for agency-specific deployments.

4.3 AI-Assisted Skeleton Generation

Once a migration target is selected, the AI layer generates a Rust skeleton — not a naive transpilation, but a structured outline that:

• Defines idiomatic Rust data structures corresponding to C structs

• Establishes proper ownership semantics and lifetime annotations where inferable

• Flags areas of ambiguous ownership that require human judgment

• Generates comprehensive test scaffolding based on the C module's behavior

• Provides inline commentary explaining each conversion decision

This is the "200 IQ" layer — rather than blindly converting syntax, the system reasons about intent and safety semantics, producing output that is closer to idiomatic Rust than raw transpilation.

4.4 FFI Boundary Management

During migration, converted Rust modules must coexist with surrounding C code. ARMOR automatically manages the FFI boundary layer, generating safe wrappers that:

• Handle type marshaling between C and Rust

• Enforce memory ownership at the boundary

• Log and monitor boundary crossings for validation and debugging

This is critical for incremental migration — you cannot convert everything at once, so the boundary layer must be robust and auditable.

4.5 Validation and Regression Testing

After each migration, ARMOR runs a validation suite that:

• Executes existing C test suites against the new Rust implementation

• Performs differential fuzzing between C and Rust versions to detect behavioral divergence

• Measures performance characteristics to ensure no regression

• Generates a formal migration report suitable for security auditing and compliance documentation

5. Deployment Model

5.1 On-Premises First

Given the sensitive nature of government codebases, ARMOR would be designed for fully air-gapped, on-premises deployment. No source code would leave the agency's network. The AI models would be pre-trained on open-source systems software and fine-tuned on internal data within the secure environment.

5.2 Tiered Access

• Tier 1 — Analysis Only: Read-only static analysis and risk prioritization. No code generation.

• Tier 2 — Assisted Migration: Full skeleton generation and FFI management. Requires cleared engineering review.

• Tier 3 — Full Workflow: End-to-end migration workflow with validation, CI/CD integration, and compliance reporting.

5.3 Integration with Existing DevSecOps Pipelines

ARMOR integrates with standard government DevSecOps toolchains including:

• RHEL-based build environments (the natural foundation for this work)

• GitLab CI/CD or Jenkins for automated validation pipelines

• STIG compliance checkers to ensure converted code meets DoD security baselines

• FedRAMP-compliant cloud environments for agencies not requiring air-gapping

6. Target Populations

6.1 Primary: Defense Contractors and National Labs

Organizations like MITRE, Sandia, and major defense primes maintaining large C codebases for classified systems. These organizations have the engineering talent to leverage ARMOR's output and the compliance requirements that make Rust migration a compelling priority.

6.2 Secondary: Civilian Federal Agencies

Agencies like DHS, NSA, and DoE managing critical infrastructure software where memory safety vulnerabilities represent genuine national security risks.

6.3 Tertiary: Open-Source Security Projects

Hardened Linux distributions, BSD kernels, and security-focused open-source projects could benefit from an open version of ARMOR, accelerating community-driven Rust adoption across the broader systems software ecosystem.

7. Challenges and Limitations

7.1 Unsafe Rust is Not a Destination

A naive migration produces unsafe Rust — code that compiles but retains the same risks as C. ARMOR must explicitly track the percentage of safe vs. unsafe Rust in converted modules and flag any output that leans too heavily on unsafe blocks as incomplete.

7.2 Concurrency and Async Complexity

Multithreaded C code is notoriously difficult to translate because Rust's ownership model enforces strict concurrency guarantees that may be incompatible with C's assumptions. ARMOR would flag these as high-complexity migration targets requiring senior engineer oversight.

7.3 Institutional Inertia

The human challenge may exceed the technical one. Engineers with decades of C expertise may resist Rust adoption. ARMOR's workflow should be designed to lower this friction by being additive rather than disruptive — it fits into existing workflows rather than replacing them.

7.4 Verification of AI Output

AI-generated Rust skeleton code must not be trusted without review. Rigorous human verification is mandatory. ARMOR should include confidence scores and explicit uncertainty flags on all generated output to guide reviewer attention.

8. Recommended Next Steps

1. Prototype the static analysis engine on a medium-sized open-source C codebase (e.g., OpenSSH or the Linux networking subsystem) as a proof of concept

2. Partner with a national lab or university security research group to validate the risk prioritization model against historical CVE data

3. Engage CISA and ONCD to align the framework with existing memory-safety guidance and explore potential federal funding mechanisms (SBIR/STTR grants are a natural fit)

4. Publish open research on the prioritization methodology to build credibility and community contribution

5. Develop a pilot program with a willing defense contractor to test the full workflow on a non-classified codebase before seeking classified deployment authorization

9. Conclusion

The government mandate for memory-safe programming is directionally correct but lacks practical implementation guidance for organizations managing large, legacy C codebases. ARMOR represents a pragmatic middle path: not a magic rewrite button, but an intelligent workflow that makes incremental Rust migration measurable, prioritized, and tractable.

By combining AI-assisted analysis with human engineering expertise, integration with real-world threat intelligence, and a rigorous validation pipeline, ARMOR could meaningfully accelerate the transition to memory-safe systems software across government and defense infrastructure — turning a vague policy mandate into an executable engineering roadmap.

End of Document Version 1.0 | June 2026 | Independent Research