↓推荐关注↓
转自：CSDN（ID：CSDNnews），整理 | 苏宓
“C/C++”被视为内存不安全的编程语言由来已久，很多开发者似乎也见怪不怪了，然而近日外媒 TheNewStack 最新发表了一篇《联邦政府：关键软件必须在 2026 年之前放弃 C/C++，否则将面临风险》文章，让人警铃大作。
因为过往包括美国网络安全和基础设施安全局（CISA）、联邦调查局（FBI）、国防高级研究计划局（DARPA）等多个机构虽然发起多个指南、甚至想尽办法开发 AI 工具旨在一键将旧的 C 代码转为 Rust，但终归没有采取过于强硬的手段或者是给“去 C、C++ 加上一个时间限制”。如今外媒报道中赫然出现了一个「2026 年」的期限到底是怎么一回事？倘若在软件中继续使用 C/C++ 语言最终又会带来哪些影响？
CISA 和 FBI 最新发布《产品安全不良实践》指南
进一步来看，这篇报道的来源依据的是美国 CISA、FBI 最近联合发布的一份关于《产品安全不良实践》的报告。
在报告中，CISA 表示，软件制造商应确保从软件开发之初就将安全性作为核心考虑因素。基于此，CISA 和 FBI 希望能够敦促软件制造商通过在整个产品开发过程中优先考虑安全性来降低客户风险。
不过，值得注意的是，虽然 CISA、FBI 想要尽可能地让开发用于支持关键基础设施或 NCF 的软件产品和服务（包括本地软件、云服务和软件即服务 (SaaS)）的软件制造商去避免产品安全不良做法，但是其在发布这份报告时说得也很明确——并未强硬地要求软件开发商们必须按照这份报告的建议去做。
目前这份报告指南还正处于征求公众意见期间，收集各方的反馈意见，以指导这些产品安全不良做法的制定。倘若开发者、企业对这份报告提出的做法有意见，可以在 2024 年 12 月 16 日提交反馈意见。
来源：https://www.federalregister.gov/documents/2024/10/29/2024-25078/request-for-comment-on-product-security-bad-practices-guidance
话虽如此，CISA、FBI 在这份主题为《产品安全不良实践》的报告中概述了被认为极其危险的产品安全不良做法，特别是对于生产用于关键基础设施或国家关键功能 (NCF) 的软件的软件制造商而言，并为软件制造商提供了减轻这些风险的建议，同时还是忍不住地多次强调了「2026 年」这个时间节点。
建议在 2026 年前软件开发商发布内存安全路线图
CISA、FBI 将不良实践划分为三类：
产品特性：描述软件产品可观察的、与安全相关的质量。
安全特性：描述产品支持的安全功能。
组织流程和政策：描述软件制造商为确保其安全方法的高度透明度而采取的行动。
在产品特性维度上，美国两大组织首先将“内存不安全语言的开发”列为首要不良实践的做法。
其指出，“在有现成的内存安全语言可供使用的情况下，使用内存不安全的语言（如 C 或 C++）开发用于关键基础设施或（国家关键功能）NCF 的新产品线是危险的，并且会大大增加对国家安全、国家经济安全以及国家公共健康和安全的风险。”
此处，这份指南特别强调了——对于使用内存不安全语言编写的现有产品，如果在 2026 年 1 月 1 日之前未发布内存安全路线图，则非常危险，会大大增加国家安全、国家经济安全和国家公共卫生与安全的风险。内存安全路线图应概述制造商消除优先代码组件（例如面向网络的代码或处理加密操作等敏感功能的代码）中的内存安全漏洞的优先方法。制造商应证明内存安全路线图将显著、优先减少制造商产品中的内存安全漏洞，并证明他们正在做出合理的努力来遵循内存安全路线图。这不适用于宣布支持终止日期在 2030 年 1 月 1 日之前的产品。
至于为什么是「2026 年之前」，CISA、FBI 并未做特别的解释，仅是在「建议采取的措施」中又一次表示，当前的软件制造商应以系统性的方式构建产品，以防止引入内存安全漏洞，例如使用内存安全语言或防止内存安全漏洞的硬件功能。此外，软件制造商应在 2026 年 1 月 1 日之前发布内存安全路线图。
其他建议
除此之外，CISA、FBI 还列举了几种常见的产品不安全的实践，譬如：
在 SQL 查询字符串中发现包含用户提供的输入。其建议产品应以系统性防止 SQL 注入漏洞引入的方式构建，例如通过始终强制使用参数化查询；
在操作系统命令字符串中有包含用户提供的输入。其建议软件制造商应以系统性防止命令注入漏洞的方式构建产品，例如通过始终确保命令输入与命令本身的内容有明确的区分。
关键基础设施或 NCF 使用的产品发布时带有默认密码。对此，其建议软件制造商应确保产品中不存在默认密码，例如为产品提供随机的、实例唯一的初始密码，要求安装产品的用户在安装开始时创建一个强密码等等。
存在已知被利用的漏洞。对此，软件制造商应在发布前修补软件组件中所有已知被利用的漏洞。对于 CISA 目录中新发布的 KEV，制造商应及时免费向用户提供补丁（任何情况下不超过30天），并明确警告用户不安装补丁的相关风险。
存在已知可利用漏洞的开源软件。对此，软件制造商应对他们依赖的开源软件负责任地使用并可持续地贡献。
在安全功能方面，CISA 和 FBI 还发现很多软件开发商在开发中缺乏多因素身份验证、缺乏收入入侵证据的能力，其指出，2026 年 1 月 1 日之后未默认为管理员帐户启用 MFA 的产品非常危险，软件制造商应在产品中原生支持 MFA（如果产品本身处理身份验证），或在产品的基线版本中支持使用外部身份提供者，例如通过单点登录、要求管理员使用 MFA。对于云服务提供商和 SaaS 产品，软件制造商应免费保留一定时间范围内的日志（至少 6 个月）。
在组织流程和政策方面，软件制造商应及时发布所有严重或高影响漏洞的完整 CVE，以及公开发布漏洞披露政策 (VDP) 等。
不放弃 C/C++，又会带来什么样的影响？
「以 2026 年为时间节点」来敦促软件开发商们想尽办法去改进，以此提升产品安全性，本意或许是好的，但是在仅有 14 个月的时间里，为产品规划内存安全路线图也不是一件小事。
此前，CISA 自己也发布过一份 23 页的《内存安全路线图指南》，其指出，在 MSL 中重写现有代码可能是一个巨大的挑战，特别是如果代码已经运行良好，而组织还不具备所选 MSL 的专业知识。
当时，该组织只是给出较为笼统的路线图制定建议：
定义阶段，包括日期和结果。与所有软件开发工作一样，开发团队可以将较大的工作分解为具有明确结果的较小项目，以度量最新进展。具体包括 MSL 评估、测试在 MSL 中编写新组建的试点项目、找到最危险的内存不安全代码、重构内存不安全代码。
确定新系统完全使用 MSL 的时间。此后，公司将会仅在 MSL 中编写新代码。
内部开发者和培训和整合计划。没有 MSL 过渡是免费的，制造商需要留出时间让开发人员精通用所选语言编写软件、调试、工具、将 MSL 集成到生产环境中、全面的质量控制流程。
外部依赖计划。路线图应该记录处理对用 C 和 C++ 编写的库的依赖关系的计划。
透明度计划。通过定期 (例如，每季度或每半年)更新来保持上述信息的最新性，将进一步建立组织正在认真对待内存安全漏洞的信心。
CVE 支持计划。行业需要详细和正确地公开数据，以了解给客户带来风险的漏洞类别。
但是综合成本与风险，很多企业无意迁移到内存更安全的编程语言上。
那么不迁移到 MSL 语言又会带来什么样的影响？
对此，业界的开发者们也展开了激烈的讨论，多数人认为「这些建议终究只是一个建议罢了，无伤大雅」：
目前它们只是建议，这是“如果可以，请遵守我的规则”，仅仅是对即将发生的事情的一个警告，但它不会在 2026 年成为法律，我 100% 确定这一点。
作为一名用 C++ 为政府编写软件的人，读到这些也真的很有趣。我们的项目直到 2020 年之后才被允许使用 C++11 功能，而且显然很快就会被允许使用 C++14。而且必须是 C++，因为我们需要支持平台和供应商。即使对于我们所有的新项目也是如此！
现在和可预见的未来，放弃 C 或 C++ 是完全不可能的。此外，我喜欢 Rust，它正在被采用，但让它成为新的黄金标准，未免操之过急。它仍然是一种新语言，在我们考虑真正用 Rust 重写所有内容之前，它还有一些非常大的问题需要解决。
不过也有人一些开发者声称自己以及公司已经受到了一些影响：
当有网友究竟问及是哪一类的软件时，该开发者回应道，「它是一类必须实现 Linux 中存在的几乎所有安全层的软件。」
而就国外现在呼吁放弃 C/C++ 这种内存不安全语言的做法，国内知名 C++ 专家吴咏炜此前在接受 CSDN 采访时表示：
这一事件的起源重点是关注网络安全，内存安全的编程语言是其中的一小部分内容。
确实建议大家避免使用内存不安全的语言。但问题是，如果不是对效率有极致追求的场景，大家本来就不会选用 C 和 C++（如在企业应用里，本来 Java 就是主流）。而用到 C 和 C++ 的，基本都是确有需要。此前报告里也提过，空间系统里仍然使用 C 和 C++，并描述了如何使用其他技术手段来规避不安全语言可能带来的问题。
吴咏炜认为，对于 C 和 C++ 的安全性，也有必要做几点陈述：
C 和 C++ 不是一回事。在现代 C++ 代码里，因为有很多好的语言构件（如容器和智能指针）可以用，犯内存错误的可能性要比 C 低得多。C 的固定大小数组是很多安全问题的根源。
已经存在很多工具，可以帮助检查代码的安全性，如 clang-tidy、cppsafe 和 address sanitizer（ASan）。
C++ 本身也在发展，像 lifetime profile（生存期规格配置）等方面的工作就是为了能提前检查出安全问题。
内存安全是代码安全的一部分，不是全部。
代码安全问题是个系统工程，不是靠某种银弹就能立即解决的。培训、语言、工具等等都是解决方案的一部分。
那么，针对内存安全编程语言的争论，你有什么样的看法？在 Linux、Google、微软等组织纷纷开始拥抱 Rust 的情况下，你开发的项目是否有受到这波趋势的影响？欢迎留言分享你的看法。
参考：
https://www.cisa.gov/resources-tools/resources/product-security-bad-practices
https://thenewstack.io/feds-critical-software-must-drop-c-c-by-2026-or-face-risk/
https://www.reddit.com/r/rust/comments/1ggt7m2/feds_critical_software_must_drop_cc_by_2026_or/
https://news.ycombinator.com/item?id=42013379
- EOF -
觉得本文有帮助？请分享给更多人
推荐关注「算法爱好者」，修炼编程内功
点赞和在看就是最大的支持❤️
