Rust 在安全关键软件:机遇、挑战与未来之路

编译器已经在帮你"做安全"了——但要把 Rust 真正送进飞机、汽车和 ICU，还差什么？

背景：什么是"安全关键"软件？

在汽车、航空、医疗、工业自动化等领域，软件一旦出错，可能造成人身伤亡或环境灾难。这类软件被称为安全关键软件（Safety-Critical Software）。

各行业有对应的标准来管控风险：

等级越高，对开发流程、验证方法和证据文件的要求就越严苛——成本也成倍增加。

Rust 已经在生产环境中跑起来了

这不是未来的故事，而是正在发生的现实。

工业机器人领域：一家移动机器人公司的首席固件工程师分享了他们的经历——过去用 C 语言开发 IEC 61508 SIL 2 级安全系统时，需要依赖昂贵且不好用的第三方静态分析工具；切换到 Rust 之后，"大约 90% 原本需要外部工具检查的内容，直接由编译器完成了"，加上已经有安全认证的 Rust 编译器可以引用，成为了一个真正的突破。

医疗设备领域：某公司正在向 ICU 重症监护室部署 IEC 62304 Class B 级别的 EEG（脑电图）分析软件，所有生产代码均用 Rust 编写，并且将原有的 Python 组件替换为 Rust 后，性能提升了 100 倍。

这些都是经过监管审计、真正在受控环境中运行的系统。路是有的，问题是怎么让后来者走得更容易。

Rust 的核心价值：让编译器来做安全工程师的工作

安全关键领域的工程师花费大量时间在防止内存错误、竞争条件、未定义行为上，而这些恰恰是 Rust 编译器天然强制保障的。

多位受访工程师指出：

• 约 90% 原本需要 MISRA C、CERT C 等外部规范或静态分析工具才能检查的问题，Rust 编译器在编译期就直接拦截了；
• Rust 对错误处理有统一且被生态系统广泛采用的方式（Result + ? 运算符），减少了因"各写各的"引发的隐患；
• 对于拥有数十甚至上百名开发者、产品生命周期长达 15~20 年的项目，编译器强制的不变量比"我们要更努力地做代码审查"更可扩展。

某汽车大厂的工程师说得很直白："我们无法控制每一位开发者的技能水平，必须依靠工具做代码质量把关。Rust 的编译期检查和 Clippy，对我们的领域非常有用。"

挑战一：越往高关键级走，生态越稀薄

Rust 在安全关键领域的采用，呈现出清晰的分层结构：

低关键级（QM 级）：相对自由

团队可以从 crates.io 自由引用第三方库，快速搭建原型，然后逐步加固。

高关键级（ASIL B+）：几乎寸步难行

第三方依赖难以通过审计，团队的典型做法是：

1. 自行重写核心组件，不依赖任何第三方 crate；
2. 构建抽象层，为未来替换做准备；
3. 把 crates 当作"早期加速器"，在进入关键路径之前彻底清除。

一位航空领域的工程负责人说得更极端："在航空领域，我们必须拥有所有代码，必须掌控每一行代码。"

目前，以下关键基础设施在 Rust 生态中仍是空白或尚未成熟：

• 无 MATLAB/Simulink 的 Rust 代码生成
• 无与 OSEK / AUTOSAR Classic 兼容的 Rust RTOS
• 工具链认证与资质评定流程尚在完善中

挑战二：工具链稳定性 vs. 依赖漂移

安全关键团队倾向于锁定 Rust 工具链版本，以确保可重复构建。但问题随之而来——绝大多数 crate 都是面向最新版本编译器开发的，版本锁定会导致依赖降级，非常耗时。

某汽车大厂工程师抱怨道："我们可以锁定 Rust 工具链，但因为几乎所有 crate 都是为最新版本实现的，我们不得不反复降级。这非常耗时。"

值得庆幸的是，Rust 的 Edition 系统（版次机制）被多位受访者称赞为"对汽车行业是黄金"——它支持代码库的渐进式迁移，而非强迫一次性大改。

挑战三：目标平台支持有盲区

安全关键软件通常运行在长期维护的平台和 RTOS 上。即使 Rust 名义上"支持"某个目标，细节中可能藏着坑。例如，QNX 8.0 的 Rust 支持目前仅限于 no_std 模式，这对很多场景来说远远不够。

一位资深工程师描述了他的经历："有一次我升级编译器后，我们用的 Tier 3 目标的工具链和依赖全坏了。这完全不可接受。如果你要在某项技术上投入，就必须有一定的可靠性保障。"

挑战四：Async 的未来尚未清晰

异步编程对中间件、事件驱动架构非常有吸引力，但在安全关键场景中，async 意味着需要引入一个异步运行时——而运行时本身必须通过安全认证，其调度行为必须可预测、可验证。

一位开发 AUTOSAR Adaptive 平台中间件的团队负责人表示："如果我们要使用 async Rust，当然需要一个能为 ISO 26262 提供所有质量与流程产物的运行时。"

目前，Eclipse S-CORE 等项目正在尝试构建面向安全关键汽车软件的 Rust 异步运行时，但整个生态的认证路径仍在摸索中。

六大改进建议

Rust 官方博客在大量用户访谈基础上，提出了以下六条路线图建议：

1. 帮助安全关键社区自我赋能

参考 Ferrocene 语言规范（FLS）的成功模式——由产业界联合投入，成果归入 Rust 项目维护。类似地，MC/DC 覆盖率支持工作现已通过安全关键 Rust 联盟（Safety-Critical Rust Consortium）重启，以共同所有权模式推进。

2. 建立生态级 MSRV（最低支持 Rust 版本）公约

引入 LTS 发布版本，并鼓励库作者维护与 LTS 版本的兼容性，从源头解决依赖漂移问题。

3. 将"目标平台层级策略"转化为安全关键入门指南

整合现有文档，为每个目标平台提供一份清单：是否支持 no_std？最后验证的 OS 版本是什么？主要阻塞问题有哪些？

4. 整理"依赖生命周期"最佳实践手册

将各团队已在实践的经验（早期用 crate 加速、后期内化关键路径）整理成可复用的 Playbook。

5. 明确"安全案例友好型"异步运行时的需求规格

联合 async 工作组和 libs 团队，定义什么样的运行时才算满足 ISO 26262 等标准的要求。

6. 将 C/C++ 互操作纳入安全性故事

许多团队不会全量重写，而是将 Rust 集成进现有 C/C++ 系统。改善 FFI 边界的审计性和工具支持，是必须正视的工程挑战。

总结

Rust 在安全关键系统领域的故事，已经从"能不能用"进化到"怎么用得更好"。路径是存在的，基础设施正在搭建中，生态正在成熟。

如果你正在安全关键领域使用 Rust，或者想为这一方向贡献力量，欢迎关注 Safety-Critical Rust Consortium^[1] 和 安全关键 Rust 编码指南^[2]。

原文来源：Rust 官方博客 · 2026年1月14日^[3]