留给 C/C++ 语言的时间不多了。
出品丨自主可控新鲜事
本文内容来源于CSDN等
正文共3839，建议阅读时间10分钟
“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 将不良实践划分为三类：
产品特性：描述软件产品可观察的、与安全相关的质量。 安全特性：描述产品支持的安全功能。 组织流程和政策：描述软件制造商为确保其安全方法的高度透明度而采取的行动。
其他建议
在 SQL 查询字符串中发现包含用户提供的输入。其建议产品应以系统性防止 SQL 注入漏洞引入的方式构建，例如通过始终强制使用参数化查询； 在操作系统命令字符串中有包含用户提供的输入。其建议软件制造商应以系统性防止命令注入漏洞的方式构建产品，例如通过始终确保命令输入与命令本身的内容有明确的区分。 关键基础设施或 NCF 使用的产品发布时带有默认密码。对此，其建议软件制造商应确保产品中不存在默认密码，例如为产品提供随机的、实例唯一的初始密码，要求安装产品的用户在安装开始时创建一个强密码等等。 存在已知被利用的漏洞。对此，软件制造商应在发布前修补软件组件中所有已知被利用的漏洞。对于 CISA 目录中新发布的 KEV，制造商应及时免费向用户提供补丁（任何情况下不超过30天），并明确警告用户不安装补丁的相关风险。 存在已知可利用漏洞的开源软件。对此，软件制造商应对他们依赖的开源软件负责任地使用并可持续地贡献。
不放弃 C/C++，又会带来什么样的影响？
定义阶段，包括日期和结果。与所有软件开发工作一样，开发团队可以将较大的工作分解为具有明确结果的较小项目，以度量最新进展。具体包括 MSL 评估、测试在 MSL 中编写新组建的试点项目、找到最危险的内存不安全代码、重构内存不安全代码。 确定新系统完全使用 MSL 的时间。此后，公司将会仅在 MSL 中编写新代码。 内部开发者和培训和整合计划。没有 MSL 过渡是免费的，制造商需要留出时间让开发人员精通用所选语言编写软件、调试、工具、将 MSL 集成到生产环境中、全面的质量控制流程。 外部依赖计划。路线图应该记录处理对用 C 和 C++ 编写的库的依赖关系的计划。 透明度计划。通过定期 (例如，每季度或每半年)更新来保持上述信息的最新性，将进一步建立组织正在认真对待内存安全漏洞的信心。 CVE 支持计划。行业需要详细和正确地公开数据，以了解给客户带来风险的漏洞类别。
目前它们只是建议，这是“如果可以，请遵守我的规则”，仅仅是对即将发生的事情的一个警告，但它不会在 2026 年成为法律，我 100% 确定这一点。
作为一名用 C++ 为政府编写软件的人，读到这些也真的很有趣。我们的项目直到 2020 年之后才被允许使用 C++11 功能，而且显然很快就会被允许使用 C++14。而且必须是 C++，因为我们需要支持平台和供应商。即使对于我们所有的新项目也是如此！
现在和可预见的未来，放弃 C 或 C++ 是完全不可能的。此外，我喜欢 Rust，它正在被采用，但让它成为新的黄金标准，未免操之过急。它仍然是一种新语言，在我们考虑真正用 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
免责声明：本文系网络转载，版权归原作者所有。但因转载众多，或无法确认真正原始作者，故仅标明转载来源，如涉及作品版权问题，请与我们联系，我们将在第一时间协商版权问题或删除内容！内容为作者个人观点，并不代表本公众号赞同其观点和对其真实性负责。
