【国际视野】美国家安全局等部门联合发布《面向开发人员的软件供应 链指南》 原创 “ 天极智库 天极智库 2022-09-07 18:40 发表于北京 天极按 近日，美国国家安全局 （NSA）、网络安全和基础设施安全局 （CISA） 以及国家情报总监办公室 （ODNI）联合发布面向开发人员 的软件供应链指南，为解决国家关键基础设施面临的高优先级威胁提 供网络安全指导。本指南分为三部分系列，将与软件供应链生命周期 同时发布。这是该系列的第 1 部分，重点介绍软件开发人员。本系列 的第 2 部分侧重于软件供应商，本系列的第 3 部分侧重于软件客户。 背景 从历史上看，软件供应链的危害主要针对未修复漏洞的组织。在过去的几年里，这些下一代 软件供应链的入侵对于开源和商业软件产品都显着增加。针对软件供应链的常见危害方法包 括利用软件设计缺陷、将易受攻击的第三方组件整合到软件产品中、在最终软件产品交付之 前用恶意代码渗透供应商网络以及注入恶意软件，然后由客户部署。   开发人员 安全软件开发生命周期（Secure SDLC）是用于保护软件供应链的重要流程。下图显示了单 个小组活动以及客户、开发商和供应商之间的关系的示例：   图 1：软件供应链组的关系和活动  当供应商的项目管理团队从客户的用户群、技术群和营销团队收集功能请求时，该流程立即 开始。供应商和开发人员管理团队共同定义用于产生架构和高级设计的需求，开发团队使用 需求来生产产品。此外，联合管理团队定义了产品开发安全策略和生产产品时使用的实践。 该过程定义了如何构建开发活动以及将收集哪些工件以进行验证和确认。以下是安全 SDLC 流程和实践示例的简短列表： • NIST“安全软件开发框架” • 卡内基梅隆大学“安全软件开发生命周期过程” • ACM“计算机系统中的信息保护” • OWASP“安全开发生命周期” • “思科安全开发生命周期” • Synopsys“安全软件开发生命周期阶段” • US-Cert“安全软件开发生命周期流程” • OpenSSF“安全软件开发基础课程”。   除了生成的高级开发文档外，管理团队还定义了用于安全软件开发的安全实践和程序，例 如： • 安全编码实践， • 代码审查流程， • 软件存储库程序、测试和漏洞评估， • 安全构建和分发产品的程序。 产品发布后，将通过产品客户可用的支持渠道监控产品的缺陷，开发人员可以安全地提供更 新和升级以解决报告的问题。 对于安全 SDLC 中的每个操作，都会创建工件，以证明对所需和概述的流程的遵守。 1 安全产品标准和管理 开发人员用例依赖于安全 SDLC 流程中定义的程序和策略。开发团队经理和成员调整和定制 这个过程以满足其特定需求。Secure SDLC 确定了用于确保实施安全开发实践并创建工件以 证明所采用的 Secure SDLC 计划在产品实施和分发方面的遵守的确切程序和策略。 开发团队由开发、质量保证 (QA)、构建工程和安全方面的专家组成。产品管理团队由具有产 品领导经验的个人组成，包括产品和开发经理、安全架构师和公司级质量控制评估员，所有 这些都有助于产品发布监督。 最高级别的组织管理团队必须确保安全的开发政策和程序在预算和时间表内得到支持，并由 指定的开发团队实施和遵守。下图概述了安全的开发过程和生命周期。 图 2：安全软件开发流程 >>>> 威胁场景 在开发和交付产品时，在软件开发生命周期中可能会出现以下常见威胁： 1. 对手故意注入恶意代码或开发人员无意中在产品中包含易受攻击的代码； 2. 有意或无意地将易受攻击的第三方源代码或二进制文件合并到产品中； 3. 利用构建过程中的弱点在产品组件中注入恶意软件； 4. 在交付机制中修改产品，导致在客户部署的原始包、更新或升级包中注入恶意软件。 >>>> 建议的缓解措施 供应商和开发人员管理团队应制定政策，确保开发组织具有以安全为中心的原则和指导方 针，以： • 生成架构和设计文档； • 聚集训练有素、合格且值得信赖的开发团队； • 创建威胁模型软件产品； • 定义和实施安全测试计划； • 定义发布标准并根据它评估产品； • 建立产品支持和漏洞处理政策和程序； • 评估开发人员的能力和对安全开发过程的理解并分配培训； • 记录和发布每个软件版本的安全程序和流程。 >>>> 架构和设计文档 架构和设计文档应基于已收集、关联和优先排序的客户和营销需求。从运营客户环境和已知 产品风险评估中得出的特定安全相关评估和可靠性标准应包含在要求中。这些要求应考虑基 于零信任原则的特定行业的安全标准， 架构和设计文档应解决所有已定义的需求，并根据开 发团队的需要，详细描述实现产品所需的组件、接口和功能。 >>>> 开发团队 开发团队的成员应经过培训并具备执行架构和高级设计文档中概述的安全开发任务的资格。 >>>> 威胁模型 高级安全架构师和开发人员应该为正在开发的产品创建威胁模型。构建管道中涉及的所有代 码和系统都应针对相关威胁模型进行持续审查。应根据需要进行更改，以确保代码和系统都 没有结构漏洞。威胁模型应进一步： • 随着功能的变化、主要版本的更新，至少每年更新一次； • 提供给正在操作任何相关软件组件或系统的其他内部工程团队。 管理策略还应指定分配给创建威胁模型的开发人员使用组件级设计以确保完整性。模型应由 团队中至少两名独立工程师审查和批准，并随着架构和设计更改的发生而发展。当组织政策 和程序发生变化时，威胁模型过程需要适应。 >>>> 安全测试计划 QA 团队由自动化和构建专家组成，他们利用所需的现代技术为架构和高级设计文档中定义的 所有组件应用安全测试策略。 开发人员应执行由 QA 验证的单元级和系统级安全测试。这允许 QA 执行进一步的安全测 试，以减少重复工作，以涵盖更广泛和更深入的测试集。测试计划中定义的策略应包括： • 代码覆盖率，集成到每个构建中并作为实施测试和开发计划的一部分进行跟踪； • 理想情况下，在提交新代码前，所有签入的代码都应达到代码覆盖率的基线水平； • 策略应该是定义为最大化代码覆盖率并解决美国国家标准与技术研究院 (NIST) 特别出 版物 (SP) 800-218 标准的 PO.2.1、PW.5.2 和 PW.8.2 中定义的 SSDF 任务， • 测试覆盖率应确定测试计划涵盖的代码路径的百分比以及使用的测试工具的类型。 当定义发布准备标准时，它们可能包括对以下类型测试的要求： • 应在签入前对所有代码执行静态和动态应用程序安全测试（SAST 和DAST），并使用 公司批准的标准工具集对每个版本执行； •应记录测试结果，并分析和解决所有发现的漏洞； • 应对所有第三方软件执行软件组成分析，包括根据 MITRE 常见漏洞和披露 (CVE) 和 NIST 软件安全漏洞公告进行审查； • 在开发过程中应该对所有软件组件执行模糊测试，以确保它们在不同的输入下表现出 预期的行为； • 在可能的情况下，计划使用内存安全的编程语言来缓解常见可利用漏洞； • 进行验证，以确保根据软件运行的平台，在开发中利用适用的反入侵功能； • 按常规进行渗透测试 ，每年不少于一次。 >>>> 发布标准 管理团队应建立、管理和应用发布标准，并评估产品是否满足标准。标准应包括： • 在执行所有必需的威胁建模和测试时未发现不可接受的安全漏洞； • 在开发过程中维护了开发环境的网络安全卫生。收集并安全存储开发人员和相关工件 以供参考；  • 产品是按照组织设定的安全软件开发实践和任务开发的，相关工件被收集并安全存储 以供将来参考； • 生成、关联和验证软件物料清单 (SBOM)。 >>>> 产品管理团队 确保所有发布的二进制文件都使用与来自受信任的证书颁发机构的根证书关联的密 钥进行数字签名； 所有发布的软件都符合公司范围内的加密标准。这些标准应基于相关行业最佳实践 或适用的政府标准；联邦政府使用加密标准的指南：加密机制并通过适当定义的负 责任、负责、咨询和知情 (RACI) 矩阵来执行； 所有开源的运输都符合公司范围的标准，包括源和漏洞评估。 >>>> 产品支持和漏洞处理政策 管理团队定义产品支持和漏洞处理政策和程序，因其涉及产品从概念到生命周期结束 (EOL) 的整个生命周期。 • 使用漏洞提交系统，应收集所有已知的安全问题和漏洞，并将其作为产品缺陷在组织 的缺陷跟踪工具中进行跟踪。 • 企业应该有一个产品安全事件响应团队 (PSIRT)，它支持面向公众的报告工具，使外 部研究人员可以轻松报告组织产品中的漏洞。 • 应使用 HTTPS/TLS 等安全协议交付所有现场软件的更新，包括补丁和产品更新。 >>>> 评估和培训 管理团队定义用于评估开发人员的能力和对安全开发过程的理解的政策和程序。这些政策应 解决培训范围、培训周期 、主办部门、培训主题、培训评估等。 理想情况下，开发团队的安全培训由集中的专家安全团队进行，帮助产品团队提高安全开发 方面的专业知识。培训应包括：安全的软件开发和设计、安全的代码审计、软件验证测试、 开发过程中使用安全和漏洞评估工具。企业应确保个人完成与分配给个人的系统和软件的影 响级别相称的安全培训。 应至少每年定期评估开发团队中的个人，以衡量他们对产品安全目标的了解和合规性。 >>>> 安全程序和流程 管理团队记录安全程序和流程。这些文档应经过审查、更新，并尽可能为每个软件版本公 开。这必须在不泄露有关产品的敏感安全信息的情况下完成。在产品开发过程中出现问题时 以及在产品发布后在正式的“事后行动”报告或“经验教训”会议中，对参与安全开发过程的所有 成员进行审查。 >>>> 与 SSDF 保持一致 本节中提供的缓解措施与 NIST SP 800-218“安全软件开发框架 (SSDF) 1.1 版：缓解软件漏 洞风险的建议”中的活动保持一致。下表将有形的发展活动与 SSDF 的建议保持一致： 表 1：与 SSDF 的缓解对齐 2 开发安全代码 源代码开发涉及审查批准的产品需求和设计文档并实现所有必需的特性和功能。这应该按照 SSDF PO.1.1、PO.2.2 和 PW 中规定的编写源代码的政策和程序并使用指定的计算机编程语 言来完成。NIST SP 800-218 的第 1 条。 当有机会选择用于开发的编程语言时，应注意该语言是静态类型还是动态类型，以及它固有 地内置了保护措施，以减轻漏洞并提供内存和线程安全操作。安全软件开发遵循 Saltzer 和 Schroeder 在“计算机系统中的信息保护”中概述的原则，其中包括：开放式设计、故障安全 默认值、最小特权、机制经济、特权分离、完全调解、最不常见机制、心理可接受性。 开发人员还可以集成公共核心库并重用已经过