作者：Jim Bugwadia
客座文章最初发表在Nirmata 博客[1]上
软件供应链攻击的急剧增加，使得保护软件的构建和交付成为个至关重要的话题。但是这对于 Kubernetes DevOps 团队来说意味着什么呢？他们的任务是保护他们的持续交付流水线和集群。要开始保护 Kubernetes 供应链，需要考虑四件事情：Artifacts（工件）、Metadata（元数据）、Attestations（证明）和 Policies（策略）（A-MAP）。让我们开始吧！
Photo by Annie Spratt on Unsplash
在之前的一篇文章[2]中，Dan Lorenc（Chainguard 创始人/CEO）和我讨论了容器镜像签名和验证。
虽然签名是保护软件供应链的良好开端，但对于新兴标准如SLSA（发音“Salsa”，Supply Chain Levels for Software Artifacts）[3]所要求的更高级别的安全性来说，这还不够。签名并没有告诉我们软件是如何以及在哪里构建的，以及它是由什么组成的。
软件构建系统产生工件和元数据。验证构建完整性和软件组件安全属性需要证明和策略。在安全的软件供应链中，每一项都扮演着重要的角色。
A-MAP：软件供应链安全的四个要素
工件
软件构建产生用于安装和执行的工件。工件的类型和格式因软件而异。它们可以是包、WAR 文件、容器镜像或其他格式。
元数据
元数据是描述软件工件的数据。软件供应链安全应该考虑三种类型的元数据：
起源数据
起源（Provenance）是指原产地。对于软件系统，起源数据是关于产生它的构建系统的信息。这包括机器标识、构建软件和过程信息、CI/CD 工具信息，以及在验证构建环境时有用的任何其他细节。
虽然不存在起源数据的标准，但 CNCF 的个in-toto[4]项目，提供了一套软件供应链安全的工具和规范，允许自定义谓词类型[5]，可用于表示起源数据。我们将在后面的章节中更详细地讨论 in-toto 证明。
软件材料清单（SBOM）
SBOM（Software Bill of Material）是软件包含的成分（即其他软件包和库）的列表。SBOM 有两种主要格式：CycloneDX[6]和SPDX[7]。
NTIA（National Institute of Telecommunications and Information Administration）发布了一份指南[8]，对现有的 SBOM 格式和标准进行了调查，比较了这些标准以及SWID[9]（软件识别标签， Software Identification Tag），后者虽然不是一个完整的 SBOM，但提供了一种识别软件组件的标准方法。
漏洞扫描报告
漏洞扫描识别已知的安全问题，是保护软件系统的主要步骤。扫描应该在软件交付生命周期中尽早执行。当检测到新的或未解决的漏洞时，软件构建应该会失败。
然而，并不是所有的漏洞都能够或者必须被修复，因此，熟悉软件的人必须检查漏洞并批准允许的漏洞。VEX[10]（漏洞可利用性交换，Vulnerability Exploitability Exchange）格式通常与 SBOM 一起使用，以提供已知漏洞如何影响软件组件的评估。
虽然大多数其他元数据是不可变的（immutable），但是漏洞扫描报告应该定期刷新，因为在软件系统发货后可以报告新的漏洞。
除了来源数据、SBOM 和漏洞扫描报告之外，还可以创建其他类型的元数据，如 SAST 和代码审查报告，以满足组织和法规遵从性的要求。
证明
元数据提供了有用的信息，但是如何信任元数据本身呢？在实际审计中，独立审计员审查信息并生成报告，以证明信息的准确性和可靠性。类似地，在软件供应链中，证明是由受信任的人或系统产生的签名元数据。在安全的软件供应链中，构建系统签署元数据，如起源数据、漏洞扫描报告和 SBOM，以生成证明。
代码和镜像签名可以是一种基本的证明。对软件包或容器镜像进行签名仅仅意味着某个可信实体证明了它的完整性。但是，签名并不为消费者提供任何额外的保证。因此，对可用于检查和验证软件信息的元数据进行签名更有意义。消费者可以使用这些证明来建立对软件系统的信任。
in-toto 项目已经为证明定义了一种标准格式[11]，虽然仍在开发中，但它正获迅速采用，作为一种表示经过验证的元数据的方式。
像sigstore Cosign[12]这样的工具可以签署 in-toto 谓词，并将它们作为证明附加到容器镜像上。而且，像 Kyverno 这样的策略引擎可以用来验证这些证明。
策略
工件、元数据和证明是由构建系统产生的。但是消费者应该如何使用这些信息并为他们的组织实施软件供应链安全呢？
策略，是这个问题的答案，也是安全软件供应链的最后一步。策略有助于自动化和解决验证构建信息（如证明）的挑战。
例如，镜像验证策略可以声明组织对部署到其生产环境中的任何镜像的要求。这里有一个例子：
- 所有镜像都必须包含以下 in-toto 证明格式的证明：
- 起源数据
- 漏洞扫描报告
- SBOM
- 漏洞扫描报告应该是 VEX 格式。
- 漏洞扫描报告应该每天更新。
- 不允许存在高严重性漏洞。
- SBOM 应采用 CycloneDX 或 SPDX 格式。
策略应该在部署之前实施，并通过运行时扫描定期实施。
像 Kubernetes 这样的云原生系统是可扩展的，并提供准入控制[13]的概念，以允许在将组件部署到集群之前对其进行验证。像Kyverno[14]这样的 Kubernetes 策略引擎提供了灵活的策略格式，可以在部署之前和运行时通过连续扫描来验证镜像和配置。
总结
在这篇文章中，我介绍了 Kubernetes DevOps 团队理解软件供应链安全性所需的四个要素：
- 工件：构建系统产生各种安装或执行软件的工件。
- 元数据：元数据用于描述软件和构建环境。起源数据、SBOM 和漏洞扫描报告是评估软件安全风险所需的基本元数据集合。
- 证明：经过验证的元数据用于证明软件系统的完整性。自定义和标准化元数据都可以转换为证明。
- 策略：策略检查并执行组织标准。策略应该在部署之前通过运行时扫描自动实施。
现代构建系统和 CI/CD 系统提供了可定制的工作流，可以集成工具来生成基于标准的证明。Kubernetes 等云原生系统及其项目和工具生态系统提供了策略引擎来验证证明和加强软件供应链安全性。
签署工件是一种证明，也是保护软件供应链的良好开端。但是，签名本身并不能提供足够的信息来验证和实施软件组件的安全级别。
使用 in-toto 证明格式的标准化证明允许 CI/CD 系统生成元数据，允许 Cosign 等工具创建证明，允许 Kyverno 等策略引擎在运行时验证证明。
作为后续文章，我将提供一个完整的例子，说明如何为 Kubernetes 实现安全的软件供应链，实现这些概念。
参与 Kyverno 项目
Kyverno 拥有 2000 多个 GitHub 星星和 1.5 亿次下载，是一个 CNCF 项目，也是为 Kubernetes 设计的策略引擎。使用 Kyverno，策略作为 Kubernetes 资源进行管理，不需要新的语言。这允许使用熟悉的工具，如 kubectl、git 和 kustomize 来管理策略。Kyverno 策略可以验证、变异和生成 Kubernetes 资源，并通过集成 Sigstore Cosign 和 in-toto 认证来确保 OCI 镜像供应链的安全性。如果你想了解更多关于 Kyverno 的信息，可以加入我们的slack 频道[15]，关注我们的GitHub 仓库[16]，保持更新。
在 Nirmata，我们正在为 Kubernetes 策略管理构建全面的解决方案，包括供应链安全。我们将继续在这里更新重要 DevSecOps 主题的读者和社区。如果你有任何具体问题，请随时联系我们[17]，或者注册 Nirmata Kubernetes 策略管理器的免费试用版[18]，并开始使用。
参考资料
[1]Nirmata 博客: https://nirmata.com/2022/03/15/a-map-for-kubernetes-supply-chain-security/
[2]之前的一篇文章: https://nirmata.com/2021/08/12/kubernetes-supply-chain-policy-management-with-cosign-and-kyverno/,
[3]SLSA（发音“Salsa”，Supply Chain Levels for Software Artifacts）: https://slsa.dev/
[4]in-toto: https://in-toto.io/
[5]自定义谓词类型: https://github.com/in-toto/attestation
[6]CycloneDX: https://cyclonedx.org/
[7]SPDX: https://spdx.dev/
[8]指南: https://www.ntia.gov/files/ntia/publications/sbom_formats_survey-version-2021.pdf
[9]SWID: https://nvd.nist.gov/products/swid
[10]VEX: https://www.ntia.gov/files/ntia/publications/vex_one-page_summary.pdf
[11]标准格式: https://github.com/in-toto/attestation#in-toto-attestations
[12]sigstore Cosign: https://github.com/sigstore/cosign#readme
[13]准入控制: https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/
[14]Kyverno: https://kyverno.io
[15]slack 频道: https://slack.k8s.io/
[16]GitHub 仓库: https://github.com/kyverno/kyverno/
[17]联系我们: https://nirmata.com/contact-us/
[18]注册 Nirmata Kubernetes 策略管理器的免费试用版: https://www.nirmata.io/security/signup.html?referrer=website&product=NPMK
CNCF (Cloud Native Computing Foundation)成立于2015年12月，隶属于Linux Foundation，是非营利性组织。
CNCF（云原生计算基金会）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。
