内存安全路线图的理由
NSA 及国际合作伙伴发布的安全建议呼吁转向“内存安全”语言，这重新引发了关于如何减少源自 C 和 C++ 的软件漏洞的争论。评论者权衡了逐步采用 Rust 和其他更安全语言的可行性，以及庞大的遗留代码库、性能关键领域和与 C/C++ 深度绑定的图形或内核等生态系统之间的矛盾。许多人认为，语言选择、强有力的工具，以及架构上的变化（例如微内核、沙箱隔离）必须与开发者培训相结合，因为即使是高水平程序员，在规模化场景下也很难避免内存安全漏洞。
系统/操作系统代码中采用内存安全语言
- 讨论的重点是如何将内存安全引入内核和底层系统。
- Linux 内核中的 Rust 被认为很有前景，但目前体量仍然很小，也还处于早期阶段，主要用于驱动。
- 倾向的策略是逐步将“边缘”组件转换为 Rust，而不是重写。
- 也有人认为，更早通过微内核或重度分段（虚拟机、Qubes 风格隔离）就能解决其中很多问题。
语言选择与 NSA 的“安全名单”
- NSA 附录将 C#、Go、Java、Python、Rust、Swift 列为“内存安全”语言，这引发了争论。
- 许多人指出，现实世界中的生态系统常常会调用 C/C++ 库，从而削弱实际安全性。
- 有人好奇为什么列了 Python 却没有 Ruby、JS 或 Perl；有人给出的解释是：流行度和 AI/ML 动能。
Rust 与 C/C++（以及 Go/Swift）
- 支持者强调 Rust 是“默认安全，只在很小且明确的区域使用 unsafe”，从而缩小了审计面。
- 批评者说，在底层工作里他们经常碰到
unsafe和MaybeUninit，感觉像是在给 C 加了更多仪式感。 - C++ 支持者认为，RAII、智能指针、自定义整数类型、sanitizer 以及有纪律的子集可以“足够安全”，但其他人回应说，历史表明人类仍然会引入关键漏洞。
- Go 和 Swift 被认为在语言层面是内存安全的，但有一些注意事项：Go 存在基于数据竞争的利用方式；Swift 和 Rust 则增加了更强的并发保证。
其他语言：Ada、Fortran、Java、JavaScript、Python
- Ada/SPARK 被认为在航空电子、铁路、国防等安全关键领域具有很强的内存安全性，但市场份额很小。
- Fortran 基本局限于科学计算；不被视为主要攻击面。
- Java 既被称为漏洞的“pest fest”，也被另一些人认为大体没问题，只是有一些著名事件（例如 log4j）。
- JavaScript 引擎由于 JIT 复杂性，很难做到完全安全；有人提到在 JVM 上的更安全实现。
- Python 本身是内存安全的，但对 C/C++ 扩展的依赖又重新引入了风险。
并发、未定义行为与安全性的边界
- 一些人认为，在内存安全之后，下一个目标应该是未定义行为以及整数溢出/下溢。
- Rust 对溢出的定义行为受到称赞：调试模式下 panic，发布模式下回绕，并且还有显式的检查 API。
- 也有人指出，没有任何语言能完全“解决”并发；Rust 和 Swift 走得最远，但逻辑竞争仍然存在。
遗留代码、培训与工具
- 庞大的 C/C++ 遗留代码被视为核心问题。许多新系统仍然是用这些语言启动的。
- 有人提议采用更严格的子集（类似 MISRA）和静态分析（Astree、Frama-C 等）来证明安全性，但也指出了成本和难度。
- 讨论串对仅靠培训能否避免内存漏洞持怀疑态度；即便是在受监管领域、训练有素的开发者也仍会交付这类漏洞。
- 有人建议，未来 AI 可作为辅助工具来审计 C/C++ 的内存问题，而不是编写新代码。
威胁模型、空气隔离与 NSA 动机
- 参与者强调，空气隔离或“离线”的 C 代码并非免疫（提到了 Stuxnet）；如果空气隔离看起来有必要，那么内存安全语言大概也同样必要。
- 有些人讽刺地认为，NSA 想让行业转向他们可能能够攻击的共享运行时；而另一些人则反驳说，NSA 也有强烈动机去加固美国基础设施。