软件供应链攻击的威胁一直笼罩在软件行业的上空，让人感觉很平静。当Solarwinds受到大规模的软件供应链攻击，导致至少1000亿美元的恢复费用时，这一切都改变了。这唤醒了整个行业对这一威胁的关注，企业争相修补这一漏洞。但是，未知的情况仍然存在--在漏洞被修补之前，他们造成了什么损失？黑客的攻击越来越多，因为感染一个常用的软件组件，就有可能让所有使用该软件组件的企业获得未经授权的访问。更糟糕的是，企业可能没有意识到他们有漏洞，因为这个软件组件或依赖关系是打包在他们信任的软件中的。
最近比较突出的漏洞，如Log4J和Spring4Shell，只是风暴的开始。根据Sonatype最近发布的2021年软件供应链状况报告，供应链安全攻击正在以前所未有的速度增加。在美国，拜登总统发布了一项改善国家网络安全的行政命令，特别指出了软件供应链攻击的威胁，并要求私营和公共供应商根据NIST的安全软件开发框架（SSDF）和相关的软件供应链安全指南采取行动。根据这一命令，向联邦机构提供服务的软件供应商必须遵守安全软件开发要求，并满足供应链安全指导，否则将不允许向联邦政府出售。联邦政府、军队和银行是少数一直在争相解决供应链威胁的受管制行业。
鉴于软件供应链威胁的重要性和影响，受监管的行业和组织可以做什么来保护自己？这时，开源社区就会一起提供建议、最佳实践、要求和工具。在接下来的几节中，我们将讨论这一切是如何形成的，并能帮助防止未来的此类攻击。
确保供应链安全的标准
软件工件的供应链级别或SLSA是一个安全框架，它提供了一个标准和控制的检查清单，以帮助改善组织的软件供应链。它引入了保证级别，可以用来逐步确保你的供应链安全，如下所示。
| 级别 | 说明 | 例子 |
| 1 | 易于采用，供应链可视性强，能够生成证明文件 | 无符号的出处 |
| 2 | 开始防止软件被篡改，并增加最低限度的构建完整性保证 | 托管的源码/构建，签名的出处 |
| 3 | 加强基础设施对攻击的防护，将更多的信任融入复杂的系统中 | 主机上的安全控制，不可篡改的出处 |
| 4 | 构建完整性的最高保证，并制定了依赖性管理的措施 | 双方审查+密闭式构建 |
企业获得的每一个级别都使他们更接近于检测和预防供应链威胁带来的损害或影响。接下来，我们将深入到实际实施中，看看SLSA使用的两个关键术语和实施不同级别的工具。
根据SLSA的官方定义。
- 证明。关于一个或多个软件工件的经过认证的、机器可读的元数据。
- 证明。关于软件工件的可验证的信息，它描述了某样东西是在哪里、什么时候以及如何产生的。
利用这些定义，我们将简要地看一下上表中显示的实际水平。完整的要求清单相当长，所以我们将讨论主要的要求。
- 第1级对所有组织来说应该是最容易采用的。它需要脚本化的构建和生成出处。
- 第2级增加了托管源码/构建、版本控制和签名证明。这个级别对组织来说有点困难，但仍然相对容易。
- 第三级是事情开始变得复杂的地方。它包括加固的基础设施，短暂的环境，以代码形式构建，以及不可伪造的证明。
- 第四级引入了更多的控制，但最重要的是一个密封的（空气密封的环境）和可重复的构建。这个级别对任何组织来说都是最难获得的，因为它需要改变基础设施、政策和更严格的控制。
我现在该做什么？
很多组织（尤其是受监管的组织）都在问："我应该怎么做才能保护自己免受这种威胁？"对于一个大型组织来说，满足这些要求并不是什么小事。为此，开源社区一直在努力工作，以创建满足SLSA所需的工具和集成，这也有助于实现NIST的SSDF。
生态系统中有多种工具，但我们将专注于几个已经铺平道路的工具。第一个是Sigstore，另一个是Tekton。Sigstore包含多种工具，可以帮助组织做签名（cosign），提供可用于签名的公共CA（fulcio）和透明度日志（rekor）。Tekton Pipelines，首先是一个云原生CI/CD系统（CI/CD Pipeline），可用于跨云供应商和内部系统的构建、测试和部署。结合这个管道，还有另一个工具，一种第三方监控器，被称为Tekton Chains，它可以跟踪管道，并增加做签名和证明生成的能力。
CNCF安全软件工厂参考架构的组成部分
基于CNCF安全软件工厂的参考架构，仍然有一些组件缺失。看一下上图，我们仍然缺少政策框架、准入控制器和运行时可见性等组件。一个被称为FRSCA（Salsa Fresca）的OpenSSF项目，旨在提供一个基于CNCF白皮书提供的最佳实践的完整参考架构。虽然FRSCA仍然是一项正在进行的工作（缺少运行时可见性部分），但它整合了各种组件，为企业和组织提供了一种方法来共同实施这些工具，以满足SLSA提出的要求（这反过来又符合SSDF）。通过目前的工具和功能集，它提供了满足SLSA二级的能力。在未来的一个月里，将增加一些功能，使其达到SLSA的3级。
FRSCA是如何满足SLSA的？
你可能会问，"所有这些工具是如何帮助组织满足SLSA的？"接下来我们将深入了解每个工具在FRSCA中带来了什么，以及它们是如何整合起来帮助我们解决软件供应链安全中的 "构建 "这一块。
- OCI注册表- 开放容器倡议注册表，用于存储图像和其他类型的工件。
- Cosign- 提供签署、验证和存储在开放容器倡议（OCI）注册表的能力。签名与被签名的图像一起存储在OCI注册表中，这样，当用户拉下图像时，他们可以自己验证。
- Fulcio- 一个公共根CA，为Cosign使用的容器签名提供基础。
- Rekor- 透明度和时间戳服务，将已签署的元数据记录到账本上，可以搜索，但不能篡改。
- Tekton管道--CI/CD系统，可将多个任务合并为一个管道，以满足组织的目标。
- Tekton Chains- 监视Tekton管道，并增加了对正在创建的图像进行签名的能力（内部使用cosign），并创建符合SLSA的证明。
- Kyverno- 一个准入控制器，可用于检查进入的工件，以确保它们符合特定的政策，以确保基于最佳实践的构建系统。这与上图中所示的接纳控制器块有关。
- SPIFFE/SPIRE--提供短暂的认证证书，可用于确保构建系统不被篡改。这与上图中的工作负载认证器和节点认证器有关。
- CUE- 一种可用于定义、生成和验证各种数据的语言。在FRSCA中，它被用于验证和策略执行。
现在我们已经探索了各种工具，我们将展示它们如何帮助满足不同的SLSA级别。下面的表格列出了每个SLSA级别的不同要求，以及FRSCA是如何满足这些要求的。
| 要求 | SLSA 1 | SLSA 2 | SLSA 3 | FRSCA |
| 来源 - 版本控制 | ✓ | 利用GitHub或任何其他基于Git的存储库 | ||
| 来源--经过验证的历史 | ✓ | 由版本控制的存储库和身份管理器管理 | ||
| 来源--无限期保留 | 18个月。 | 保留在各种工件库、OCI注册处、透明度日志中 | ||
| 构建 - 脚本化构建 | ✓ | ✓ | ✓ | Tetkon Pipelines利用脚本任务。 |
| 构建--构建服务 | ✓ | ✓ | 泰康管线是一种构建服务。Kyverno确保任务使用的图像是经过签名的，并符合SLSA的出处。 | |
| 构建--以代码形式构建 | ✓ | Tekton Pipelines任务（由CUE政策强制执行）以yaml形式定义并存储在Git repo中。 | ||
| 构建--短暂的环境 | ✓ | Tekton Pipelines 利用短暂的容器来执行其任务。 | ||
| 构建--孤立的 | ✓ | 可将 Tekton Pipelines 配置为利用孤立的容器来执行任务。 | ||
| 证据 - 可用 | ✓ | ✓ | ✓ | Tekton Chains 可为 Tekton Pipelines 创建的工件生成并存储出处。 |
| 证明--已认证 | ✓ | ✓ | Tekton Chains 对其生成的图像和证明文件进行签名。 | |
| 证明--服务生成 | ✓ | Tekton Chains 自动生成证明。 | ||
| 证明--不可伪造 | ✓ | Tekton + SPIRE 共同工作，确保构建系统的不可伪造性。 |
从表中可以看出，通过FRSCA集成的工具可以共同满足各种要求。FRSCA资源库包含各种例子，可以运行显示所有工具一起实例化（通过CUE配置），并创建一个图像和证明，可以通过Cosign验证。
受监管的环境接受起来很慢
受监管的行业，如金融机构或政府/国防机构，需要非常认真地对待软件供应链的风险。如果他们受到这种攻击，他们的损失最大（这一点在Solarwinds和Log4J事件中很明显，该事件在业界引起了巨大的轰动）。攻击媒介和易受攻击的可能性非常高，不容忽视，但似乎网络安全总是被视为一种阻碍或事后考虑。组织的高级成员必须在问题的严重性上得到教育，否则会使他们的组织陷入瘫痪。虽然最近的事件和政府的授权让一些组织睁开了眼睛，但其他组织似乎对继续保持现状而沾沾自喜。
供应链安全不是取代传统安全和持续监控的东西，而是必须实施，以确保正在生产和摄入的软件工件的安全。FRSCA的目的是提供一个可以在组织内快速实例化的架构，帮助他们满足SLSA提出的要求。在进展缓慢的受管制行业，这可能说起来容易做起来难，但仍然需要采取措施尽快开始这个旅程。开源社区可以提供指导方针和工具，以确保受管制行业的软件供应链的安全，但最终还是要由各行业来决定他们的道路。
