我肯定是个自讨苦吃的人。我的第一门编程语言不仅是 IBM 360 Assembler，我的第二门语言也是 C。用它们编写任何程序都不容易。用其中任何一种语言安全地编程都困难得多。

  因此，当美国网络安全和基础设施安全局（CISA）和联邦调查局（FBI）宣布他们正在加倍努力说服软件制造商放弃 C 和 C++ 等“内存不安全”的编程语言时，这并不令人意外。

  美国当局在《产品安全不良做法》报告中警告软件制造商，“在有现成的内存安全替代语言可供使用的情况下，使用内存不安全的语言（例如 C 或 C++）开发用于关键基础设施或（国家关键功能）NCF 的新产品线是危险的，会大幅度提升国家安全、国家经济安全以及国家公共健康和安全的风险。”

  如果这听起来很熟悉，那是因为 CISA 多年来一直在宣扬这一点。早在 2024 年，CISA 就与 FBI、澳大利亚信号局的澳大利亚网络安全中心和加拿大网络安全中心（又名五眼联盟）等合作机构发布了一份报告《探索关键开源项目的内存安全》，该报告分析了 172 个关键开源项目。研究结果为，这些项目中超过一半包含用内存不安全的语言编写的代码，占所检查项目总代码行数的 55%。

  具体来说，“内存不安全的语言要求研发人员正确管理内存的使用和分配。错误不可避免地会发生，这有几率会使内存安全漏洞，例如缓冲区溢出和释放后使用。成功利用这些类型的漏洞可以让对手控制软件、系统和数据。

  CISA 继续指出，内存安全漏洞占安全漏洞的 70%。未解决这一问题，CISA 建议研发人员过渡到内存安全的编程语言，例如 Rust、Java、C#、Go、Python 和 Swift。这些语言内置了针对常见内存相关错误的保护的方法，从代码开始就更加安全。

  如果真的能如此轻松地弹指一挥就将代码库从 C 神奇地转换为 Rust，那就太好了。剧透警告：事实并非如此。

  问题是，正如 Torvalds 在 2024 年欧洲开源峰会上所说，“整个Rust 与 C 的讨论几乎带有宗教色彩”，其激烈的论据导致一位Linux 中的 Rust 维护者厌恶地举手离开。你看，那些花了数年甚至数十年掌握 C 的人不想掌握截然不同的 Rust。他们看不到重点。毕竟，他们能够用 C 编写内存安全的代码，那么你为什么不能呢？

  这不仅仅是年老、脾气暴躁的研发人员的问题。将现有的大型代码库转换为内存安全语言可能是一项艰巨的任务。它耗费时间、资源密集，需要仔细规划才能保持功能，坦率地说，这是一件非常痛苦的事情。

  另一个问题是，与 C 和 C++ 相比，内存安全语言可能会导致性能直线下降。我们仍在使用这一些已有几十年历史且难度较大的语言是有原因的；有了它们，研发人员可以编写出最快的程序。如果要在速度和安全性之间做出选择，程序员和雇用他们的公司每次大部分会选择最快的代码。

  除了纯粹的迁移成本外，公司还面临着更换现有开发工具、调试器和测试框架以支持新语言的费用。当然，他们还要将新程序与旧代码和库集成在一起。

  CISA 坚持要求这样做。或者，至少，公司一定要在 2026 年 1 月 1 日之前制定迁移现有代码库的路线图。CISA 认为，减少漏洞和提高安全性方面的长期利益大于初始投资。

  我了解企业。他们不会接受这种观点。在现代企业界，一切都是为了在下一季度实现利润最大化。今天花钱是为了在 2027 年省钱？这是不可能的。

  最终，我们会痛苦而缓慢地转向内存安全语言。这确实是个好主意。不过，就我个人而言，我并不认为这会在十年内发生。2030 年代？是的，2020 年代？不。

  无论是企业还是程序员，都只有少数的理由做出这一转变。抱歉，CISA，事情就是这样。

  *免责声明：本文由作者原创。文章的主要内容系作者本人观点，半导体行业观察转载仅为了传达一种不同的观点，不代表半导体行业观察对该观点赞同或支持，如果有任何异议，欢迎联系半导体行业观察。

  以上内容与证券之星立场无关。证券之星发布此内容的目的是传播更多详细的信息，证券之星对其观点、判断保持中立，不保证该内容（包括但不限于文字、数据及图表）全部或者部分内容的准确性、真实性、完整性、有效性、及时性、原创性等。相关联的内容不对各位读者构成任何投资建议，据此操作，风险自担。股市有风险，投资需谨慎。如对该内容存在异议，或发现违法及不良信息，请发送邮件至，我们将安排核实处理。