现代软件开发实践使得软件供应链的安全比以往任何时候都更加重要。我们的代码依赖于开源库，而开源库依赖于其他库(一系列我们没有开发、没有编译、几乎不知道或根本不知道它来自何处的代码)。
其中一些代码几乎无处不在。在整个行业造成严重破坏的Log4Shell漏洞是由常见Java日志记录组件log4j中的一个旧bug引起的。我们正在建设一个不是站在巨人的肩膀上的行业，而是站在少数应用程序和组件维护者的肩膀上的行业，这些应用程序和组件维护者让我们的全球基础设施在业余时间工作，并出于他们内心的善良。
分布式开发增加了风险
这并不是为了减少维护人员所做的工作;它们是现代软件供应链的重要组成部分，提供从小型模块到整个基于容器的平台的一切。由于代码的重要性，他们的价值被低估，薪酬也被低估。可悲的是，有好几次坏角色主动提出接管代码维护工作，却加入了恶意软件，希望代码能够自动安装，因为它有一段值得信赖的历史。
随着我们的代码越来越多地成为团队的一部分，我们可以期望看到更多类似这样的攻击。我们如何保护自己和应用程序?首先也是最重要的是，我们需要了解软件供应链确实存在，我们不是孤立地构建代码，而且我们已经很久没有这样做了，如果我们曾经这样做过的话。开源和第三方库是我们如何制作软件的一个重要部分，它们只会变得更加重要。
我们可以采取哪些步骤来确保软件供应链的安全?在提供管理软件材料清单的工具方面已经做了大量的工作：扫描库的代码，使用静态和动态分析，向代码中添加数字签名和散列，并将其全部纳入托管存储库。但有一个方面还不清楚：我们如何验证这项工作以及我们正在使用的代码?毕竟，古老的安全格言之一仍然是“信任但要验证”。
确保软件供应链的安全
我们需要信任我们使用的代码，但我们也需要验证它是否可信。我们还需要在时间紧迫的情况下完成这项工作，随着存储库中的代码发生变化，云本机代码将发布新的构建。现代开发的自动化本质在这里是关键，像GitHub这样的平台是我们软件生命周期的核心，提供持续集成和持续交付(CI/CD)。
当我们使用像Kubernetes这样的技术时，事情会变得更加复杂，Kubernetes的设计是基于微服务架构和容器的混合匹配理念。虽然我们的代码可以在独立的容器中运行，但它在嵌套的抽象用户区中运行，每个dockerfile收集一系列依赖项，其中许多依赖项没有完整的文档记录。我们如何才能相信我们使用的容器中的物料清单?
推荐白皮书：
介绍：一个工件验证工作流微软的云本机开源团队一直在研究一个新的规范，该规范将有助于解决这一问题。Approval是一个验证框架，它支持Kubernetes应用程序中的各种工件。它使用一组受信任的安全元数据和已签名的物料清单来确保您部署的所有内容都是您希望部署的内容。
图像和其他组件利用公证人V2签名和验证工具以及ORAS(OCI注册表作为存储)工件规范。ORAS是OpenContainerInitiative注册表定义的一部分，它扩展到存储任何东西，而不仅仅是容器。它作为一种整理软件材料清单的方式工作得很好。有趣的是，Bindle分布式应用程序安装程序定义和ORAS清单之间存在共性，这使得从SBOM到经过验证的分布式应用程序安装程序变得简单。两者一起提供了一个供应链图，该图可以被解析并用作Kubernetes集群内验证方案的一部分。
将这些概念捆绑在一起，添加一个工作流引擎，将策略应用于软件物料清单，验证代码及其依赖关系中的许多不同供应链。它的核心是一个协调器，负责跨容器映像管理策略工作流。它是可扩展的，因此它可以跨公共和私有注册中心工作，使用与Kubernetes中使用的插件模型类似的熟悉插件模型。
政策推动的批准
Proparly使用的策略模型基于熟悉的工具，提供了一种使用您自己的配置以及使用Open policy Agent构建的更复杂的策略快速推出基本策略的方法。它还将在应用程序开发生命周期的不同阶段工作，插入CI/CD系统以在构建时验证工件，并插入Kubernetes以确保代码在构建和运行之间不会发生更改。重要的是要有一个在堆栈中工作的验证模式，确保避免在构建、存储库和注册中心以及运行时发生在代码上的供应链攻击。
让一个工具在整个软件生命周期中处理验证非常重要，因为它确保您只需要编写一次策略。针对不同场景的不同工具增加了策略中转录和翻译错误的风险;使用单一工具和单一策略格式有助于避免这种风险。您还可以拥有一个外部策略测试工具，该工具可以帮助您在交付代码之前调查“假设是什么”。
构建您的第一个策略
Approval团队在他们的GitHub存储库中有一些演示代码，展示了如何在Kubernetes中将Approval与Gatekeeper一起使用。使用Helm图表进行安装，并附带一些示例配置模板。您可以使用这些来测试这些操作，例如，阻止所有没有签名的图像。Gatekeeper将拒绝任何未签名的容器映像，阻止它们运行。
策略文件是用YAML编写的，因此您可以在Visual Studio代码或其他工具中编辑它们，并利用代码格式化工具。它们构建成一个简单的规则引擎，通过验证逐步生成工件。它们是否来自核准登记处?您是否多次检查一个工件以获得不同的签名?您自己的私有注册表中的工件是否比公共注册表中的工件更可信?当您运行多个检查时，您的所有验证引擎都同意吗?事实证明，运行时验证的规则很容易定义，但对于运行在CI/CD系统中的运行时验证来说，这种情况不太可能发生，因为在CI/CD系统中，您需要确定许多不同工件的状态以及来自许多不同信任根的签名。
Approval目前是一个有趣的初始建议，它提供了一套工具，可以管理软件BOM表中的所有元素。虽然它不能防止零天影响长时间隐藏的bug，但它可以快速确定哪些代码受到影响，创建规则以防止其被使用和运行。
随着供应链风险成为人们关注的焦点，行业必须仔细研究这样的提案，并在公共场所开展工作。很高兴看到微软已经承诺与云计算计算基金会共享批准，在那里它应该得到它需要的更广泛的Kubernetes开发社区的审查。
参考文章：
https://docs.ceph.com/en/latest/dev/cephfs-snapshots
https://knowledgebase.45drives.com/kb/kb450160-cephfs-snapshots/
