软件供应链安全之开发者最佳实践指南

持久安全框架 软件供应链工作小组 2022年8月 译者简介： 开源安全研究院(gitsec.cloud)目前是独立运营的第三方研究机构，和各工具厂商属于平等合作关系，专注于软件安全相关技术及政策的研究，围绕行业发展的焦点问题以及前沿性的研究课题，结合国家及社会的实际需求以开放、合作共享的方式开展创新型和实践性的技术研究及分享。欢迎关注我们的公众号。 免责声明： 本指南版权归作者所有，本文翻译工作为公益性质的学习目的，不用于商业用途，翻译本身基于水平与目标不同，并不能与专业翻译水平相提并论，如有错漏，欢迎广大读者联系客服小李进行补充和探讨。 此外我们也有软件安全爱好者的相关社群，也可扫码添加客服小李微信拉进群哦~ 执行摘要 网络攻击是通过网络空间进行的，其目标是企业使用的网络空间，目的是破坏、禁用、恶意控制计算环境或基础设施；破坏数据的完整性；窃取受控信息。1 最近的网络攻击，比如针对SolarWinds及其客户的攻击，以及利用Log4j等漏洞，突出了软件供应链的弱点，这个问题，涵盖了商业和开源软件，影响了私人和政府企业。因此，越来越需要提高软件供应链的安全意识，需要认识到国家对手使用类似的战术、技术和程序(TTPs)将软件供应链武器化的可能性。 作为回应，白宫发布了一项关于改善国家网络安全的行政命令(EO14028)。EO14028建立了新的要求来确保联邦政府的软件供应链。这些要求除了为联邦政府购买软件的客户外，还涉及对软件供应商和开发人员的系统审查、流程改进和安全标准。 同样的，持久安全框架2(ESF)软件供应链工作小组建立了此指导方针，以作为开发人员、供应商和客户利益相关者的建议实践的概要，以确保一个更安全的软件供应链。本系列分为三部分：第一部分关注软件开发人员；第二部分关注软件供应商；第三部分关注软件客户，本指南为第一部分。 客户（购买方）可以将此指南作为描述、评估和度量与软件生命周期相关的安全实践的基础。此外，本文列出的建议实践可以应用于软件供应链的收购、部署和操作阶段。 软件供应商（供应商）负责建立客户和软件开发人员之间的联系。因此，供应商的职责包括通过合同协议、软件发布和更新、通知和减少漏洞来确保软件的完整性和安全性。本指南包含推荐的最佳做法和标准，以帮助供应商完成这些任务。 本文件将提供符合行业最佳实践和原则的指导，我们强烈建议软件开发人员参考。这些原则包括安全需求规划、从安全的角度设计软件体系结构、添加安全特性，以及维护软件和底层基础设施的安全性（例如，环境、源代码审查、测试）。 1国家安全系统委员会(CNSS) 2ESF是一个跨部门的工作组，在关键基础设施伙伴关系咨询委员会(CriticalInfrastructurePartnershipAdvisoryCouncil–‘CIPAC’)的支持下运作，以应对美国国家安全系统的安全和稳定所面临的威胁和风险。它由来自美国政府的专家以及信息技术、通信和国防工业基地部门的代表组成。ESF负责将来自私营部门和公共部门的代表聚集在一起，致力于应对情报驱动的网络安全挑战。 免责声明 免责声明背书 本文件仅供一般参考之用。它适用于各种事实情况和行业利益相关者，本文所提供的信息具有咨询性的性质。本文件中的指导意见由“现状”提供。一旦发布，其中的信息可能不构成最新的指导或技术信息。因此，该文件不构成、也不打算构成合规或法律建议。读者应与各自的顾问和主题专家进行协商，以根据其个人情况获得咨询意见。在任何情况下，美国政府均不对因使用或依赖本指南而产生的任何损害负责。 本指南以商号、商标、制造商或其他方式提及任何特定的商业产品、工艺或服务，并不构成或暗示其对美国政府的背书、推荐或支持，本指南不得用于广告或产品背书目的。所有商标均为其各自所有者的财产。 目的 美国国家安全局、ODNI和CISA开发该文件是为了促进其各自的网络安全任务，包括其制定和发布网络安全建议和缓解措施的责任。这些信息可以被广泛地共享，以达到所有适当的利益相关者。 联系方式 客户要求/查询：EnduringSecurityFrameworknsaesf@cyber.nsa.gov 媒体查询/新闻台 NSAMediaRelations,443-634-0721,MediaRelations@nsa.gov CISAMediaRelations,703-235-2010,CISAMedia@cisa.dhs.gov ODNIMediaRelations,dni-media@dni.gov 目录 执行摘要ii 1介绍1 1.1背景1 1.2文件概述2 2开发人员3 2.1安全产品标准和管理4 2.2开发安全代码11 内部人员对源代码的修改或利用12 开源管理实践19 安全开发实践20 代码集成22 客户报告的缺陷/漏洞问题22 外部开发扩展23 2.3验证第三方组件24 第三方二进制文件24 选择和集成25 从知名和可信的供应商处获得组件25 组件维护26 软件物料清单（SBOM）26 2.4强化构建环境27 构建链式漏洞28 被攻击的签名服务器33 2.5交付代码34 最终软件包验证34 破坏软件包和更新的潜在策略35 分配系统的受损35 3附录37 3.1附录A:场景和SSDF之间的对照表37 3.2附录B:依赖关系39 3.3附录C:软件产品的供应链级别(SLSA)40 3.4附录D:工件和检查表42 3.5附录E:资料性参考文献55 3.6附录F:本文件中使用的首字母缩略词59 1介绍 软件供应链中未被修复的漏洞给企业带来了巨大的风险。本文为软件供应链的开发、生产和分销以及管理流程提出了可行的建议，以提高这些流程的抗风险能力。 所有组织都有责任建立软件供应链安全实践以降低风险，但组织在软件供应链生命周期中的角色决定了这一责任的形式和范围。 由于保障软件供应链安全的考虑因素，往往因组织在供应链中扮演的角色不同而不同，因此本系列介绍了针对这些重要角色的建议，即开发人员、供应商和客户（或购买软件产品的组织）。 该系列分为三部分，并将与软件供应链的生命周期同步发布。该指南的第一部分，主要针对软件开发人员。该系列的第二部分侧重于软件供应商，第三部分侧重于软件客户。这个系列将有助于促进这三个不同角色之间以及网络安全专业人员之间的沟通，从而促进软件供应链过程中的弹性和安全性的提高。 在本系列中，诸如风险、威胁、利用和脆弱性等术语是基于国家安全系统委员会词汇表（CNSSI4009）中定义的描述。3 1.1背景 历史上，软件供应链的破坏主要是针对那些没有打补丁的已知漏洞组织。虽然威胁者现在仍然使用这种策略来破坏未打补丁的系统，但一种新的、不那么引人注目的破坏方法也威胁到软件供应链，并破坏对打补丁系统本身的信任，这些信任对防范传统的破坏至关重要。攻击者不是等待公开的漏洞披露，而是主动将恶意代码注入产品，然后通过全球供应链合法地分布到下游。在过去的几年中，这些下一代软件供应链的破坏在开源和商业软件产品上显著增加。 技术消费者通常会分别管理软件下载和更广泛、更传统的软件供应链活动。将软件的上游和下游阶段都作为供应链风险管理的一个组成部分来考虑，可能有助于发现问题，并在集成活动以实现系统安全方面提供更好的发展方向。 然而，在软件产品方面也有一些差异需要说明。传统的软件供应链周期是从原产地到消费地，一般来说，客户可以退回故障产品并限制任何影响。相反，如果软件包被注入恶意代码，并扩散到多个消费者；其规模可能更难限制，并可能造成指数级的影响。 针对软件供应链的常见破坏方法包括利用软件设计缺陷、将易受攻击的第三方组件纳入软件产品、在最终软件产品交付前用恶意代码渗入供应商的网络，以及注入恶意软件，然后由客户部署。 3CNSSI-4009.pdf 利益相关者必须设法减轻其责任领域所特有的安全问题。然而，其他的问题可能需要一个缓解的方法，它决定了对另一个利益相关者的依赖性或多个利益相关者的共同责任。没有充分沟通或解决的依赖性可能导致漏洞和潜在的损害。 可能存在这些类型的漏洞的领域包括: 未记录的特征或有风险的功能； 在评估和部署之间，对合同、功能或安全假设的未知/修订； 供应商的所有权和/或地理定位的变化； 供应商企业或发展卫生条件。 1.2文件概述 本文件包含以下附加章节和附录: 第2章推荐了开发人员可以用来帮助保护软件开发生命周期（SDLC）的原则，这是一个用于保护软件供应管道的重要过程。 第3章是补充前几节的附录集合: 附录A:NISTSP800-218之间的对照表；通过采用安全软件开发框架（SSDF）4和本文所述的用例来减轻软件漏洞的风险。 附录B:依赖关系 附录C:软件产品的供应链级别（SLSA）5附录D:推荐的工件和检查表 附录E:资料性参考文献附录F:缩写词 每一节都包含了威胁场景的例子和建议的缓解措施。威胁场景解释了构成软件开发生命周期 （SDLC）特定阶段的流程与可能被利用的常见漏洞之间的关系。建议的缓解措施提出了可以减少威胁影响的控制和缓解措施。 4NISTSP800-218草案，安全软件开发框架（SSDF）1.1版：关于减轻软件漏洞风险的建议 5GitHub-slsa-framework/slsa:软件工件的供应链级别 2开发人员 安全软件开发生命周期（SecureSDLC）是一个用于保障软件供应链安全的重要过程。下图表示了个别小组活动以及客户、开发者和供应商之间的关系的例子。： 图1：软件供应链集团的关系和活动 当供应商的项目管理团队从其客户的用户群、技术基础和营销团队收集功能请求时，这个过程就开始了。这些功能包括对产品的操作和安全改进，并用于生成用例，然后将其制定为优先的需求。供应商和开发商管理团队一起工作来定义需求，这些需求被用来产生架构和高级设计，开发团队使用这些设计来生产产品。此外，联合管理团队定义了生产产品时使用的产品开发安全政策和实践。该流程定义了如何构建开发活动，以及将收集哪些工件用于验证和确认。以下是安全SDLC过程和实践的简短例子清单: NIST"安全软件开发框架"6 卡内基梅隆大学"安全软件开发生命周期流程"7 ACM"计算机系统中的信息保护"8 OWASP"安全开发生命周期"9 6OWASP"安全开发生命周期" 7卡内基梅隆大学"安全软件开发生命周期流程" 8https://web.mit.edu/Saltzer/www/publications/protection/ 9OWASP"安全开发生命周期"(SSDLC) "思科安全开发周期"10 Synopsys"安全软件开发生命周期阶段"11 US-Cert"安全软件开发生命周期流程"12 OpenSSF"安全软件开发基础课程"13 除了制作的高级开发文件外，管理团队还定义了用于安全软件开发的安全实践和程序，如： 安全编码实践; 代码审查过程; 软件库程序，测试，和漏洞评估; 安全地构建和分发产品的程序。 一旦发布，产品将通过产品客户可用的支持渠道监测缺陷，开发人员可以安全地提供更新和升级以解决报告的问题。对于安全SDLC中的每一项操作，都要创建工件，以证明对所需流程的遵守和概述。这些工件在"附录D:工件和检查表"。 2.1安全产品标准和管理 正如第2.2节开发安全代码到第2.5节交付代码所描述的，开发人员的用例取决于安全SDLC过程中定义的程序和政策。开发团队的经理和成员调整和定制这个过程，以满足他们的具体需求。安全SDLC确定了确切的程序和政策，用于确保安全开发实践的实施和工件的创建，以证明所采用的安全SDLC计划在产品的实施和分发方面的遵守情况。 开发团队是由开发、质量保证（QA）、构建工程和安全方面的专家组成的。产品管理团队由具有产品领导经验的人员组成，包括产品和开发经理、安全架构师和公司级质量控制评估师，他们都对产品发布监督做出贡献。 最高级别的