以下内容来源悬镜安全、ISC、中国电信研究院联合出品的报告《软件供应链安全治理与运营白皮书（2022）

Google SLSA 框架

针对软件供应链攻击问题，谷歌提出了 SLSA（Supply Chain Levels for Software Artifacts，软件制品的供应链级别）解决方案，旨在确保软件开发和部署过程的安全性，专注于缓解由于篡改源代码、构建平台或构件仓库而产生的威胁。

在其当前状态下，SLSA 是一套被逐渐采用的安全准则，由业界一致认可。在最终形式中，SLSA 在可执行性方面与最佳实践列表有所不同：它将支持自动创建可审核元数据，这些元数据可以输入到策略引擎中，以便为特定包或构建平台提供“SLSA 认证”。SLSA 被设计成持续的和可操作的，并且在每一步都提供最优措施。一旦一个组件达到了最高级别，用户就可以确信它没有被篡改，并且可以安全地追溯到源代码。

SLSA 侧重于以下两个主要原则：

（1）非单方面：

任何人都不能修改软件供应链中任何地方的软件制品，除非经过至少一个其他“受信任的人”的明确审查和批准。目的是预防和尽早发现风险的变化。

（2）可审计：

软件制品可以安全透明地追溯到原始的、人类可读的来源和依赖项。主要目的是自动分析来源和依赖关系，以及临时调查。

尽管并不完美，但这两个原则为广泛的篡改、混淆和其他供应链攻击提供了实质性的缓解。为了根据上述两个原则衡量供应链的保护程度，Google 提出了 SLSA 级别，SLSA 由四个级别组成，其中 SLSA 4 表示理想状态。较低级别表示具有相应完整性保证的增量里程碑。这些要求的定义如下表所示。

CNCF in-toto 框架

2022 年 3 月 11 日，CNCF 发文表示，CNCF 技术监督委员会（TOC）已投票接受 in-toto 作为 CNCF 的孵化项目。in-toto 是一个用于保护软件供应链完整性和可验证性的系统。它通过使用户能够收集到关于软件供应链行为的信息，并允许软件消费者和项目经理发布关于软件供应链实践的政策来保护软件供应链的完整性和可验证性，这些政策可以在部署或安装软件之前进行验证。简而言之，它有助于捕获软件供应链中发生的事情，并确保它按照定义的策略发生。

in-toto 的实现主要包含三个组件：

·用于生成和设计供应链布局的工具。项目所有者将使用此工具生成所需的供应链布局文件。其中供应链布局（也称布局、布局元数据）是指一个签名文件，规定了在软件供应链中创建最终产品需要执行的一系列步骤。布局包括有序步骤、这些步骤的要求以及负责执行每个步骤的参与者（或工作人员）列表。供应链中的步骤由项目所有者布置。

·一种工具，工作人员可以使用该工具创建有关步骤的链接元数据。例如“in-toto-run.py”。其中，链接是指执行供应链步骤或检查时收集的元数据信息，由执行该步骤的官员或执行检查的客户签名。此元数据包括材料、产品和副产品等信息。

·客户用来对最终产品进行验证的工具。此工具使用上述工具生成的所有链接和布局元数据，它还按照布局的指示执行检查步骤。此工具通常包含在包管理器或系统安装程序中。例如“in-toto-verify.py”。

下面我们将描述一个简单的场景，对框架系统的工作流进行一个说明：

项目所有者 Alice 希望 Diana 写一个 Python 脚本（foo.py），且希望 Bob 将脚本打包成一个 tarball（foo.tar.gz）。该压缩包将作为最终产品的一部分发送给客户 Carl。在向 Carl 提供压缩包时，Alice 将创建一个布局文件用来说明以下内容：

 ·脚本是 Diana 写的；

 ·将脚本打包是由 Bob 完成的；

 ·压缩包中包含的脚本与 Diana 编写的脚本匹配。

因此如果 Bob 是恶意的，或者打包程序有错误，Carl 为了能够检测到问题，在最终产品中要求四个文件：（1）Alice 的布局文件，描述上面列出的要求；（2）一段能够对应于 Diana 编写脚本的链接元数据；（3）一段Bob 打包脚本步骤的链接元数据；（4）目标文件（foo.tar.gz）也必须包含在最终产品中。

当 Carl 验证最终产品时，他的安装程序将执行以下检查：

(1) 布局文件存在并使用受信任的密钥（在本例中为 Alice 的密钥）进行签名；

(2) 布局文件中的每个步骤都有一个或多个由预期函数签名的相应链接元数据文件，如布局文件中所描述的信息（在本例中为 Bob 和 Diana 提供的链接元数据）；

(3) 链接元数据中列出的所有材料和产品都能够一一对应起来，正如布局文件描述的信息一样，防止包在没有记录的情况下被更改，或在传输过程中被篡改。（在本例中 Diana 和 Bob 的材料应相匹配）；

(4) 最后，检查步骤在客户端运行，检查压缩包，以验证提取的 foo.py 文件是否与 Diana 编写的文件相匹配。如果这些所有验证都通过，则安装将照常继续。

此示例的流程

Microsoft SCITT 框架

Microsoft 的供应链完整性、透明度和信任 (SCITT，The Supply Chain Integrity，Transparency and Trust) 计划是一套已提议的行业标准，用于管理端到端供应链的产品和服务的合规性。它支持对产品和服务的持续验证，其中可以确保实体、证据、政策和制品（软件或硬件）的真实性，并且可以保证实体的行为是经过授权的、不可否认的、不可变的和可审计的。

Microsoft 在之前将 SCITT 称为 SCIM（Supply Chain Integrity Model，供应链完整性模型），包括在去年提交给 NIST 的，与 EO 14028 相关的提交中。SCIM 与开发和实施供应链完整性要求的迭代方法保持一致，允许根据不断变化的威胁模型和实践随着时间的推移进行增强。分阶段推出需求以提高供应商规划和工程的清晰度，并最大限度地减少中断。其工作流程如图所示，描述了供应链完整性模型中实体之间的制品、证据和策略流。

SCIM 的工作流程

其中，供应商创建制品（a），认证者创建证据（b）并提交到应用商店进行日志记录、查询和检索。供应商和认证者可能是同一实体。策略管理器创建策略（c）并提交到存储区，在其中记录策略并可供查询和检索。用户代理（d）接收制品（a），检索证据（b）和策略（c），并验证制品。

下图显示了 SCIM 在软件开发生命周期（SDLC）中的应用示例。

SCIM 在软件开发生命周期（SDLC）中的应用

当前 SCITT 行业标准还在制定中，随着 NIST 对其不断地完善，相信之后 SCITT 能够发挥其更大的作用。

软件供应链安全框架对比分析

软件供应链安全框架和模型的建立可以帮助企业组织理解软件供应链安全活动的关键要素，从而帮助企业组织了解当前自身安全现状，在企业构建的软件供应链安全治理与运营体系中选择适合自身企业的安全活动或措施，制定相应的解决方案，进而使组织的软件供应链安全逐渐成熟。上述三种软件供应链安全治理框架对比分析如下：

软件供应链安全治理框架