7.5 CNCF的安全软件工厂参考架构

  对许多人来说，将软件生产与工厂这一术语联系起来可能看起来有些奇怪。大多数人仍将工厂与收集、处理和制造物理材料如钢铁、汽车或消费电子产品联系在一起。然而，讽刺的是，现代大多数工厂环境的运作依赖软件，而软件的生产方式越来越具有与工厂类似之处。术语“软件工厂”通常指为了以高效、可重复和安全的方式生产软件而必需的工具、资源和流程的集合。
  这个术语在公共和私营部门都得到了广泛应用，并且得到了包括MITRE和VMware在内的组织的认可。美国国防部（DoD）拥有29个软件工厂的强大生态系统，其中最著名的包括Kessel Run、Platform One和陆军软件工厂。软件工厂的概念也正在扩展到美国联邦民用机构，例如医疗保险与医疗补助中心（CMS）的batCAVE项目。这个术语还得到了行业领先组织如CNCF的认可，他们发布了他们的安全软件工厂参考架构。让我们来更详细地了解一下。

安全软件工厂参考架构

  CNCF定义软件供应链为“在编写、测试、打包和分发应用软件给最终消费者时执行的一系列步骤。” 软件工厂是在总体上促进软件交付的逻辑构造，在正确实施时确保安全性是应用交付过程的关键组成部分。
  CNCF安全软件工厂（SSF）参考架构（链接：https://github.com/cncf/tag-security/blob/main/supply-chain-security/securesoftware-factory/Secure_Software_Factory_Whitepaper.pdf）建立在先前的CNCF出版物基础上，如云原生安全最佳实践（链接：https://github.com/cncf/tag-security/tree/main/security-whitepaper）和软件供应链最佳实践（链接：https://github.com/cncf/tag-security/blob/main/supply-chain-security/supply-chain-security-paper/CNCF_SSCP_v1.pdf）。该参考架构强调现有的开源工具，重点放在安全性上。它还围绕着《软件供应链最佳实践》白皮书中的四个总体原则展开：

• 深度防御
• 签名和验证
• 制品元数据分析
• 自动化

  每个原则都是确保从软件的起源和代码到生产环境安全交付的必要条件。
  该参考架构还明确指出，它并不专注于像代码扫描和签名这样的关注点，而是更深入地关注代码来源和构建活动。这种关注的理由在于，下游活动，如静态应用安全测试/动态应用安全测试（SAST/DAST），依赖于验证来源以及您从中接收某些内容的方当的身份是否是受信任的实体。这些身份可以是与人类用户相关联的身份，也可以是与机器身份相关联的身份。签名的结合以及验证其来自可信源的事实对于保证来源的可靠性至关重要。
  安全软件工厂（SSF）中的每个实体都有依赖关系，无论这些依赖关系是与更广泛的组织IAM系统相关、源代码管理相关，还是下游消费者依赖于SSF本身来证明和签名他们正在使用的制品。
  SSF具有多个组件，其中一些被认为是核心组件、管理组件和分发组件。核心组件负责接收输入并使用它们来创建输出制品。管理组件专注于确保SSF与您的策略保持一致运行。最后，分发组件将工厂的产品安全地移动到下游进行消费。

核心组件

  这些核心组件包括您的调度和编排平台、流水线框架与工具，以及构建环境。所有SSF组件都使用平台及其相关的编排来执行它们的活动。流水线及其相关工具能够促进构建软件制品的工作流程。指南强调，流水线应该符合与您的工作负载相同的要求。这旨在指出流水线是您攻击面的一部分，并且可以被利用来影响下游消费者，就像SolarWinds事件中的情况一样。这种强调也得到了像SLSA等新兴框架的支持。
  最后，您有构建环境，这是将您的源代码转换为机器可读软件产品（称为制品）的地方。成熟的构建环境正在努力提供关于构建过程中使用的输入、操作和工具的自动证明，以验证构建过程及相关输出/制品的完整性。
  像TestifySec（www.testifysec.com）这样的组织正在进行创新，以确保组织能够检测流程篡改或构建受损。一个显著的例子是Witness项目，旨在防止构建材料的篡改，并验证从源到目标的构建过程的完整性（链接：https://github.com/testifysec/witness）。

管理组件

  管理组件包括策略管理框架、证明者和观察者。在SSF的背景下，您的策略管理框架是帮助编码组织和安全需求的核心，例如IAM（身份和访问管理）、分配的工作节点和授权的容器镜像。由于不同的风险容忍度和多种适用的监管框架，这些策略在每个组织中可能会有所不同。随着零信任模型的推广，策略管理框架尤为关键。
  确定谁有权做什么及在何种上下文中进行是执行零信任原则（如最低权限访问控制）的关键。您不希望部署由未经授权的个人推送的容器，甚至不希望使用您不信任或未经您信任来源签名的容器等。鉴于云原生环境通常意味着您使用容器和像Kubernetes这样的编排器，您将拥有节点证明者、工作负载证明者和流水线观察者等实体。它们验证节点和工作负载的身份和真实性，以及与流水线过程相关的可验证元数据。

分发组件

  在SSF中识别的关键组件中，还包括分发组件，包括制品库和准入控制器。您的流水线过程的输出产生制品，这些制品存储在您的制品库中。这些制品可以包括容器镜像、Kubernetes清单、SBOM（软件供应链安全性清单）以及相关签名。越来越多地，我们看到使用诸如Sigstore之类的解决方案来签署不仅仅是代码，还有SBOM和证明。这在之前讨论过的Linux Foundation/OpenSSF开源软件安全动员计划中得到了强调（链接：www.csoonline.com/article/3661631/the-open-source-software-security-mobilization-plan-takeaways-for-security-leaders.html）。在制品库之后，您有准入控制器，负责确保只有授权的工作负载可以由调度和编排组件运行。这些控制器可以执行策略，例如允许哪些来源进入构建，允许哪些组件进入节点主机，并且使用的组件是可信且可验证的。

变量和功能

  SSF指南理解到，SSF的输入和输出会有所不同。输入包括源代码、软件依赖、用户凭据、加密材料和流水线定义等。输出包括软件制品、公共签名密钥和元数据文档等。白皮书还讨论了SSF的功能，例如项目在SSF中的流动过程，最终提供经验证和具有一定保证水平的安全输出和制品，以建立与下游消费者的信任关系。

小结

  初看起来，SSF参考架构似乎很复杂，而实际上确实如此。在现代云原生环境中交付软件涉及许多组成部分和相关流程，以确保所消耗和生产的内容能够以符合组织风险容忍度的保证水平完成。
  这种复杂性还强调了将所有要素整合在一起的挑战性，以及系统中可能存在的错误和配置错误的机会，这些可能会对整个生态系统中的消费者产生连锁反应的影响，而现代经济中的所有这些都由软件驱动。人们常说，防御者必须始终正确，而恶意行为者只需一次正确。在充满人员挑战和认知负荷的复杂云原生环境中，这就像在一堆针中寻找特定的针，而不是在一堆草垛中寻找。