第六章 云和容器化

虽然在传统的本地基础架构中追求软件物料清单 （SBOM） 和软件透明度具有挑战性，但在使用云服务和云原生架构时，挑战就大不相同了。在本章中，我们将讨论围绕云和容器化增长的一些指标，以及云计算背景下的软件透明度和供应链安全问题。 在讨论技术时，拥有一个共享的词汇表通常会有所帮助。话虽如此，云计算最常用的定义来自 NIST 800-145 (https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf)，其中指出： 云计算是一种模型，用于实现对可配置计算资源（例如网络、服务器、存储、应用程序和服务）共享池的无处不在、便捷、按需的网络访问，这些资源可以快速配置和发布，且管理工作或服务提供商交互最少。此云模型由五个基本特征、三个服务模型和四个部署模型组成。 进一步扩展，这些特征包括按需自助服务、广泛的网络访问、资源池、快速弹性和可衡量的服务。云还具有三种服务模式：基础设施即服务 (IaaS)、平台即服务 (PaaS) 和软件即服务 (SaaS)。每种服务模式都有自己独特的共享责任模式，以及对软件如何到达下游消费者的相关影响。云计算有四种主要部署模式：私有云、社区云、公共云和混合云，每种模式都对多租户和安全等主题有影响。 与云计算相关的每一种独特模型仍然以某种形式涉及软件，并要求下游消费者对他们所消费的服务和相关软件的安全性有一定程度的保证。

6.1 共担责任模型

如果不涉及共享责任模型 (SRM)，关于云的安全性和风险的讨论就不完整。许多企业领导者仍然会问“云安全吗？”，这是一个错误的问题。更合适的问题是“作为安全团队和组织，我们是否确保了我们在云消费中的份额？”

绝大多数云数据泄露和泄漏都是由于客户造成的，IT 研究和咨询公司 Gartner 预测，到 2025 年，大约 99% 的云安全故障将是客户的错误 (www.gartner.com/smarterwithgartner/is-the-cloud-secure)。因此，所有安全从业人员都必须了解自己的责任.

共担责任模型的细分

SRM 描述了您（云客户）负责什么以及您的云服务提供商 (CSP) 负责什么。在 IaaS 模型中，CSP 负责云的安全性 — 比如物理设施、公用设施、电缆、硬件等。客户负责云的安全性 — 即网络控制、身份和访问管理、应用程序配置和数据安全。

共担责任模式的职责

也就是说，这种责任划分可能会根据您使用的服务模型而改变。从基本层面上讲，NIST 对云计算的定义解释了三种主要的云服务模型：

■ 基础设施即服务 (IaaS)：在 IaaS 模型下，CSP 负责物理数据中心、物理网络和物理服务器/托管
■ 平台即服务 (PaaS)：在 PaaS 模型中，CSP 承担更多责任，例如修补（客户过去在这方面做得很差，并且是导致安全事件的主要途径）和维护操作系统。
■ 软件即服务 (SaaS)：在 SaaS 中，客户只能在应用程序的配置设置中进行更改，其他所有控制权都留给 CSP。（Gmail 是一个基本示例。）值得注意的是，即使在 SaaS 环境中，在 SaaS 治理和安全方面也有很多工作要做，我们将在本章后面深入讨论。

每种方式都有其代价，客户放弃控制权，以换取更多的交钥匙管理体验，而 CSP 则处理更多的运营活动，让客户专注于自己的核心竞争力。许多组织发现这种模式很有吸引力，因为管理计算和基础设施通常不是他们的核心业务，而是他们为提供核心服务和产品而必须执行的活动。

每个 CSP 都有不同版本的 SRM。图 6.1 是 Microsoft Azure SRM 的一个示例（https://docs.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility）

虽然 SRM 涉及合同和财务影响等非安全问题，但它也包括一些安全考虑因素。安全从业人员必须根据他们所使用的服务以及组织的实施和架构了解他们在 SRM 中的责任。

还记得几乎所有云数据事件都发生在 SRM 的客户端吗？这是了解 SRM 并确保您正在履行模型职责的主要原因。另一件我们再怎么强调也不为过的是，虽然可能存在责任分担，但您不能将责任外包。作为一个组织，您最终仍然是数据所有者，并对这些数据及其所属的利益相关者负责，即使您决定在向客户或利益相关者提供服务和业务时使用第三方（例如 CSP）。虽然涉及客户数据泄露的 CSP 可能会产生合同后果，但客户将承受声誉、品牌和监管后果方面的后果。

您的职责取决于您拥有两种主要安全角色中的哪一种：技术安全从业者或安全主管。技术安全从业者（例如云安全工程师或云安全架构师）必须了解您的组织使用哪些云服务；如何安全地构建这些解决方案；以及哪些配置、设置和控制属于您的职权范围，您可以影响这些配置、设置和控制并实现更强大的安全态势。一个明显的例子是，云原生供应商 SysDig 在其 2023 年的“云原生安全和使用情况报告”中发现，云环境中 90% 的授予权限未被使用。这与行业对零信任的推动相矛盾，并为攻击者滥用受损帐户留下了很多机会（https://sysdig.com/press-releases/sysdig-2023-usage-report）。

技术安全专业人员应该非常熟悉其组织使用的平台和服务，并了解如何安全地实施它们。云安全工程师/架构师经常与工程和开发团队合作。如果您无法引导他们找到安全的解决方案或发现有风险的配置（请记住，这些配置是大多数云数据事件的根源），您的组织可能会面临巨大的风险。

向您的 CSP 寻求安全资源。例如，Amazon Web Services (AWS) 提供了一个令人难以置信的安全文档数据库，按类别（例如，计算、存储、安全、身份和合规性）细分，您可以在其中找到与您的组织使用的每项服务相关的具体信息。这包括广泛的信息，从如何安全地配置服务，到您可以操作哪些配置，再到故障排除指南。

安全主管需要考虑的关键因素包括清点服务使用情况（你必须知道组织内正在使用什么，否则你就无法保护它）、确保所使用的服务符合适用的监管框架，以及了解合同/法律方面的问题，如 CSP 服务级别协议 (SLA)，尤其是涉及事件响应计划等方面的问题。其中一位作者贡献的一种资源是云安全联盟的云事件响应框架 （https:// cloudsecurityalliance.org/artifacts/cloud-incident-response-framework）。

许多组织与 CSP 建立合作伙伴关系并分担责任。这包括确保您使用的服务符合您必须遵守的监管框架。超大规模 CSP 使这些信息易于查找，AWS 和 Microsoft Azure 提供了“范围内的服务”页面，您可以在其中确定哪些服务符合哪些框架，哪些服务仍在审批流程中或尚未评估和评估。这有助于确保您的团队不仅在云中构建强大且安全的架构和工作负载，而且还使用符合适用框架的服务，以避免合规性或法规问题，并使用他们有保证的服务。

各级安全从业人员都应努力在其云环境中实施安全标准和最佳实践。这可能意味着从各自的 CSP 实施安全最佳实践，或者为各自的云环境实施诸如 Internet 安全中心 （CIS） 基准测试之类的内容（www.cisecurity.org/blog/ foundational-cloud-security-with-cis-benchmarks）。

处理 SRM 时的一个基本工件是客户责任矩阵 （CRM），它列出了 CSP 提供哪些控制以及哪些责任留给云消费者。查找 CRM 模板并了解有关它们的更多信息的一个地方是联邦风险和授权管理计划 （FedRAMP）。FedRAMP 是一个程序，用于处理美国联邦政府 （www.fedramp.gov/updated-Control-implementation-summarycis-and-customer-responsibility-matrix-crm-templates） 使用的云服务产品/服务的授权。

CRM是安全从业人员使用的关键工具。在 SRM 中，安全控制完全由 CSP 提供，混合控制（责任由云客户承担），或完全留给客户。安全从业人员可以利用CRM来清楚地了解这种安全控制描述。这些通常分别是指完全、部分或不可继承的安全控制。

使用云服务可以将某些安全控制和活动的责任转移到 CSP，并让组织专注于其核心竞争力。它创造了一种责任关系，安全专业人员必须理解并适当地处理。请记住，大多数云数据泄露将发生在 SRM 的客户端，归根结底，您对组织的声誉负有全部责任，而 CSP 代表了另一个第三方提供商，在推动软件透明度和软件供应链安全方面必须考虑该提供商。

6.2 云原生安全的4C

将云原生生态系统情境化的一种有用方法是通过 Kubernetes 文档中描述的“云原生安全 4C”，此处讨论的图 6.2 中所示的容器编排器。

图6.2

在此特定于容器及其编排的上下文中，您拥有云、集群、容器和代码，每一层本质上都依赖于其上层（或之前层）的各种形式的基础设施和部署到其上的代码。

如前所述，云范式具有 NIST 定义的三种商定的服务模型。云消费的主要方法之一是 IaaS，组织利用 CSP 的物理设施、实用程序、人员和基础设施来部署操作系统和应用程序。在这种模式中，CSP 负责底层基础设施、公用事业、设施、人员和一般资本支出 （CapEx） 成本。领先的 CSP 为网络、计算和存储等关键领域的使用提供强大的云服务。然而，这些服务仍然由软件提供支持，就像大多数现代基础设施一样。这意味着它们仍然容易受到与软件相关的漏洞和漏洞的攻击。虽然云消费者是从 IaaS 模型中的底层基础设施中抽象出来的，但这并不意味着他们完全不受可能影响它的风险和威胁的影响。这正是 Log4j 漏洞中发生的情况。主要的 CSP（AWS （https://aws.amazon.com/security/ security-bulletins/AWS-2021-006）、Azure （https://msrc-blog.microsoft .com/2021/12/11/microsofts-response-to-cve-2021-44228-apache-log4j2） 和 Google Cloud （https://cloud.google.com/log4j2-security-advisory） 都发布了与 Log4j 对其云服务产品的影响相关的公告。

这些 CSP 与更广泛的 IT 行业非常相似，使用无数的开源库和组件来支持其多样化的云服务组合。从上述 CSP 的公告来看，这种单一的开源软件供应链妥协对其云原生服务组合产生了影响，而且并不止于此。这些 CSP 的收入高达数十亿美元，为数千个组织和数百万个人提供支持。当组织在这些 CSP 产品/服务之上构建和交付应用程序和服务时，基础服务产品中的软件供应链泄露或漏洞不仅会影响使用型组织，还会影响其业务合作伙伴、客户和利益相关者。对于前面提到的超大规模 CSP，这些客户甚至包括美国最关键和最敏感的工作负载，因为 CSP 由国防部 （DoD）、情报界和联邦民事行政部门 （FCEB） 机构等组织使用。

这一现实要求确保云客户正在使用的服务以及支持他们的相关软件。虽然已经制定了成熟的计划，例如 FedRAMP （www.fedramp.gov） 或 SOC2 （https://us.aicpa .org/interestareas/frc/assuranceadvisoryservices/aicpasoc2report），但他们传统上并没有从清点和了解为现代云原生服务产品提供支持的底层软件供应链以及与该软件相关的风险的角度来看待软件。这些计划着眼于更传统的风险评估方法，例如 CSP 策略和流程、基础计算实例的漏洞扫描结果以及渗透测试。随着软件供应链日益成为 IT 和网络安全领导者关注的焦点，我们可能会看到一种转变，即 FedRAMP 等授权计划开始要求 CSP 为其面向软件的托管服务产品提供 SBOM 等项目。美国联邦政府已经通过发布管理和预算办公室 （OMB） 备忘录 22-18 （www.whitehouse.gov/wp-content/uploads/2022/09/M-22-18.pdf） 表明了这一意图，该备忘录将让各机构可能要求工件，包括第三方软件生产商向联邦政府销售软件的 SBOM，其中当然包括云提供商。它还要求第三方软件供应商提供自我证明，证明他们遵循安全的软件开发实践，例如NIST的安全软件开发框架（SSDF）和其他NIST软件供应链安全指南。

然而，考虑到AWS、Azure和谷歌等超大规模CSP的广度和规模，这是具有挑战性的，他们无疑拥有大量的软件库存来支持他们的云服务产品。它也与目前的方法主要基于第三方评估组织 （3PAO），其中第三方评估服务提供商并提供与提供商的内部实践和安全流程相关的工件和证明。云和托管服务产品通常努力从消费者那里抽象出一些潜在的复杂性，以换取消费者体验和便利性。值得注意的是，在前面提到的 OMB 22-18 备忘录中，它允许软件生产者自我证明他们使用了安全开发实践。但是，如果机构认为有必要，它确实允许机构要求提供 3PAO。然而，考虑到当前的环境、工具和组织能力，如何为每个云服务大规模发挥作用是不切实际的。

虽然 IaaS 不可避免地涉及软件，但围绕软件供应链安全的对话在云原生架构的其他方面要成熟得多，例如容器、Kubernetes、代码和越来越多的 SaaS。

6.3 容器

云原生生态系统延续了物理服务器和虚拟机 （VM） 等传统计算模型，广泛使用容器。因此，当涉及到容器及其相关的编排系统（如 Kubernetes）时，我们必须讨论容器和相关的软件供应链问题。

随着计算抽象的成熟，我们已经看到了从虚拟机 （VM） 到容器的转变。根据行业领导者 Docker 的定义，容器是“打包代码及其所有依赖项的标准软件单元，因此应用程序可以快速可靠地从一个计算环境运行到另一个计算环境。容器比 VM 更轻量级、更动态、更可移植，后者需要每个 VM 都有一个来宾操作系统（参见图 6.3）。

图6.3

容器的主要好处之一是它们允许开发人员将他们的软件代码、相关库和依赖项打包到一个轻量级的工件中。此项目是可移植的，能够在支持基于容器的部署的各种托管环境和基础结构中运行。

虽然这种捆绑对可移植性和效率等活动非常有益，但它也为不安全或易受攻击的依赖项打开了大门，这些依赖项可以包含在容器中，然后大规模复制。这种情况也经常发生，在公共容器映像存储库（如 DockerHub、Google Container Registry 等）中，任何人都可以使用容器映像来使用和重用。

事实上，帕洛阿尔托的 Unit 42 威胁研究小组 2021 年的一项研究发现，在对 1,500 多个公开可用的容器映像的研究中，96% 的映像中存在已知漏洞，并且 91% 的映像至少存在一个严重或高度漏洞，具体取决于 CVSS 等来源的严重性评分（www.paloaltonetworks.com/content/dam/pan/en_US/assets/ pdf/reports/Unit_42/unit-42-cloud-threat-report-2h-2021.pdf）。

这项研究还指出，图像的依赖关系越多，平均而言，它就越有可能具有更高的漏洞计数。因此，诸如减少攻击面或将依赖项和代码的数量最小化到仅容器和应用程序运行所需的依赖项和代码数等工作被广泛认为是安全最佳实践。

与其他形式的应用程序和软件交付非常相似，部署容器也保证了透明度。通过对容器使用 SBOM，您可以查看容器映像中的每个项目，这有助于识别软件供应链中的漏洞并在整个软件开发生命周期中进行修复。这包括从源、生成、暂存、部署和运行时阶段。漏洞可以在整个开发周期的任何阶段引入，因此在整个过程和阶段生成 SBOM 可以允许在整个生命周期中查看映像以及引入风险的任何更改。

尽管易受攻击的图像普遍存在，但创新工具正在出现，以帮助提供容器及其所需的软件组件和依赖项的透明度。Anchore 等领先供应商已经开发了允许组织生成 SBOM 的 OSS 工具。Anchore 的 SBOM 工具被称为 Syft，拥有一组强大的功能和语言支持。功能包括为容器映像、文件系统等生成 SBOM;支持开放容器计划 （OCI） 和 Docker 映像格式;以及使用 in-toto 框架支持已签名的 SBOM 证明的能力。（证明是我们将在本书的其他领域讨论的一个概念，例如第 11 章“消费者实用指南”。

Syft 支持领先的 SBOM 格式，如 CycloneDX 和 SPDX，如第 4 章“软件物料清单的兴起”中所述。另一个广受欢迎的 OSS 扫描仪是 Trivy，来自 Aqua Security 的团队。它支持以容器映像、文件系统、Git 存储库和 Kubernetes 资源为目标，以识别 CVE、OS 包和依赖项，以支持 SBOM 和声明性基础结构即代码中的错误配置。

容器领导者 Docker 甚至添加了原生 SBOM 功能。2022 年初，Docker 宣布能够简单地从 Docker Desktop 的 CLI 运行 docker sbom 并为任何 Docker 映像生成 SBOM （www.docker .com/blog/announcing-docker-sbom-a-step-towards-more-visibility-intodocker-images）。此功能是在开源社区和 Anchore 团队的协作下开发的，使用我们之前讨论过的 Syft 项目。Docker 团队解释说，这个附加功能旨在提高对供应链的信任，以查看映像中包含的内容，并使开发人员轻松完成该过程，以免妨碍生产力或速度。

从软件供应链的角度来看，容器及其相关生态系统存在广泛的潜在攻击媒介和需要考虑的风险。虽然很难列举每个攻击媒介，但我们肯定会在这里看到一些主要的攻击媒介，包括基础镜像、操作系统、Git 存储库、应用程序代码和依赖项以及 OSS 组件。由于云原生环境中涉及开发、安全和运营的团队数量众多，再加上保护容器的各种安全层，容器安全也变得更加复杂。这些涉及容器映像及其包含的软件、容器和主机操作系统之间的交互，以及在编排平台上运行的其他容器。此外，还存在与容器网络和存储以及容器在生产环境中部署到的运行时环境相关的攻击媒介和风险，该环境通常位于 Kubernetes 集群之上。

在讨论基础映像时，就像软件供应链中的任何上游组件一样，所有下游消费者和用户都可能受到供应链上游引入的风险的影响。基础映像是容器软件供应链中的关键步骤，因为在容器上运行的软件应用程序会继承构建应用程序的基础映像中包含的任何安全债务和漏洞。多个容器安全指南来源推荐的一个关键最佳做法是使用强化的基础映像。通常，这意味着基础映像已经过强化以减少漏洞，并且还被剥离为仅包含功能所需的基本要素。这通常称为攻击面减少，即删除不必要的组件，这些组件可以被利用来破坏容器及其上的应用程序。一些最受欢迎的基础映像包括 Alpine、Ubuntu 和 Debian。

在最小化容器攻击面的推动力中，出现了所谓的“无发行版”容器映像。无发行版容器映像仅包含应用程序及其运行时依赖项，从而删除了通常伴随常见 Linux 发行版的组件，例如包管理器、shell 或其他程序。NIST等来源在其“应用程序容器安全指南”（https://csrc.nist.gov/publications/detail/sp/800-190/final）以及行业领导者（如Liz Rice）的《容器安全》（O'Reilly Media，2020）一书中经常将最小化容器的攻击面作为最佳实践，该书讨论了减少攻击面以及其他容器安全建议。除了减少攻击面之外，无发行版图像还具有多种好处，例如最大限度地减少由于虚假 CVE 引起的扫描程序噪音、减少出处负担以及在大小方面更有效率，正如 Google 的容器工具无发行版 GitHub 页面 （https://github.com/ GoogleContainerTools/distroless） 中所引用的那样。

软件供应链安全初创公司 Chainguard 推出了 Wolfi，这是一套无发行版映像，在 CVE 方面比大多数传统容器映像 （www.chainguard.dev/unchained/introducingwolfi-the-first-linux-un-distro） 更安全。Chainguard 还开始引入对内存安全容器镜像的追求，这与 NSA 等来源关于将行业转向更安全的内存安全语言和生态系统的更广泛建议一致。

与其他 OSS 组件非常相似，组织通常从开放的 Internet 获取容器映像，当涉及到容器时，最受欢迎的来源之一是 Docker Hub （https://hub.docker.com）。顾名思义，Docker Hub 由 Docker 运行，用于查找容器映像并与团队和组织共享。为了正确看待 Docker Hub 及其托管的相关映像的受欢迎程度，在撰写本文时，该站点上有 20 张映像已被下载至少 10 亿次。也就是说，与任何其他软件组件一样，这些容器映像在映像文件中通常存在多个漏洞，组织可以通过在使用它们之前不进行尽职调查来继承这些漏洞和技术债务。如前所述，研究已经确定，Docker Hub 上公开提供的映像中，超过 90% 包含已知漏洞，其中极高比例的映像包含至少一个严重或高漏洞。再加上数十亿的下载量，您可以想象有多少易受攻击的容器在世界各地的企业环境中运行。

软件供应链供应商 Chainguard 等组织的进一步研究使用容器漏洞扫描工具 Trivy、Snyk 和 Grype 通过 Docker Hub （https://uploads-ssl.webflow.com/6228fdbc6c97145dad2a9c2b/624e233 7f70386ed568d7e7e_chainguard-all-about-that-base-image.pdf） 上的下载量来评估一些最流行的基础映像。Chainguard 发现，Node、Debian、Ubuntu 和 Red Hat UBI 等领先镜像都融入了大量的技术债务。这些图像的漏洞计数从 28 个到高达 800 个不等，具体取决于图像和使用的扫描程序。漏洞严重程度从低到严重不等，在所使用的三个漏洞扫描程序中，只有 Alpine： 3.15.0 映像不包含已知漏洞。正如该研究指出的那样，与其他产品相比，Alpine之所以得分如此之高，是因为它是一个面向安全的基础映像，包含不到10个软件包。这是一个减少攻击面和创建基础映像的示例，这些映像考虑了安全性，以降低组织风险。显然，容器化应用程序的每一层都可能增加风险状况，但建议从适当安全且最小的基础映像开始。

不仅基础映像是一个值得关注的话题，而且组织越来越多地采用建立强化容器的内部存储库的做法，这些容器已经过攻击面减少和强化，并由受信任的实体签名。这降低了团队从公共源拉取容器映像的可能性，因此他们可能会改用内部批准和存储的映像，以满足组织的安全性和合规性要求。最明显和被引用的例子之一是国防部 （DoD） 的 Iron Bank （https://p1.dso.mil/products/iron-bank），这是一个容器存储库，其中包含经过强化、批准和授权的容器映像，供美国空军 （USAF） 和更广泛的国防部使用。美国联邦民事机构也利用了这些强化映像，并紧随其后，建立了自己的内部安全容器映像存储库，以供使用和部署。

公共 Git 存储库代表了另一种可以在容器软件供应链中引入风险的途径。虽然与映像关联的 CVE 是衡量容器安全性的重要指标，但了解它们来源的存储库是另一个衡量标准，可告知组织对固有或潜在风险的理解。一个流行的项目，着眼于与公共GitHub项目及其存储库相关的配置和活动，是OpenSSF记分卡计划，我们将在第7章中讨论，标题为“现有和新兴的商业指南”。

应用程序代码、依赖项和 OSS 组件都存在风险，这些风险也可能导致容器镜像的漏洞配置文件。因此，在将容器引入运行时环境之前，使用应用程序安全最佳实践非常重要，例如对通过持续集成/持续交付 （CI/CD） 管道的容器实施静态应用程序安全测试 （SAST） 和软件组合分析 （SCA） 扫描。这些工具可以帮助识别容器内代码中的漏洞，这些漏洞可以在引入生产环境之前进行修正，恶意参与者可能会利用这些漏洞。

也就是说，尽管在生产之前将安全性向左转移并识别管道中或在构建期间的漏洞是很好的做法，但它们并不能减轻对运行时容器分析和监视的需求。管道中可能遗漏了漏洞，或者部署后可能出现了新的漏洞，因此除了管道可见性之外，组织还需要对容器运行时进行监视。正如云原生所提到的Computing Foundation （CNCF） 的云原生安全最佳实践白皮书 （https://cncf.io/blog/2022/05/18/announcing-the-refreshedcloud-native-security-whitepaper），云原生工作负载需要安全性 控件贯穿其整个生命周期，包括运行时。如果正确的工具和可见性已到位，安全团队可以了解运行时环境中的漏洞，更新容器映像并重新部署不再脆弱的映像。

需要指出的是，现代应用程序也绝大多数由开源代码和组件组成。安全领导者 Snyk 等组织发现 80% 的应用程序代码由 OSS （https://snyk.io/wp-content/uploads/Snyk-Docker-ContainerSecurity.pdf） 组成。当然，这种开源代码包含直接依赖关系和传递依赖关系，每个依赖关系都包含各自的漏洞。除了OSS代码和组件之外，容器镜像也是分层创建的，每一层的工具、库和附加组件都代表了引入风险的可能性。通过管理和控制添加到容器文件的其他代码和层，组织可以控制引入的风险。

使用容器时的另一个关键问题是主机基础结构本身。如前所述，这意味着 Kubernetes 集群作为业务流程协调程序运行，但也存在诸如底层 VM 之类的问题。这些问题包括 VM 的强化、其选择的操作系统以及与主机实例关联的网络控制。我们将在下一节中对此进行更多探讨。

6.4 Kubernetes

容器编排通常被定义为自动执行操作工作以运行容器化工作负载和服务。虽然有几种潜在的容器编排工具可供选择，但 Kubernetes 在采用和使用方面无疑是行业领导者 （https://kubernetes.io）。

Kubernetes 起源于 Google 的一个容器编排项目，并在采用和使用方面迅速增长。CNCF 2021 年的一项调查发现，96% 的受访者表示使用 Kubernetes，其中 70% 的受访者表示他们在生产中使用 Kubernetes（www.cncf.io/wp-content/ uploads/2022/02/CNCF-AR_FINAL-edits-15.2.21.pdf）。据估计，全球有 390 万 Kubernetes 开发人员，同比 （YoY） 大幅增长。在一项类似的红帽调查 （www.redhat.com/en/enterpriseopen-source-report/2022?intcmp=701f2000000tjyaAAA） 中，85% 的 IT 领导者认为 Kubernetes 对他们的云原生应用程序战略极其重要或非常重要。

如前所述，Kubernetes 的起源可以追溯到 Google 的早期内部项目，最著名的是 2003 年左右的 Borg 系统。这个项目发展成为一个名为 Omega 的项目，这是谷歌在 2013 年推出的另一个集群管理系统。最后，在 2014 年，Google 开源了 Borg，并将其作为 Kubernetes 引入。从那时起，Kubernetes 的采用和增长才得以加速，推出了额外的版本和功能以及强大的爱好者生态系统。相关的行业活动，如 KubeCon，一个面向 Kubernetes 和云原生生态系统的会议，吸引了来自行业领导者的参与者，并重点介绍了该领域的一些新兴功能和创新。

尽管 Kubernetes 发展迅速，但一些软件供应链组织仍然与 Kubernetes 及其相关技术的使用和实施有关。Kubernetes 在架构上由 Kubernetes 集群中的多个组件组成。这些组件包括 Kubernetes API 服务器。Kubernetes API 服务器验证和配置 Kubernetes 对象的数据，包括 Pod、服务、复制控制器和其他 Kubernetes 实体。

2022 年，每天积极扫描整个互联网 IPv4 空间的 Shadow Server 组织能够找到 380,000 个公开暴露的 Kubernetes API 服务器 （www.shadowserver.org/news/over-380-000-open-kubernetesapi-servers）。他们的研究指出，他们能找到的已知 Kubernetes 实例中有 84% 是公开的，并返回 HTTP 200 OK 响应。许多安全和 Kubernetes 专家指出，这并不意味着这些集群不安全或易受攻击，因为它们的存在通常是由于 CSP 托管 Kubernetes 服务的默认配置。但是，它确实显示了轻微的错误配置如何暴露集群、容器和在其上运行的代码。真正的错误配置可能允许恶意参与者破坏群集及其工作负载，并可能横向转向其他组织资产。

与 Kubernetes 供应链威胁相关的另一个促成因素是 Kubernetes 是通过清单文件实现的。这些是声明性 YAML 或 JavaScript 对象表示法 （JSON） 配置文件，用于描述 Kubernetes 集群的运行方式，定义各种 Kubernetes API 对象的所需状态。这意味着它们是用代码编写的，并且能够像其他形式的传统代码和配置文件一样保存、存储和共享。
使用各种资源管理复杂的 Kubernetes 部署可能是一项复杂的任务。通常，组织将使用 Helm 图表，这是一种用于描述一组相关 Kubernetes 资源的文件集合的打包格式。Helm 图表与 Kubernetes 资源非常相似，通常以 YAML 格式进行描述。它们被存储、共享和可用在诸如 Artifact Hub 之类的地方，Artifact Hub 是一个基于 Web 的应用程序，可用于查找、安装和发布各种 CNCF 项目（包括 Kubernetes）的包和配置。

虽然使用现存的Helm图表和配置文件可以加快实现和部署的时间，但这样做也会带来传统软件代码存在的风险，如恶意或易受攻击的代码或配置。例如， Palo Alto的研究小组Unit 42在他们的“2H 2021”白皮书中研究了Kubernetes和Helm（https://paloaltonetworks.com/prisma/unit42-cloud-threat-research-2h21.html）。研究人员使用一种名为“helm-scanner”的工具来评估Artifact Hub上的Helm图表和YAML文件，发现超过99%的图表容器有不安全的配置，近10%的容器至少有一个关键或高度不安全的配置。

研究人员还指出，与代码类似，Helm图表通常依赖于其他图表，他们在图表中识别的62%的错误配置是由于依赖图表。他们还指出，依赖项计数越高，平均错误配置计数就越高。这些错误的配置包括诸如过度特权的容器和不安全的网络配置等项。因此，尽管现代应用程序和工作负载经常被部署在 Kubernetes的容器上，但 Kubernetes的配置文件和图表经常被复制和共享固有的漏洞和错误配置本身，潜在地威胁到驻留在这些集群上的所有工作负载。

在 Kubernetes的背景中，配置和声明性显示构成了自己的风险，但恶意行为者通常是在 Kubernetes工作负载并使用容器图像的生命周期渗透 Kubernetes供应链之后。这些攻击向量可能包括基本映像、应用程序代码和依赖关系、存储库、OSS组件和其他相关资源。如果邪恶的参与者可以让恶意代码在容器化的工作负载上运行，特别是没有适当的Kubernetes安全配置，它们不仅会影响单一的工作负载，还可以影响集群中其他潜在的工作负载，或者更广泛的说，影响组织的企业系统，这取决于适当的架构和配置。在Kubernetes的背景下确保适当的供应链安全将意味着确保您有一个安全的 Kubernetes的体系结构和配置。

对于想从这方面着手的组织团体的建议当然是Kubernetes文档和最佳实践，但也要利用行业指导的形式下的来源，如 Kubernetes CIS Benchmark（www.cisecurity.org/benchmark/kubernetes）或Kubernetes Defense Information Systems Agency (DISA) Security Technical Implementation Guide (STIG)。这些指导源集中于核心活动，如保护Kubernetes 体系结构的控制平面组件，包括主节点、控制器管理器、调度器等。它们还包括与正确实施安全策略和基于角色的访问控制（RBAC）、网络策略和秘密管理相关的控制和配置。未能实现这些安全实践和配置可能会影响节点和集群内的工作负载，并可能允许到它们所连接的企业环境中的其他系统的横向移动。

组织也经常使用CSP的管理Kubernetes服务，如谷歌的Kubernetes Engine（GKE）或亚马逊的Elastic Kubernetes（EKS）。使用这些管理的Kubernetes产品可以通过“rolling your own”Kubernetes来减轻一些管理开销（例如，拥有整个控制平面的活动和配置）。然而，使用托管的Kubernetes产品并不是没有它自己的问题。在CSP环境中仍然需要安全的配置，如身份和访问管理（IAM）、加密和密钥管理、网络和运行工作负载的节点的元数据服务，再加上信任和依赖云提供者的固有特性。

了解保护Kubernetes集群的最佳资源之一是Kubernetes文档页面 (https://kubernetes.io/docs/tasks/ administer-cluster/securing-a-cluster)。 CIS Kubernetes Benchmark， DISA Kubernetes STIG和NSA Kubernetes Security Guide也是优质资源，但用户还应该更广泛地确保，如果他们所使用的云平台的云本地安全最佳实践也会得到解决。

组织可以使用工具来确保Kubernetes的集群和部署，以及Kubernetes的安全最佳实践。一些例子包括来自Aqua Security（https://github.com/aquasecurity/kube-bench）的kube-bench，一个OSS工具，检查部署的Kubernetes配置是否与 CIS Kubernetes Benchmark一致。与Kubernetes本身类似，kube-bench使用了用YAML编写的测试，它可以随着基准测试的发展而进行修改。Aqua的另一个著名工具是kube-hunter，它寻找Kubernetes集群中的安全弱点。kube-hunter可以在机器或端点上运行，并使用IP进行远程扫描。此外，它可以在集群中的机器上运行，甚至可以作为集群中的pod运行。kube-hunter的一个独特方面是，它不仅支持审计/评估模式，还支持主动搜索模式，这可以改变集群的状态，利用被发现的漏洞。特别是由于后一种原因，kube-hunter文档特别指出，该工具不应该用于您不拥有的集群，其中包括使用受管理的Kubernetes产品。

想要了解与Kubernetes相关的各种攻击策略和技术的组织也可以利用资源，如微软对Kubernetes的Threat Matrix（www.microsoft.com/en-us/ security/blog/2020/04/02/attack-matrix-kubernetes），如图6.4所示。

就像MITRE ATT&CK一样，这个资源可以帮助组织了解其环境的攻击表面，以及恶意行为者所使用的各种策略。微软在他们的Threat Matrix中采取了类似的方法，但针对Kubernetes进行了定制，包括揭露Kubernetes的秘密和利用集群内部网络等活动，如图6.4所示。这些战术范围从初始访问阶段到影响，很像MITRE ATT&CK。

另一个类似的资源是 由Weaveworks传播的MITRE ATT&CK Matrix for Kubernetes（www .weave.works/blog/mitre-attack-matrix-for-kubernetes），它使用类似于微软的Threat Matrix，还包括一个收集阶段，它专注于对手用于收集信息的技术，特别是从私人注册中心收集图像。尽管Weaveworks和微软的Threat Matrix之间存在差异和相似之处，但这两种资源都可以帮助组织理解以Kubernetes为中心的攻击的各个阶段，以及恶意行为者可能用来利用Kubernetes环境和协调的工作负载的相关策略。除了前面讨论过的资源，如 CIS Benchmarks，DoD STIGs，和Kubernetes Threat Matrices，组织还应该寻求采用新兴的框架，如Supply Chain Levels for Software Artifacts (SLSA)，我们会在下一章中讨论。

Kubernetes还支持各种多租赁模型，这些模型使用其集群和名称空间的构造，以促进云本地工作负载的效率、成本节约和可伸缩性（www.weave.works/blog/mitre-attack-matrix-forkubernetes）。对于部署工作负载到Kubernetes的组织来说，理解他们正在使用的租赁模型和潜在的安全和合规考虑事项是很重要的，特别是如果发生了安全事件或数据泄露，如果安全卫生和爆炸半径控制不良，可能会对租户产生级联影响。为了详细了解云原生环境中多租户的风险，云安全领导者Wiz发布了他们所谓的“PEACH Framework”，这是一个助记符，包括特权、加密、身份验证、连接硬化以及卫生等因素。该框架可以应用于Kubernetes的部署以及更广泛的多租户云环境（www.datocms-assets.com/75231/1671033753-peach_whitepaper_ver1-1.pdf）。

在Kubernetes生态系统中也支持SBOM。最值得注意的是，这包括OSS Kubernetes的bom实用程序，它利用为Kubernetes编写的代码为他们的项目生成SBOMs（https://github.com/kubernetes-sigs/bom）。Kubernetes bom工具支持从文件、图像和Docker图像中创建SBOMs，并将一组文件打包到单个文件中。您还可以从注册表中提取图像，并使用bom工具分析它们。它以 Software Package Data Exchange (SPDX) SBOM格式生成这些工件，并可以导出到一个in-toto的来源证明。In-toto是一个”超越最后一英里“或最终工件焦点的框架，旨在确保软件产品从启动到最终用户安装的完整性，使其透明地执行了什么步骤、由谁以及以什么顺序执行（https://in-toto.io/in-toto）。这些in-toto的来源证明都允许生成关于一个软件是如何生产的任何方面的可验证声明。可以利用Kubernetes的bom工具使用一个简单的”bom generate“命令创建SPDX清单。

6.5 无服务器模型

在VMs和容器的计算抽象和演化的基础上，一些组织根据它们的用例进一步采取了他们的采用过程，并已经开始使用所谓的无服务器模型。更高级的说法是，无服务器模型允许开发团队构建和运行云本地的应用程序，而不需要管理底层服务器。云范式如IaaS，PaaS和SaaS，有一些相似之处PaaS和SaaS不需要管理基础设施和服务器，但主要区别在于应用了无服务器模型，而不是消耗一个SaaS提供商的应用程序，开发人员部署代码到云平台并且由云提供商后续托管和执行。云提供商处理底层基础设施，包括管理开销，如扩展和修补托管运行代码的服务器和实例的补丁。

最流行的一个例子之一是AWS的Lambda服务，它允许您运行代码，而不需要提供或管理服务器。该代码在一个高度可用的计算基础结构模型中运行，并处理实例的底层日志记录。其他云提供商，如谷歌和微软Azure也提供类似的无服务器功能。

在软件供应链安全方面，即使是在无服务器模式中，忧虑也仍然存在。在无服务器模型函数中运行的代码仍然可能包含OSS组件或易受攻击的代码，这可能会给在无服务器体系结构中运行的组织带来风险。此外，如前面讨论的，基础的functions-asa-service (FaaS)和云中的基础设施也由软件提供动力，每个软件都包含各种软件组件也可能包括OSS。

6.6 SaaSBOM及API复杂度

为所包含的实体创建一个SBOM可能会很复杂，例如在本地交付的软件或容器映像。为具有云和SaaS等无数相互关系的动态且快速变化的环境创建SBOM可能是另一个级别的难度。

关于SaaS的SBOM的概念已经出现了讨论，它被称为SaaSBOM。云和SaaS引入了供应商管理的部署模型，而在这些模型中，消费者不拥有或控制底层的物理基础设施、托管环境、操作系统，甚至不是应用程序。应用程序仅仅是作为服务使用，即”as-a-Service“，而消费者对应用程序的配置和修改仅有有限的控制权。

一个更正式的定义是 NIST的800-145 Definition of Cloud Computing： ———————————————————————————————————————————————————— 提供给消费者的功能是使用运行在云基础设施上的提供商的应用程序。这些应用程序可以通过瘦客户机接口，如web浏览器（例如，基于web的电子邮件）从各种客户端设备或程序接口访问这些应用程序。消费者不管理或控制底层的云基础设施，包括网络、服务器、操作系统、存储，甚至是单个应用程序功能，可能有有限的用户特定的应用程序配置设置除外。 ————————————————————————————————————————————————————

2021年初，SBOMs快速流行起来，该行业的许多从业者开始提出疑问，是什么推动SBOMs在高度动态和复杂的环境中工作，比如SaaS（用于应用程序的另一种方法，不像传统的软件交付和消费）。这本书的作者之一在2021年9月共同发表了一篇题为《The Case for a SaaS Bill of Materials》的文章（www.csoonline.com/article/3632149/the-casefor-a-saas-bill-of-material.html）。正如文章所指出的，在SaaS环境中定义什么是软件是具有挑战性的。现代SaaS通常建立在现有的IaaS和PaaS环境上，这些环境通常由其他CSPs拥有。底层的IaaS和PaaS通常被定义为“as-code”，并包括物理组件和虚拟组件，所有这些组件都包括它们自己的软件。这在SaaS环境中定义软件时造成了一种复杂的情况，因为涉及到无数的代码和软件组件，以及包含的各种关系和所有权实体。也就是说，许多业内人士都是在服务和数据流的背景下，围绕着SaaSBOMs作为焦点。CISA的SBOM Working Group包括一个Cloud Working Group，那里的许多专业人士都主张采取这个立场。Cloud Security Alliance（CSA）的出版物《SaaS Governance Best Practices for Cloud Customers》也引用了在SaaS中使用SBOMs，本书的其中一位作者领导了该出版物（https://cloudsecurityalliance.org/artifacts/saas-governance-best-practices-for-cloud-customers）。

为了进一步增加挑战，供应商经常使用工具来维护和操作底层云环境以及驻留在它们之上的SaaS。其中最值得注意的是 Ansible、Chef和Terraform，所有这些都有助于配置、部署和管理SaaS所依赖的云基础设施。当然，为了促进SaaS的交付，还涉及到其他的系统和软件，如CI/CD管道和IAM软件。

所有这些实体都是由软件组成的，并且经常动态和快速地变化，这使得定义它们确切的软件组件组成具有挑战性。建议的方法包括让SaaS供应商在他们的控制范围内尽可能确定整个技术组件，SaaS应用程序依赖这些组件能够向应用程序消费者提供SaaSBOM。尽管具有挑战性，但这种方法仍具有可能性，因为SaaS提供商至少应该能够访问并在其直接控制下理解应用程序交付中使用的组件。

正如我们所提到的，这并不能解决向SaaS应用程序消费者提供底层IaaS和PaaS提供商的软件和系统的详细SBOM的挑战，所有这些都是SaaS应用程序的关键依赖关系。

CycloneDX SaaSBOM

我们并不是唯一认识到SBOM采用性和成熟度是具有挑战性的人。作为行业领先的SBOM格式之一的CycloneDX，它是一个由 Open Worldwide Application Security Project (OWASP)管理的项目，已经提出了SaaSBOM模型，如图6.5所示。

CycloneDX SaaSBOM信息认识到，现代软件依赖于许多外部服务，甚至可以完全由服务组成。出于这个原因，他们致力于使CycloneDX能够代表各种服务类型，包括微服务、FaaS、systems of systems（SoS），当然还有SaaS。CycloneDX指出，SaaSBOMs可以作为infrastructure-as-code (IaC)的补充，IaC还提供了复杂系统的逻辑表示。在IaC的情况下，这包括云架构组件，如网络、计算和访问控制，所有这些都在一个as-code模型中定义。

CycloneDX指出，SaaSBOMs可以提供类似的逻辑表示，包括所有服务、服务依赖关系、相关的URL，甚至是服务和系统之间的数据方向流。

如前所述，SaaS由每个体系结构中的一组独立的应用程序和服务组成，用于向消费者交付应用程序。CycloneDX的SaaSBOM功能允许将服务和软件组件库存成单个BOM或独立的BOMs。CycloneDX建议将大型系统的SaaSBOMs与SBOM脱钩，因为云和SaaS涉及动态服务和部署场景。SaaSBOM可以表示为一个单一实体，其中有许多与之关联的SBOMs，SBOMs表示协同交付SaaS应用程序的相关服务。

因为每个独立的服务显然都有自己独特的漏洞，所以CycloneDX还支持来自其他系统和BOMs的BOM中的能力引用组件、服务和漏洞。这被称为BOM-Link（https://cyclonedx.org/capabilities/bomlink），它支持两种通用场景，即从另一个BOM引用一个BOM，并从一个BOM到另一个BOM引用一个特定的组件或服务。

CycloneDX还建议解耦Vulnerability Exploitability eXchange（VEX）和BOMs，因为BOM可能直到系统清单完成后才能更改，但VEX可以更频繁地更改，因为可能出现与现有和正在使用的软件组件相关的新漏洞。

工具和新兴讨论

从我们的讨论中可以明显看出，实现一个SaaSBOM，或者是一个普通的SBOM，因为它与云的复杂和动态的世界有关，并不是一件容易的事。它将不可避免地需要新的流程和工具来促进它的广泛采用，因为人类要跟上软件组件库存和相关漏洞的快速变化速度是不现实的。

因此，越来越多的人呼吁进一步讨论工具和功能的主题，以帮助解决针对SBOMs的云和SaaS环境中的这些差距。2022年7月，CISA就几个主题举行了一系列的会议，其中包括“Cloud & Online Applications”（www.federalregister .gov/documents/2022/06/01/2022-11733/public-listening-sessions-onadvancing-sbom-technology-processes-and-practices）。这些事件并不是为了寻求共识，但这些对话被用来促进关于SaaS和云应用程序的SBOMs主题的公开对话。

此外，Department of Homeland Security (DHS) Science & Technology (S&T) Directorate正在鼓励技术公司帮助开发自动化的SBOM工具。这是由于DHS S&T意识到大规模管理SBOMs的复杂性，包括SaaS。在他们的声明中，S&T承认，试图利用软件漏洞的攻击可能会导致安全和社会所依赖的关键系统的中断和损害。有关更多信息，请参见“DHS S&T Seeks Solutions to Software Vulnerabilities”：

https://dhs.gov/science-and-technology/news/2022/07/11/st-seeks-solutions-software-vulnerabilities

6.7 在DevOps和DevSecOps中的应用

随着云和云原生架构的出现并继续流行，另一个趋势发生了：从传统的瀑布式软件开发到DevOps时代，或者最近的DevSecOps时代的转变。在不进行哲学辩论的情况下，DevOps可以概括为一套弥合软件开发和操作之间鸿沟的实践，或者在DevSecOps、软件开发、安全和IT操作的情况下。这场运动可以追溯到21世纪初，比如 Patrick Debois，Andrew Shafer，Gene Kim和Jez Humble，他们对生态系统做出了贡献。这与云计算的发展相吻合，组织也越来越多地使用云原生技术，通过敏捷和DevOps方法来促进业务结果。为了更好地理解DevOps，我们推荐诸如《DevOps Handbook (2nd edition, IT Revolution Press, 2021) 》或《 The Phoenix Project (5th Anniversary edition, IT Revolution Press, 2018)》。

本章其他章节中提到的许多技术，如cloud、SaaS、CI/CD、Kubernetes、containers和infrastructure as code，都在DevSecOps的成功旅程和实现中发挥了作用。在软件供应链安全和DevSecOps的背景下，一个健壮的工具生态系统已经出现。快速浏览一下CNCF场景（https:// landscape.cncf.io）就可以看到在CI/CD、自动化和配置、调度和编排等领域的蓬勃发展，所有这些都在现代DevSecOps环境中扮演着重要的角色。值得强调的是，尽管工具和技术促进了成功的DevOps转换，但DevOps不是工具或技术；它是一种方法和一套实践。已经采用了许多工具来支持DevOps，而一些常见的方法，如CI/CD，已经允许集成工具来应对软件供应链的挑战。

Syft和Grype等工具通常用于工具链中，以便创建SBOMs，并扫描这些SBOMs，以寻找与在部署到生产环境之前通过工具链的软件组件相关的漏洞。DevOps使用源代码管理（SCM）和Git存储库、CI/CD管道、声明性部署的GitOps风格等等。所有这些工具和方法都已经融合起来，以支持从源代码到运行时的迭代软件交付。它们还使团队和组织能够利用工具获得源代码、容器映像、不安全的IaC或Kubernetes配置中涉及的组件，最终形成了云本地部署架构，每个组件都有自己的软件供应链问题。

像NIST这样的组织已经开始请求DevSecOps的实践可以帮助识别、评估和减轻软件供应链的风险(www.nccoe.nist.gov/sites/default/files/2022-07/dev-sec-ops-projectdescription-draft.pdf)。如白皮书《Software Supply Chain and DevOps Security Practices》中所述，该观点旨在为安全的DevOps环境提供基于风险的建议。它还寻求与其他NIST的指导方针相一致，如SSDF和800-161/C-SCRM。本指南采用了一种非常以CI/CD管道为中心的方法，将软件供应链安全集成到DevSecOps环境中。

敏捷和DevOps的一个基本方面是远离传统的瀑布式软件开发，而是专注于更多的迭代和增量的软件交付。有些人可能会认为，敏捷的增量性质和DevOps可能会促进管理软件供应链的安全问题。随着组织逐步生产和发布软件，工具链可用于识别软件组件、关联漏洞、聚合这些指标，并授权组织做出与软件供应链问题相关的了解风险的决策。使用DevSecOps工具和在SDLC中强调左移安全或更早的安全性，可以在引入运行时环境之前识别出易受攻击的软件组件。许多人声称，从成本的角度来看，这种方法更有效，但它也降低了利用的可能性，因为如果该漏洞及早被捕获并补救，就不能在生产过程中被恶意行为者利用。

DevSecOps不仅提供了捕获SDLC早期脆弱软件组件的机会，并提供了更好的透明度，而且高能力的DevSecOps团队能够更好地应对软件供应链问题和事件。研究支持这些说法，最著名的是由谷歌运营的DevOps Research and Assessment (DORA) 团队。在《2022 Accelerate State of DevOps Report》中，DORA团队发现，部署前安全扫描等实践在发现脆弱的依赖关系方面是有效的，这导致生产应用程序中的漏洞更少（https://services.google.com/fh/files/misc/2022_state_of_devops_report.pdf）。

由于DORA团队多年来进行了他们的研究，他们创建了特定的指标，现在被认为是DORA指标。他们用于衡量软件开发团队绩效的四个关键指标如下：

部署频率：一个组织成功地发布到生产环境中的频率
变更提前期：一个承诺投入生产所需的时间
变更失败率：导致生产过程中失败的部署的百分比
服务恢复时间：一个组织从生产失败中恢复过来需要多长时间，这也通常被称为平均恢复时间（MTTR）

这四个指标支持两个关键主题：部署频率的速度和更改的提前时间、故障率的稳定性和恢复服务的时间。这些指标有助于衡量团队以业务/任务需求的速度发布软件的能力，同时也能确保这些发布不会影响系统的弹性。一开始认为快速移动的团队是稳定的似乎是违反直觉的，但正如行业专家指出的那样，在不影响稳定性的情况下，正是软件开发和交付的实践帮助这些团队能够做到这一点。那些在生产中不频繁发布软件的队伍往往而且需要更长的时间完成产品，并且经常难以应对变化以及无法从故障中恢复系统。在这种情况下，高表现力的DevOps团队可以被认为是已经将上述经验内化成了肌肉记忆。

6.8 小结

总之在《2022年DevOps状态报告》中、DORA团队的软件工件供应链水平（SLSA）和NIST的SSDF确定了与保护软件供应链相关的流程和实践。我们探讨了DevOps和DevSecOps为何不仅仅是工具——它们是文化实践和方法的集合。DevSecOps方法使团队能够缓解软件供应链问题，最近的研究已经开始支持这一观点。

在本章中，我们讨论了云原生范式中与软件透明度相关的一些复杂性和细微差别。这包括与云相关的基本服务模型、云原生的4C，以及SaaS环境中的SBOM。我们还讨论了使用成熟DevSecOps实践的高绩效团队如何实现更安全的软件供应链结果。