AMIRREZA
2024-11-04T12:35:53+00:00
此次意见可谓美国政府在软件安全方面表达的最强硬立场，消息一出很快引起软件开发商关注：若不对编码实践做出修复，则意味着需要承担过失风险。
美联邦政府正在加强关于危险软件开发实践的警告，日前美国网络安全与基础设施安全局(CISA)和联邦调查局(FBI)陆续发布关于困扰关键基础设施的基本安全问题的明确处置信号。
CISA 和 FBI 在关于产品安全性不良实践的最新报告中，提醒软件开发商应高度关注使用非内存安全编程语言等不良行为，而 C 和 C++ 更是在其中被列为反面典型。
报告指出，“在支持关键基础设施或国家关键职能(NCF)的新产品线的开发过程中，使用非内存安全语言(例如 C 或 C++)可能引发风险，即显著提高了国家安全、国家经济安全以及国家公共卫生及安全所面临的风险。”
规避不良实践，遵循建议方针
这份报告还将不良实践具体分为三大类别：
产品属性，即描述软件产品中肉眼可见与安全相关的质量属性。
安全功能，描述产品所支持的安全功能。
组织流程和政策，描述软件开发商在确保安全方法的透明度等方面采取的实际行动。
这份报告主要面向负责为关键基础设施或者国家关键职能等应用场景开发软件产品及服务的各软件开发商(包括本地软件、云服务以及 SaaS 软件即服务)。
此外，这份报告还鼓励全体软件开发商避免采取这些可能影响产品安全性的不良实践。报告提到，“通过遵循本指南中的建议，开发商将向客户发出信号，表明他们高度关注向客户交付成果的安全因素、牢牢秉持在设计之初就重视安全的基本原则。”
Omdia 分析师 Brad Shimmin 表示，“这项指南是对美国政府此前关于软件安全问题的早期声明的延续，当时的声明可以追溯到 2022 年，意在提醒技术提供商和企业用户尽量使用或迁移至内存安全语言。”
他解释称，“抛开新增代码不谈，当时的文件和美国政府表达的立场相对比较和缓，没有立即要求从 C/C++ 迁移至 Rust。CISA 的设计文档中也提到，软件维护者根本不可能在短时间内完成如此规模的代码库迁移。”
当时的指南虽然属于自愿性质，但也代表着 CISA 在基准安全实践方面的最强立场，包括提醒企业注意到可能被疏忽的不良软件开发实践，特别是其中触及基础设施的部分。
时间正点滴流逝
但时间的洪流一刻不停向前奔涌，最新报告已经要求企业必须在 2026 年 1 月 1 日之前建立内存安全发展路线图。
报告指出，“对于以非内存安全语言编写的现有产品， 到 2026 年 1 月 1 日前仍缺少明确内存安全迁移路线图的情况， 将被视为存在风险，即显著提高了国家安全、国家经济安全以及国家公共卫生及安全所面临的风险。”
CISA 战略合作伙伴关系及漏洞项目开发负责人 Rina Rakipi 表示，CISA 已获得超过 230 家软件厂商的自愿承诺。加入“安全设计”计划， 意味着这些厂商承诺在一年内达成一系列网络安全目标，包括减少产品中的默认密码、增加多因素身份验证的使用，以及消除特定类别的漏洞。
Rakipi 说：“我们非常高兴有超过 230 家软件厂商自愿参与这一承诺。展望未来，我们期待 在接下来的一年中，看到这 230 家公司取得的实质性进展。”
此外，报告还要求企业在同一日期之前移除管理员账户中使用的全部默认密码。这一截止日期已经将指南内容从建议升级为预期标准。
报告同时指出，内存安全路线图应要搞开发商在主要代码组件(例如面向网络的代码或者处理加密操作等敏感功能的代码)当中将要采取的首选内存安全漏洞消除方法。
报告指出，“开发商应当证明，其内存安全路线图将如何优先缓解其所开发产品中内存安全性的脆弱性，同时证明他们正做出合理努力以实施并推进其内存安全路线图。”
Shimmin 在采访中解释称，“但有两个现实理由会迫使企业继续维护由 COBOL 和 Fortran 编写的成规模代码——成本和风险。首先，对数百万行旧代码进行迁移在财务上不具备可行性，而且任何负责任的组织都无法承担由此带来的业务风险。”
此外，根据报告内容，关键基础设施还面临着以下“异常风险”的困扰：
默认密码。
直接 SQL 注入漏洞。
缺少基本注入检测机制。
缺少多因素身份验证机制。
开源难题
对于开源软件，该报告称应特别关注开源漏洞。其他建议还包括：
企业必须维护明确的软件物料清单(SBOM)。
应当缓存依赖项，而非直接从公共来源处提取。
需要以负责任方式为其依赖的开源项目做出贡献。
报告提到，“软件开发商应当以负责任的方式使用并持续为其所依赖的开源软件做出贡献。”
报告还敦促提高软件开发透明度，包括：
企业必须发布漏洞披露政策。
应当为所有关键漏洞发布 CVE。
必须提供关于安全问题的清晰说明文档。
预计将安全日志维护并保存六个月。
尽管手段严厉，但影响无疑非常积极
最后，Shimmin 总结称，CISA 建议掌握关键软件的企业在 2026 年初之前制定出明确的安全计划无疑是件好事。因为这能让软件行业有更多时间探索出理想的方法，确保我们的关键软件资产免遭威胁侵扰。
“这些方法能够包括在硬件制造层面消除潜在的攻击面，以及由编程语言维护者提出方案。 以 Safe C++ 提案为例 ，其呼吁为 C++ 创建一个超集以解决内存安全问题，借此避免强制进行大规模代码重写。”
C++ 之父驳斥弃用论：安全升级需渐进改进，而非全盘更换
这并不是 CISA 对内存安全语言的首次提倡。
在去年 9 月的一篇博文中，CISA 也曾公开敦促开发人员使用内存安全编程语言。网络与基础设施安全局、联邦调查局(FBI)、国家安全局及各盟国机构随后于 12 月发布了题为《内存安全路线图案例》(The Case for Memory Safe Roadmaps)的研究报告，其中就点名 C/C++ 存在内存安全漏洞，软件开发商应放弃使用，改用 C#、Rust、Go、Java、Python 和 Swift 等内存安全的编程语言 (MSL)。
今年 2 月底，白宫国家网络主任办公室 (ONCD) 也就此发布了一份报告，呼吁科技界主动减少网络空间的攻击面；通过改用 Rust 等内存安全编程语言、避免使用 C++ 和 C 语言等易受攻击的语言，以减少内存安全漏洞的数量来提高软件安全性。
随后，C++ 的创建者 Bjarne Stroustrup 针对白宫的这些言论进行了反驳。
Stroustrup 指出了 C++ 的优势，并提到该语言最早于 1979 年设计。“令我感到惊讶的是，这些政府文件的作者似乎忽略了现代 C++ 的优势以及在提供强大安全保障方面所做的努力，” Stroustrup 表示，“但另一方面，他们似乎认识到编程语言只是工具链的一部分，因此改进工具和开发流程也至关重要。”
Stroustrup 强调，C++ 开发始终将安全性改进作为目标之一。“自第一天起，安全性改进就是 C++ 发展的目标之一，并贯穿了整个演进过程。只要将 K&R 时代的 C 语言与最早的 C++ 比较，再将早期的 C++ 与当代 C++ 比较就可以看出这一点，”他说。“许多高质量的 C++ 代码采用了基于 RAII(资源获取即初始化)、容器和资源管理指针的技术，而不是传统的 C-style pointer messes。”
其实在更早之前，Stroustrup 就明确表达过自己的看法，他曾在 CppCon2023 大会上主题演讲上阐述了 C++ 的演变，还花了一些时间回应了批评。批评者说问题出在 C++ 本身，解决方案应该是改用另一种语言。Stroustrup 在演讲中向与会者详细说明了 C++ 语言在安全性方面所需的具体措施，并介绍了一项引入全新安全工具的提案，旨在为全球数十亿行 C++ 代码提供更可靠的安全保障。
Stroustrup 反对通过更换语言来解决安全问题。他指出安全问题不仅仅是内存安全，还包括资源泄漏、溢出、并发和计时错误等多种复杂的隐患。
他强调，完全转向其他语言不仅成本高昂，还缺乏关注跨语言互操作的需求——“实际上，我们在替换 C++ 时，可能需要用七种不同的语言来完成。而到 40 年后，可能会有 20 种语言需要彼此兼容。这是巨大的挑战。”
此外，Stroustrup 指出，许多所谓“安全”语言实际上将底层任务外包给 C 或 C++，以便访问操作系统、硬件资源或其他历史代码库，这些代码往往隐藏在库中，甚至使用完全不同的语言开发。
与 CISA 的“安全设计”计划类似，Stroustrup 主张采用逐步改进的方案来提升 C++ 的安全性，而非推倒重来。他援引加尔定律，指出“有效的复杂系统总是从简单系统演变而来”。
在他看来，“一边倒地构建一个无旧系统问题的新系统是幻想，但这种幻想确实颇具吸引力。”
美联邦政府正在加强关于危险软件开发实践的警告，日前美国网络安全与基础设施安全局(CISA)和联邦调查局(FBI)陆续发布关于困扰关键基础设施的基本安全问题的明确处置信号。
CISA 和 FBI 在关于产品安全性不良实践的最新报告中，提醒软件开发商应高度关注使用非内存安全编程语言等不良行为，而 C 和 C++ 更是在其中被列为反面典型。
报告指出，“在支持关键基础设施或国家关键职能(NCF)的新产品线的开发过程中，使用非内存安全语言(例如 C 或 C++)可能引发风险，即显著提高了国家安全、国家经济安全以及国家公共卫生及安全所面临的风险。”
规避不良实践，遵循建议方针
这份报告还将不良实践具体分为三大类别：
产品属性，即描述软件产品中肉眼可见与安全相关的质量属性。
安全功能，描述产品所支持的安全功能。
组织流程和政策，描述软件开发商在确保安全方法的透明度等方面采取的实际行动。
这份报告主要面向负责为关键基础设施或者国家关键职能等应用场景开发软件产品及服务的各软件开发商(包括本地软件、云服务以及 SaaS 软件即服务)。
此外，这份报告还鼓励全体软件开发商避免采取这些可能影响产品安全性的不良实践。报告提到，“通过遵循本指南中的建议，开发商将向客户发出信号，表明他们高度关注向客户交付成果的安全因素、牢牢秉持在设计之初就重视安全的基本原则。”
Omdia 分析师 Brad Shimmin 表示，“这项指南是对美国政府此前关于软件安全问题的早期声明的延续，当时的声明可以追溯到 2022 年，意在提醒技术提供商和企业用户尽量使用或迁移至内存安全语言。”
他解释称，“抛开新增代码不谈，当时的文件和美国政府表达的立场相对比较和缓，没有立即要求从 C/C++ 迁移至 Rust。CISA 的设计文档中也提到，软件维护者根本不可能在短时间内完成如此规模的代码库迁移。”
当时的指南虽然属于自愿性质，但也代表着 CISA 在基准安全实践方面的最强立场，包括提醒企业注意到可能被疏忽的不良软件开发实践，特别是其中触及基础设施的部分。
时间正点滴流逝
但时间的洪流一刻不停向前奔涌，最新报告已经要求企业必须在 2026 年 1 月 1 日之前建立内存安全发展路线图。
报告指出，“对于以非内存安全语言编写的现有产品， 到 2026 年 1 月 1 日前仍缺少明确内存安全迁移路线图的情况， 将被视为存在风险，即显著提高了国家安全、国家经济安全以及国家公共卫生及安全所面临的风险。”
CISA 战略合作伙伴关系及漏洞项目开发负责人 Rina Rakipi 表示，CISA 已获得超过 230 家软件厂商的自愿承诺。加入“安全设计”计划， 意味着这些厂商承诺在一年内达成一系列网络安全目标，包括减少产品中的默认密码、增加多因素身份验证的使用，以及消除特定类别的漏洞。
Rakipi 说：“我们非常高兴有超过 230 家软件厂商自愿参与这一承诺。展望未来，我们期待 在接下来的一年中，看到这 230 家公司取得的实质性进展。”
此外，报告还要求企业在同一日期之前移除管理员账户中使用的全部默认密码。这一截止日期已经将指南内容从建议升级为预期标准。
报告同时指出，内存安全路线图应要搞开发商在主要代码组件(例如面向网络的代码或者处理加密操作等敏感功能的代码)当中将要采取的首选内存安全漏洞消除方法。
报告指出，“开发商应当证明，其内存安全路线图将如何优先缓解其所开发产品中内存安全性的脆弱性，同时证明他们正做出合理努力以实施并推进其内存安全路线图。”
Shimmin 在采访中解释称，“但有两个现实理由会迫使企业继续维护由 COBOL 和 Fortran 编写的成规模代码——成本和风险。首先，对数百万行旧代码进行迁移在财务上不具备可行性，而且任何负责任的组织都无法承担由此带来的业务风险。”
此外，根据报告内容，关键基础设施还面临着以下“异常风险”的困扰：
默认密码。
直接 SQL 注入漏洞。
缺少基本注入检测机制。
缺少多因素身份验证机制。
开源难题
对于开源软件，该报告称应特别关注开源漏洞。其他建议还包括：
企业必须维护明确的软件物料清单(SBOM)。
应当缓存依赖项，而非直接从公共来源处提取。
需要以负责任方式为其依赖的开源项目做出贡献。
报告提到，“软件开发商应当以负责任的方式使用并持续为其所依赖的开源软件做出贡献。”
报告还敦促提高软件开发透明度，包括：
企业必须发布漏洞披露政策。
应当为所有关键漏洞发布 CVE。
必须提供关于安全问题的清晰说明文档。
预计将安全日志维护并保存六个月。
尽管手段严厉，但影响无疑非常积极
最后，Shimmin 总结称，CISA 建议掌握关键软件的企业在 2026 年初之前制定出明确的安全计划无疑是件好事。因为这能让软件行业有更多时间探索出理想的方法，确保我们的关键软件资产免遭威胁侵扰。
“这些方法能够包括在硬件制造层面消除潜在的攻击面，以及由编程语言维护者提出方案。 以 Safe C++ 提案为例 ，其呼吁为 C++ 创建一个超集以解决内存安全问题，借此避免强制进行大规模代码重写。”
C++ 之父驳斥弃用论：安全升级需渐进改进，而非全盘更换
这并不是 CISA 对内存安全语言的首次提倡。
在去年 9 月的一篇博文中，CISA 也曾公开敦促开发人员使用内存安全编程语言。网络与基础设施安全局、联邦调查局(FBI)、国家安全局及各盟国机构随后于 12 月发布了题为《内存安全路线图案例》(The Case for Memory Safe Roadmaps)的研究报告，其中就点名 C/C++ 存在内存安全漏洞，软件开发商应放弃使用，改用 C#、Rust、Go、Java、Python 和 Swift 等内存安全的编程语言 (MSL)。
今年 2 月底，白宫国家网络主任办公室 (ONCD) 也就此发布了一份报告，呼吁科技界主动减少网络空间的攻击面；通过改用 Rust 等内存安全编程语言、避免使用 C++ 和 C 语言等易受攻击的语言，以减少内存安全漏洞的数量来提高软件安全性。
随后，C++ 的创建者 Bjarne Stroustrup 针对白宫的这些言论进行了反驳。
Stroustrup 指出了 C++ 的优势，并提到该语言最早于 1979 年设计。“令我感到惊讶的是，这些政府文件的作者似乎忽略了现代 C++ 的优势以及在提供强大安全保障方面所做的努力，” Stroustrup 表示，“但另一方面，他们似乎认识到编程语言只是工具链的一部分，因此改进工具和开发流程也至关重要。”
Stroustrup 强调，C++ 开发始终将安全性改进作为目标之一。“自第一天起，安全性改进就是 C++ 发展的目标之一，并贯穿了整个演进过程。只要将 K&R 时代的 C 语言与最早的 C++ 比较，再将早期的 C++ 与当代 C++ 比较就可以看出这一点，”他说。“许多高质量的 C++ 代码采用了基于 RAII(资源获取即初始化)、容器和资源管理指针的技术，而不是传统的 C-style pointer messes。”
其实在更早之前，Stroustrup 就明确表达过自己的看法，他曾在 CppCon2023 大会上主题演讲上阐述了 C++ 的演变，还花了一些时间回应了批评。批评者说问题出在 C++ 本身，解决方案应该是改用另一种语言。Stroustrup 在演讲中向与会者详细说明了 C++ 语言在安全性方面所需的具体措施，并介绍了一项引入全新安全工具的提案，旨在为全球数十亿行 C++ 代码提供更可靠的安全保障。
Stroustrup 反对通过更换语言来解决安全问题。他指出安全问题不仅仅是内存安全，还包括资源泄漏、溢出、并发和计时错误等多种复杂的隐患。
他强调，完全转向其他语言不仅成本高昂，还缺乏关注跨语言互操作的需求——“实际上，我们在替换 C++ 时，可能需要用七种不同的语言来完成。而到 40 年后，可能会有 20 种语言需要彼此兼容。这是巨大的挑战。”
此外，Stroustrup 指出，许多所谓“安全”语言实际上将底层任务外包给 C 或 C++，以便访问操作系统、硬件资源或其他历史代码库，这些代码往往隐藏在库中，甚至使用完全不同的语言开发。
与 CISA 的“安全设计”计划类似，Stroustrup 主张采用逐步改进的方案来提升 C++ 的安全性，而非推倒重来。他援引加尔定律，指出“有效的复杂系统总是从简单系统演变而来”。
在他看来，“一边倒地构建一个无旧系统问题的新系统是幻想，但这种幻想确实颇具吸引力。”
