云原生应用由多个松散耦合的组件（称为微服务，通常以容器形式实现）组成，在需要零信任概念的无边界网络环境中运行（企业内部或云），并由来自不同地点的用户访问（例如，校园、家庭办公室等）。云原生应用不只是指在云中运行的应用。它们还指具有设计和运行时架构的一类应用，如微服务，以及用于提供所有应用服务（包括安全）的专用基础设施。将 零信任原则 纳入这类应用提供了一些技术，其中对所有受保护资源的访问是通过基于身份的保护和基于网络的保护（如微分）来强制执行的。
由于业务原因，云原生应用程序需要敏捷和安全的更新和部署技术，以及应对网络安全事件的必要弹性。因此，它们需要一种与传统的单层或多层应用不同的应用开发、部署和运行时监控范式（统称为软件生命周期范式）。DevSecOps（开发、安全和运维）是这类应用的促进范式，因为它通过（a）持续集成、持续交付 / 持续部署（CI/CD）管道（在第 3 节中解释）等基本要素促进了敏捷和安全的开发、交付、部署和运维；（b）整个生命周期的安全测试；以及（c）运行时的持续监控，所有这些都由自动化工具支持。事实上，满足上述目标的范式最初被赋予了 DevOps 这个术语，以表明它试图消除开发和运维之间的隔阂，并促进（或推动）加强合作。后来，DevSecOps 这个词是由社区的一部分人创造的，以强调安全团队在整个过程中的作用。因此，DevSecOps 这个术语表示一种文化和一套带有自动化工具的实践，以推动负责交付软件的关键利益相关者（包括开发、运维和安全组织）之间加强协作、信任、分担责任、透明度、自主性、敏捷性和自动化。DevSecOps 拥有必要的基本要素和其他构建模块，以满足云原生应用的设计目标。
应该注意的是，整个社区对 DevSecOps 一词并无共识。如前所述，该术语主要是为了强调一个事实，即必须在软件开发生命周期的所有阶段（即构建、测试、打包、部署和运行）对安全进行测试和整合。社区中的一部分人继续使用 DevOps 这个术语，理由是没有必要定义一个新的术语，因为安全必须是任何软件生命周期过程的一个组成部分。
1.1 范围
从理论上讲，DevSecOps 原语可以应用于许多应用架构，但最适合于基于微服务的架构，由于应用是由相对较小的、松散耦合的模块组成的，被称为微服务，因此允许采用敏捷开发模式。即使在基于微服务的架构中，DevSecOps 原语的实现也可以采取不同的形式，这取决于平台。在本文中，所选择的平台是一个容器编排和资源管理平台（如 Kubernetes）。该平台是物理（裸机）或虚拟化（如虚拟机、容器）基础设施上的一个抽象层。为了在本文中明确提及该平台或应用环境，它被称为 DevSecOps 原语参考平台，或简称为 参考平台。
在描述参考平台的 DevSecOps 原语的实现之前，我们假设在部署服务网格组件方面采用了以下 尽职调查：
- 用于部署和管理基于服务网格的基础设施（如网络路由）、策略执行和监控组件的安全设计模式
- 测试证明这些服务网格组件在应用的各个方面（如入口、出口和内部服务）的各种情况下都能按预期工作。
为参考平台实施 DevSecOps 原语所提供的指导与 (a) DevSecOps 管道中使用的工具和 (b) 提供应用服务的服务网格软件无关，尽管来自 Istio 等服务网格产品的例子被用来将它们与现实世界的应用工件（如容器、策略执行模块等）联系起来。
以下是对参考平台所呈现的整个应用环境中的代码类型（在执行摘要中提到）的稍微详细的描述。请注意，这些代码类型包括那些支持实施 DevSecOps 原语的代码。
- 应用代码：体现了执行一个或多个业务功能的应用逻辑，由描述业务事务和数据库访问的代码组成。
- 应用服务代码（如服务网格代码）：为应用提供各种服务，如服务发现、建立网络路由、网络弹性服务（如负载均衡、重试），以及安全服务（如根据策略强制执行认证、授权等，见第 4 章）。
- 基础设施即代码：以声明性代码的形式表达运行应用程序所需的计算、网络和存储资源。
- 策略即代码：包含声明性代码，用于生成实现安全目标的规则和配置参数，例如在运行期间通过安全控制（如认证、授权）实现零信任。
- 可观测性即代码：触发与日志（记录所有事务）和追踪（执行应用程序请求所涉及的通信途径）以及监控（在运行期间跟踪应用程序状态）有关的软件。
代码类型 3、4 和 5 可能与代码类型 2 有重叠。
本文件涵盖了与上述所有五种代码类型相关的管道或工作流程的实施。因此，整个应用环境（不仅仅是应用代码）受益于应用代码的所有最佳实践（例如，敏捷迭代开发、版本控制、治理等）。基础设施即代码、策略即代码和可观测性即代码属于一个特殊的类别，称为声明性代码。当使用“xx 即代码”的技术时，编写的代码（例如，用于配置资源的代码）被管理，类似于应用源代码。这意味着它是有版本的，有文件的，并且有类似于应用源代码库的访问控制定义。通常，使用特定领域的声明性语言：声明需求，并由相关工具将其转换为构成运行时实例的工件。例如，在基础设施即代码（IaC）的情况下，声明性语言将基础设施建模为一系列的资源。相关的配置管理工具将这些资源集中起来，并生成所谓的 清单，定义与所定义的资源相关的平台（运行时实例）的最终状态。这些清单存储在与配置管理工具相关的服务器中，并由该工具用于为指定平台上的运行时实例创建编译的配置指令。清单通常以平台中立的表示方式（如 JSON）进行编码，并通过 REST API 反馈给平台资源配置代理。
1.2 相关的 DevSecOps 倡议
在联邦政府的各个机构中，有几个 DevSecOps 倡议，其重点和焦点各不相同，这取决于软件和任务需求所带来的流程。尽管并不详尽，但以下是对 这些倡议 的简要概述：
- DevSecOps 管道参与构建、签入和签出一个名为 Iron Bank 的容器镜像仓库，这是一个经过国防部审查的强化容器镜像库。
- 空军的 Platform One，也就是实现了连续操作授权（C-ATO）概念的 DevSecOps 平台，这又简化了国防部的授权程序，以适应现代连续软件部署的速度和频率。
- 国家地理空间情报局（NGA）在 "NGA 软件之路" 中概述了其 DevSecOps 战略，其中为其每个软件产品规定了三个关键指标：可用性、准备时间和部署频率，以及用于实现 DevSecOps 管道的七个不同产品系列的规格，包括消息传递和工作流工具。
- 医疗保险和医疗补助服务中心（CMS）正在采用一种 DevSecOps 方法，其中一个重点是为软件材料清单（SBOM）奠定基 —— 这是一种正式记录，包含用于构建软件的各种组件的细节和供应链关系。制作 SBOM 的目的是为了实现持续诊断和缓解（CDM）计划下的目标。
- 在海军水面作战中心（NSWC），DevSecOps 原语的实施方法被用来教导和培训软件工作人员，让他们了解各种软件指标以及自动化作为实现这些指标的助推器的作用。
- 陆军的 DevSecOps 倡议被称为 “陆军软件工厂”，重点是建立技能组合而不是建立软件。它利用 DevSecOps 能力（管道和平台即服务功能）作为技术加速器，在产品管理、用户体验、用户界面（UI/UX）设计、平台和软件工程方面提高效率和熟练度。
1.3 目标受众
由于 DevSecOps 的基本要素跨越了开发（安全的构建和测试、打包）、交付 / 部署和持续监控（以确保运行期间的安全状态），本文建议的目标受众包括软件开发、运维和安全团队。
1.4 与其他 NIST 指导文件的关系
由于参考平台是由容器编排和资源管理平台以及服务网格软件组成的，以下出版物为确保该平台的安全提供了指导，并为本文件的内容提供了背景信息。
- SP800-204，基于微服务的应用系统的安全策略，讨论了基于微服务的应用的特点和安全要求，以及满足这些要求的总体策略。
- SP800-204A，使用服务网格构建基于微服务的安全应用，为基于微服务的应用的各种安全服务（如建立安全会话、安全监控等）提供了部署指导，这些服务使用基于独立于应用代码运行的服务代理的专用基础设施（即服务网格）。
- SP800-204B，使用服务网格的基于微服务的应用的基于属性的访问控制，为在服务网格中构建满足安全要求的认证和授权框架提供了部署指导，例如：（1）通过在任何一对服务之间的通信中实现相互认证来实现零信任；（2）基于访问控制模型，如基于属性的访问控制（ABAC）模型的强大访问控制机制，可用于表达广泛的策略集，并在用户群、对象（资源）和部署环境方面可扩展。
- SP800-190，应用容器安全指南，解释了与容器技术相关的安全问题，并为在规划、实施和维护容器时解决这些问题提出了实用建议。这些建议是针对容器技术架构中的每个层级提供的。—
1.5 本文件的组织
本文件的结构如下：
第二章简要介绍了参考平台，为其提供了实施 DevSecOps 原语的指导。
第三章介绍了 DevSecOps 的基本要素（即管道），设计和执行管道的方法，以及自动化在执行中的作用。
第四章涵盖了管道的所有方面，包括（a）所有管道需要解决的共同问题，（b）对第 1.1 节中列出的参考平台中五种代码类型的管道的描述，以及（c）DevSecOps 在整个生命周期中对整个应用环境（有五种代码类型的参考平台，因此承载着 DevSecOps 的实施）的安全保证的好处，包括 持续授权操作（C-ATO）。
第五章提供了摘要和结论。