From the Cisco edition of October 31, 2026
Preprint: automated C-to-Rust refactoring tools left original memory-security bugs and introduced new ones on 116 NIST Juliet test programs
Hung-Mao Chen, Xu He, Bo Lu, Xiaokuan Zhang, Kun Sun (arXiv preprint) · Academic software-security research · Not stated on the abstract page; method uses the U.S. NIST Juliet Test Suite
- Publisher
- arXiv
- Original publication
- arXiv, submitted Sept. 22, 2026 (v1)
- Source retrieved
- 2026-11-01
What happened
Preprint, not peer reviewed. The authors evaluated four automated C-to-Rust refactoring approaches (C2Rust-analyze, CROWN, C2SaferRust and FLOURINE), some using LLMs, on 116 C programs with memory security bugs from the NIST Juliet Test Suite, producing 464 Rust programs. 342 failed to compile, 177 inherited memory security bugs from the original C, and 77 new Rust bugs were introduced. They conclude the tools deliver memory safety as they define it, but not broader memory security. Why now: Cisco’s president said on Oct. 30-31 that AI-assisted rewriting could speed Cisco’s migration to memory-safe languages; this is the most relevant independent evidence on that claim.
Why it matters
Gives SLED security leaders an independent check on vendor claims that AI or automated translation into memory-safe languages makes software safer. It applies to Cisco’s stated direction and to agencies considering similar modernization of their own C/C++ code.
Evidence and measured results
Empirical study on a standard synthetic test suite (116 programs, four tools, 464 outputs), measuring compilation, inherited bugs and new bugs. Read from the arXiv abstract page.
Limitations and uncertainty
Preprint, not peer reviewed; I read the abstract page, not the full paper. Juliet programs are small synthetic test cases, not production networking code. The tools studied are research tools, not Cisco’s (unknown) toolchain. The study does not evaluate the general-purpose LLM coding agents Cisco may use.
Put this evidence to work
Lighthouse Advisory interpretation, grounded in this source. Enriched 2026-11-01; this does not change the original publication date. Each role follows the same checklist so takeaways compare across sources.
Sales
Role takeaway
- Customer problem
- Customers hear that rewriting code in memory-safe languages, increasingly with AI, removes vulnerabilities, but have no independent evidence of how well that works.
- Stakeholders
- CISO
- Application security lead
- Software modernization program manager
- Discovery questions
- What evidence would you require before crediting a rewrite with security improvement?
- Do your acceptance tests include known-vulnerability regression?
- Value hypothesis
- Bounded: adding security regression to modernization acceptance avoids false assurance from translation alone.
- Potential engagement
- Security-acceptance criteria workshop for an existing or planned code modernization effort.
- Unsupported claims
- That AI or automated translation guarantees memory security
- That Cisco’s rewrite will or will not succeed
- Results transfer directly to production networking code
Pre-sales engineering
Role takeaway
- Fit
- Evaluation evidence for any automated or AI-assisted C/C++ translation.
- Architecture and integration
- Applies to CI pipelines: compile checks, known-bug regression, fuzzing and static analysis on translated output.
- Prerequisites
- Known-vulnerability test cases for the code being translated
- Static analysis and fuzzing tooling
- Constraints
- Synthetic Juliet programs; research tools only
- Preprint not peer reviewed
- Security
- Translation can inherit or introduce memory-security bugs; test the output.
- Proof of value
- Re-run original vulnerability test cases on translated code
- Count new defects introduced by translation
Delivery
Role takeaway
- Work
- Add security regression to modernization acceptance tests.
- Dependencies
- Test corpora
- Security tooling in CI
- Ownership
- Application security lead.
- Skills and adoption
- Teams need Rust and secure-coding review skills.
- Governance checkpoints
- Security sign-off requires regression evidence, not just translation rate
- Acceptance criteria
- Proposed: zero inherited known vulnerabilities in translated modules before release
- Proposed: new-defect count reported per release
- Risks
- False assurance from language migration
- Rework from compile failures
Implementation considerations
Lighthouse Advisory interpretation across the operating dimensions a public-sector buyer must settle before this evidence becomes a design. Each note answers the question under its heading for this specific source.
Architecture and integration
What must connect, and where does the AI sit in the workflow?
Translated code needs compile, behavior and security testing; reducing “unsafe” Rust is not the same as removing vulnerabilities.
Governance
Who approves, reviews and stays accountable for outcomes?
Vendor and agency claims of memory-safety gains should be backed by security test results, not just the share of code translated (interpretation).
Security and privacy
What data, permissions and controls need testing?
Automated translation can carry original memory-security bugs forward and introduce new ones, so a rewrite does not substitute for vulnerability testing.
Accessibility and workforce
Who is affected, and what skills or accommodations follow?
Rust and secure-code review skills are needed to judge translated code; the study implies human expertise remains essential.
Procurement
What should contracts, pricing and exit terms secure?
Supports requiring security test evidence, not just a language-migration claim, in vendor questionnaires and modernization contracts (interpretation).
Operating model
Which teams own the service once it runs?
Security regression testing becomes part of every translation-based modernization release cycle.
Publication history
- 2026-10-31Cisco · Issue 035 resources
Stable resource ID: arxiv-c-to-rust-fallacy-automatic-refactoring-not-memory-security-20260922