自2020年底政府和企业网络遭受大范围SolarWinds攻击以来，美国加快推出软件供应链安全的各类措施。根据2023年2月初的公开报道，美网络安全和基础设施安全局(CISA)正在组建一个新办公室，专注于政府供应链安全并负责向政府机构、行业及其他合作方提供供应链风险管理政策及技术指导。

早在去年9至11月间，CISA就联合美国家安全局(NSA)和国家情报总监办公室(ODNI)陆续发布了三份《软件供应链安全推荐实践指南》，分别针对开发者(Developer)、供应商(Supplier)和用户(Customer)，给出了一组涵盖安全原则、威胁场景、缓解措施的指导。

相比之下，这种区分角色的指南更便于软件供应链各参与方明确自己的目标和责任、形成协作机制；此外，该系列指南的缓解措施给出了具体的实现技术和操作方法，便于各角色参照使用。

一、软件供应链安全推荐实践系列指南解读

该系列指南由持久安全框架(ESF)组织具体编制，它们并非行政令EO 140238要求的成果，但参考了《安全软件开发框架(SSDF)》等标准，指南附录部分也列出了各章节与SSDF安全实践的对应关系表。系列指南主要有以下特点：

1、根据角色确定安全实践的形式和范围

指南编制的基本指导思想是：组织在软件供应链周期中的角色决定了其建立安全实践的形式和范围。从发布者CISA、NSA和ODNI来看，其关注的场景应主要聚焦于政企组织的供应链安全，包括开发者、用户(即采购组织)，以及负责联络它们的供应商(即卖方)三种角色，它们之间的关系及典型的安全活动如下图所示。

其中，开发者的安全职责包括安全需求规划、从安全角度设计软件架构、添加安全特性，以及维护软件和底层基础设施(如环境、源码的审计和测试)的安全等；供应商通过合同协议、软件发布和更新、通知及漏洞缓解来确保软件的完整性和安全性；用户则主要负责推动实施软件产品采购、部署和运营阶段的安全活动和措施。

2、不同角色的安全活动兼具差异和协同

鉴于以上思路并考虑到常见的软件供应链安全风险，指南把各角色的安全活动进一步分类和细化，形成了“推荐的安全原则”，即软件供应链各类参与者应关注的安全领域，如下表所示。

从表中可以看出，开发者侧重于生产研发的安全、供应商侧重于保障的安全(验证和完整性等)、用户侧重于部署运营和使用的安全。但它们之间不是割裂的，例如，三者都涉及交付的安全活动，另外，漏洞响应更是一个“反馈(用户->供应商->开发者)”和“修复(开发者->供应商->用户)”的双向协同过程。因此，它们既有各自的安全职责，同时也高度协作，共同保护软件供应链的安全。

3、缓解措施定位在技术实现和操作层面

对于每条安全原则，指南详细描述了对应的“威胁场景”和“推荐的缓解措施”，下表总结了开发者“验证第三方组件”类原则的核心内容，针对第三方组件的来源审查、安全扫描、集成前评估、集成后维护、信息记录(SBOM)等环节给出了缓解措施，并且具体到了实现技术、参考条例和操作流程的粒度，较为详细。

二、美国软件供应链安全指南的角色适用性分析

自2021年以来，美国加快了软件供应链安全的建设，特别是通过行政令的专门章节强化了对软件供应链安全各方面的要求，涉及标准、指南、措施等规范性文件的制定和修订。由NIST修订完成的SSDF 1.1和《系统和组织网络安全供应链风险管理实践》(SP 800-161r1)是其中的重要成果。

面向软件提供者的SSDF

SSDF 1.1的安全实践涉及需求、设计、第三方软件集成、编码、构建、源代码和可执行码测试、漏洞修复响应和分析等阶段，重点关注实现实践的结果，而未对实现的具体工具、技术和机制进行展开。SSDF侧重于软件的提供者(大致与《软件供应链安全推荐实践指南》中“开发者+供应商”的角色对应)。

考虑到SSDF适用对象的局限，为了帮助美联邦机构(购买者)响应行政令的要求，NIST还编制了补充文件《基于EO 14028 4e的软件供应链安全指引》，指引提供一组建议，用来确保软件生产商遵循了基于风险的安全软件开发方法，并非具体的指导实践内容。

面向需求方的SP 800-161r1补充指引

另一重要指南SP 800-161r1，旨在帮助组织开展网络安全供应链风险管理(C-SCRM)，为它们提供识别、评估、选择、实施风险管理过程和缓解控制的指导。但软件供应链安全管理是C-SCRM的关键子学科，因此，为了响应行政令，并能够更有针对性的给组织的IT、C-SCRM、采购等部门提供第三方软件和服务的获取、使用及维护等方面的安全指导，NIST编制了《基于EO 14028 4c/4d的软件供应链安全指引》(也是SP 800-161r1的附录F)。

指引包括“现有的标准、工具和推荐实践”和“演进中的标准、工具和推荐实践”两大部分。前者涉及“EO关键软件定义”、《关键软件使用安全措施》、SSDF 1.1、《开发者验证软件的最低标准指南》等行政令要求制定的文件对SP 800-161r1各章节内容，特别是C-SCRM安全控制项的影响或与它们的对应关系；后者针对为美联邦机构量身定制的SBOM、开源软件控制、漏洞管理、供应商风险评估等软件供应链新概念，定义了多层级的能力标准。这些都是面向需求方/用户(包括美联邦机构)的。

美国软件(供应链)安全相关的标准、指南、框架多以软件开发生命周期作为基础模型(参见《美国“加强软件供应链安全实践的指南”(SSDF V1.1草案)解读》和《从主流安全开发框架看软件供应链安全保障的落地》)，比较容易在每个环节中结合参与角色的(安全)职责，确定针对性的安全策略和安全措施。这一过程可使用一个矩阵来表示，姑且叫做软件供应链安全责任矩阵，下图是《软件供应链安全推荐实践指南》对应的矩阵。

三、对我国软件供应链安全标准的相关建议

国家标准《软件供应链安全要求(送审稿)》规定了对软件供需双方的安全要求和控制措施，更侧重于对需方的要求；此外，国内正在编制的一些软件供应链安全行业和团体标准也多从供需双方考虑安全要求。

《ICT供应链安全风险管理指南(GB/T 36637-2018)》规定了ICT供应链的安全风险管理过程和控制措施，适用于ICT产品和服务的供方和需方、第三方测评机构等。标准中风险管理和控制措施部分的详细条目未明确指定对应的具体角色，统一使用“组织”作为规范对象；《信息技术产品供应方行为安全准则(GB/T 32921-2016)》面向信息技术产品供应方，规定了其行为安全准则。

总体而言，目前我国的供应链安全标准大都考虑到了不同的角色，且与SSDF类似，基本都关注于目标和结果，对于具体实现的技术、工具、机制等讨论较少。鉴于这一现状，建议可从两个方面深化对软件供应链安全的规范和指导：

• 制定行业和领域标准时应首先确定供应链参与各方。对于通用标准，从供需双方进行角色划分可满足普适的指导要求。但对于特定的行业和领域场景，软件供应链参与者可能更加多元和细分。因此在编制此类标准指南时，可首先根据实际情况确定安全职责矩阵，而后制定具体的安全措施。

• 可基于现有标准细化实施方法以形成强操作性指南。现有的标准在科学性和完备性等方面已经过了充分的论证，也较多给出了各方面应达到的安全目标和结果。如果能够在此基础上细化各条目的实现路径，包括技术、工具、方法等内容，则可让组织和企业“按图索骥”，从而提升软件供应链安全保护工作的可操作性和效率。

关于作者

董国伟，虎符智库专家，奇安信集团代码安全实验室高级专家，博士，从事网络安全、软件安全、代码审计和漏洞分析相关工作近20年。

声明：本文来自士冗科技，版权归作者所有。文章内容仅代表作者独立观点，不代表士冗科技立场，转载目的在于传递更多信息。如有侵权，请联系 service@expshell.com。