从SolarWinds攻击到Log4j漏洞，再到近期以反战名义对开源软件供应链投毒事件，软件供应链安全问题愈演愈烈，因其带来的巨大危害引发全球关注。寻求有效、可落地的保障方法成为软件供应链相关各方的共同目标。
安全开发框架作为软件开发生命周期中各阶段安全实践、活动和措施的集合，能够指导使用者提高软件生产和产品的安全性，并且它们越来越多的将供应链因素考虑在内，形成一个不断完善的保障体系。
本文通过对六种主流安全开发框架的最新版本进行分析，总结了共性和差异，归纳了供应链安全保障的主要环节，提出了操作指南细化的初步思路。
六种框架包括安全软件开发框架(NIST SSDF) V1.1、软件联盟安全软件框架(BSAFSS) V1.1、SAFECode安全软件开发基本实践 V3、软件保障成熟度模型(OWASP SAMM) V2.0、安全内建成熟度模型(BSIMM) V12和微软安全开发生命周期(MSSDL) 2022。
一、六种主流安全开发框架的异同点
六种主流安全开发框架面向开发组织，以软件的风险管控和漏洞防控为目标，以软件开发生命周期为主线。框架均采用多级分类的形式：即首先划分为大类，然后逐级细化，名称不同，但最终都细化为具体的安全要求或措施，以指导使用者。
六种框架的最新版均较多涉及软件供应链安全方面的内容，如第三方组件/开源组件的安全管控、对供应商的安全要求、开发工具和环境的安全防范、构建部署环境的安全防护、第三方组件漏洞响应等；SSDF V1.1作为应美行政令要求而出台的高层级实践框架，参考了其他5个框架的内容。
各框架之间也存在着较大的差异，主要差异如表1所示。
二、软件供应链安全保障的主要环节
通过对各框架具体内容的分析可以发现，除了自主研发软件代码和产品的安全措施外，软件供应链安全保障实践主要涉及4个环节。
1、第三方组件的安全管控
作为最终软件产品的重要组成部分，商业、开源和其他第三方来源组件等“外来原料”的安全性是软件供应链安全保障首先要考虑的问题，六种安全开发框架也都将针对第三方/开源组件的保护作为重点。
SAFECode安全软件开发基本实践将第三方组件安全风险管理(TPC)作为单独一部分进行系统描述。TPC管理共有4个步骤：TPC列表维护、评估来自TPC的安全风险、缓解或接受风险、监控变化，每个步骤又包含若干具体措施，如图1所示。
其他几种框架关于第三方组件的安全要求也符合图1模型中的步骤，只是对某些方面的措施进行了细化，例如：
第三方组件列表维护方面
框架考虑了来源信息和依赖关系的记录与分析(SSDF PW.4.1、BSAFSS SM.2-2/SM.2-3、SAMM SB1/SB2/SB3、BSIMM SR2.4/SE3.6)，以及第三方组件的获取、批准、符合性、保存和维护(SSDF PW.4.1/PW.4.4、SAMM SA3、MSSDL开源软件风险管理实践1)等要求；
风险评估方面
框架考虑了第三方组件的安全漏洞检测及发现(SSDF PW4.4/PW.7.1/ PW.8.1/RV.1.1、BSAFSS VM.1-3、SAMM ST1、BSIMM CR1.2、MSSDL开源软件风险管理实践2)、安全性评估(BSIMM SFD2.1)、使用复杂性评估(SAMM SA2)等实践；
风险缓解方面
框架考虑了第三方组件漏洞的公开和修复(SSDF RV.1.3、BSAFSS VM.1-3/VM.3)、打补丁(BSAFSS VN.1、SAMM EM1)、控制开源风险(BSIMM SR3.1、MSSDL开源软件风险管理实践3和4)等措施；
在生命周期监管方面
框架考虑了监控第三方组件的生命终止(BSAFSS EL.1-3)、定期替换已终止的第三方应用及依赖关系(SAMM OM2)等内容。
小结：所有框架对第三方/开源组件的维护、风险评估和缓解(特别是安全漏洞的检测和修复)都有详细的措施；除SSDF和BSIMM外也都提到了对组件生命周期变化的监控。它们都把第三方/开源组件的风险管控放在重要位置，而且已具备系统性的管控措施。
2、针对供应商的安全要求
如果说第三方组件是供应链中重要的原材料，软件供应商无疑就是其中最主要的主观因素。提高供应商的安全意识、能力，对其进行必要的安全要求，也是供应链安全中不可或缺的一环。
安全开发框架中对供应商的安全要求主要包括对供应商进行评估并签署安全协议、要求供应商使用一致的安全方法并对其进行培训、明确供应商的安全事件响应责任等5个方面，详细如表2所示。
小结：多个框架都要求对供应商进行评估和签署安全协议；BSIMM对供应商的要求最为全面，涉及所有5个方面；上述这些对供应商的要求贯穿于软件开发生命周期的全过程，在安全层面将供应商与组织捆绑在一起。
3、软件基础设施的安全性
软件产品的基础设施包括开发、构建、部署、运维等过程中所使用的工具和环境等，这些设施一般由第三方提供，近年来发生的供应链攻击事件也多与其相关，如Codecov供应链攻击事件，因此它们的安全性也成为目前关注的焦点。6种安全开发框架对各阶段基础设施的安全性也有较为详细的要求：
开发工具和环境的安全性方面
框架考虑了开发环境的隔离、开发终端的加固(SSDF PO.5.1/PO.5.2)；内部代码库和加密服务密钥保护、最新版开发工具的使用、开发框架的安全配置、开发环境访问的强身份认证(BSAFSS DE.1-2/DE.1-3/DE.2-1/DE.2-2/IA.1-1)；开发环境安全质量评估、SDK之类的库和组件及系统的安全性评估(SAMM SA1/AA1)等措施。
安全构建方面
框架考虑了使用最新版本和批准的编译器等构建工具(SSDF PW.6.1/PW.6.2、SAFECode实践、MSSDL实践8)、对构建工具进行检查验证及强制执行安全基线(SSDF PW.6.1、SAMM SB1/SB3)、选择适当的编译特性并进行安全配置(SSDF PW.6.2、BSAFSS DE.2-3/DE.2-4/DE.2-5)、构建过程的自动化(SAMM SB2)等措施。
部署和运维环境的安全性方面
框架考虑了容器和虚拟化环境的使用编排及部署自动化(BSAFSS DE.2-6、SAMM SD2、BSIMM SE2.7)、部署的安全检查和安全配置(BSAFSS DE.2-6、SAMM SD2、BSIMM AA1.1/ SE2.2)、确保安装在正确硬件和授权用户的机制(BSAFSS SM.6-1)、可部署工件风险数据的发布(BSIMM CMVM3.6)、主机网络及云安全能力保障(BSIMM SE1.2/SE2.6)、基础运维设施安全的验证(BSIMM CMVM3.5)等措施。
小结：BSAFSS和SAMM在3个方面均有涉及；SSDF更关注开发和编译环境的安全；BSIMM在部署和运维环境安全方面的实践更多一些，特别是运维；SAFECode和MSSDL主要对安全构建进行了要求。虽然各有侧重，但所有框架都有对基础设施安全保护的要求，并且相信后续版本中此类措施会越来越多。
4、软件自身安全性的保护
软件（包括补丁）的伪造和篡改同样是供应链攻击的主要手段之一。软件完整性保护就是通过验证软件来源、授权、完整性等信息的一致性来防止此类问题的机制，代码签名和来源信息验证是其中最为主要的方法；此外，补丁的安全性也是软件自身保护的重要部分。框架的相关措施包括：
软件完整性保护方面
措施包括建立代码签名和第三方工件签名之类的软件完整性保障机制(SSDF PS.2.1/ PS.3.1、BSAFSS SM.4-1、SAMM SD3、BSIMM SE2.4/SE3.2)、软件来源数据的收集维护及验证(SSDF PS.3.1/PS.3.2、BSAFSS SM.4-2、BSIMM SE2.4)、每个交付产品特定软件版本的唯一标识(BSAFSS SM.4-3)等。
补丁安全性防护方面
措施包括对补丁进行功能和安全测试(BSAFSS VN.1-3)、通过可信和自动化渠道交付补丁(SSDF RV2.2、BSAFSS VN.2-1)、对补丁进行签名以确保其完整性(BSAFSS VN.2-2)、追踪打补丁流程对SLA的合规情况(SAMM EM3)等。
小结：多数框架对软件完整性保护进行了要求，并遵循主流的防篡改方法；在补丁安全性防护方面，BSAFSS从测试、传输、防篡改等角度进行了要求，最为全面。
三、安全开发框架主要指导作用思考
安全开发框架以软件开发生命周期为主线，基于组织和企业的实践和操作经验，并将供应链相关的安全措施纳入，目前各类安全开发框架的内容也较为丰富，对软件供应链安全保障工作具有一定的指导作用，主要体现在以下两点：
一是在直接使用方面，鉴于框架不同的编制背景，软件供应链安全决策和策略制定等相关人员可更多的参考结果导向框架的内容，关注目标和效果，并结合自身的实际情况，从中选取适当的实践作为策略制定和实施的基础；具体安全实施等人员可较多的参考过程导向的框架，关注实现的技术和方法，并结合自身情况选择性实施。
二是在进一步细化后使用方面，由于各框架的许多内容之间存在着对应关系，因此未来可考虑将结果导向和过程导向的两类框架结合起来，选取便于落地的实践，并进一步细化每项实践对应的具体操作、技术、机制和工具等内容，形成覆盖“保障结果->过程方法->具体操作->辅助工具”的软件供应链安全保障字典式详细实施方案，满足相关各方人员的需求。
关于作者
董国伟，虎符智库专家，奇安信集团代码安全实验室高级专家，博士，从事网络安全、软件安全、代码审计和漏洞分析相关工作近20年。
声明：本文来自安全内参，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
