AI重写53万行代码转Rust 内存安全漏洞治理启示

一、事件：53万行Zig代码被AI译为Rust

JavaScript 运行时 Bun 的创始人 Jarred Sumner 近日公布了从 Zig 迁移到 Rust 的完整技术细节，这被视为目前规模最大的一次公开的 AI 辅助代码库迁移。据项目方披露，迁移涉及 535,496 行代码、1,448 个文件，翻译阶段由一名工程师调度约 64 个并行的 AI 编程实例完成，耗时约 11 天；整个项目从启动到 v1.4.0 正式发布用时约四个月，而原先的人工估算是一年。

要解决的核心问题很明确：反复出现的内存安全缺陷。释放后使用、重复释放这类缺陷只要代码规模变大，人力审查就难免遗漏，而 Rust 的借用检查器能在编译期把它们拦住。迁移带来的收益也不只是“更安全”——据第三方整理的项目数据，进程内存从此前一路攀升超过 6.7GB 变为稳定在约 609MB，Linux 二进制体积从 88MB 降到 70MB，同时修复了上百个长期存在的缺陷，AI 调用的 API 成本约 16.5 万美元。

二、内存安全为什么成了漏洞治理主战场

把它称为主战场并不夸张。微软、谷歌与美国国安局多年的统计都指向同一个结论：约七成的严重安全缺陷属于内存安全类问题，也就是 C、C++ 这类手工管理内存的语言容易引入的越界读写、释放后使用与类型混淆。

谷歌安卓团队公布的实测数据更直观：在大量引入 Rust 之后，安卓平台内存安全类漏洞占比首次降到两成以下，Rust 代码的内存安全漏洞密度比 C/C++ 低约一千倍，代码回滚率只有 C++ 的四分之一。政策层面的推动同样明确：白宫国家网络主任办公室在《回归基础构件》报告中呼吁开发者转向内存安全语言，CISA 与 NSA 等机构发布的《内存安全路线图》则要求软件厂商公布自己的迁移计划。

不过安卓项目同时承认，平台中仍有超过七成的代码由内存不安全语言写成，全量重写在工程上并不现实。也正是这一点，让 Bun 的迁移格外受关注——它至少证明，全量重写也许真的能在几个月内完成。

三、AI大规模重写代码的三重风险

但“能编译、能通过测试”与“语义完全等价”是两件事。对安全团队来说，至少有三个地方要看住。

① unsafe 与 FFI 边界。Rust 的安全保证只覆盖安全代码，与宿主引擎、C 库交互的角落必须写进 unsafe 块，争议和漏洞高发区恰恰在这里。把几十万行手工内存管理代码交给模型翻译，最需要人工复核的就是这些边界。

② 语义漂移。原始实现是手工内存管理，又要与自带垃圾回收的 JavaScript 引擎在同一进程内深度交织，一旦在锁的顺序、错误处理、资源释放时机上出现偏差，表现出来的往往不是编译错误，而是难以复现的内存泄漏与随机崩溃。

③ 审计责任。代码由 AI 生成，出问题谁来负责？如果团队把重写当成绕开历史技术债的捷径，等于把未经审计的产物直接送进构建链。Zig 创始人 Andrew Kelley 随后发布的公开回应就指出，更换语言解决不了工程治理问题，双方的争论至今没有定论。对国内单位而言，这件事的参考价值不在于选哪种语言，而在于任何一次大范围代码改写，都必须先回答“谁来审、怎么审、审到什么程度”。

四、对青海政企的落地建议

省内单位的自研与定制系统规模远小于 Bun，但风险结构是相似的，有四件事不必等预算也能做。

第一，摸清内存不安全资产。把自研系统、外包定制系统与第三方组件里的 C/C++ 部分列出来，重点标注直接解析外部输入、暴露在网络边界的模块，例如网关、协议解析器、文件格式处理组件——这正是近两年被利用最多的位置。

第二，先加固，再谈重写。对存量 C/C++ 代码开启编译期缓解措施，接入内存检测、静态分析与模糊测试，并把结果纳入等保整改中“安全计算环境”的测评准备材料。这类工作成本低、见效快，比重写现实得多。

第三，新增代码优先选用内存安全语言，并把要求写进采购与外包合同。软件采购时可以直接要求供应商说明主要开发语言、是否发布内存安全路线图、漏洞披露与响应机制，把这几项列为验收条件。

第四，给 AI 辅助重构设人工关卡。真要引入 AI 大规模改写代码，上线前至少要有静态扫描、第三方代码审计与回归压测三道验证，并明确源码归属与许可证责任。对医疗、教育、政务类客户而言，代码层的内存安全风险通常不会在等保测评中直接暴露，一旦被利用，后果却落在业务连续性上；把代码审计与漏洞扫描打包成年度动作，比立项重写更容易通过。