DevSecOps 参考模型介绍

目录

一、参考模型概述

1.1 概述

二、参考模型分类

2.1 DevOps 组织型模型

2.1.1 DevOps 关键特性

2.1.1.1 模型特性图

2.1.1.2 特性讲解

2.1.1.2.1 自动化

2.1.1.2.2 多边协作

2.1.1.2.3 持续集成

2.1.1.2.4 配置管理

2.1.2 DevOps 生命周期

2.1.2.1 研发过程划分

2.1.2.2 研发阶段划分

2.1.2.2.1 阶段划分图

2.1.2.2.2 阶段划分说明

2.1.2.2.2.1 持续集成

2.1.2.2.2.2 持续交付

2.1.2.2.2.3 持续部署

2.1.3 DevOps 管道与流程

2.1.4 DevOps 模型总结

2.2 Gartner 普适性模型

2.2.1 Gartner对 DevSecOps的贡献

2.2.2 Gartner 安全工具链参考模型

2.2.2.1 DevSecOps 安全工具链模型图

2.2.2.2 Gartner 安全工具链模型与DevOps的比较

2.2.2.2.1 阶段划分

2.2.2.2.2 全程贯穿

2.2.2.2.3 工具支撑

2.2.3 Gartner 推荐的安全工具

2.3 DoD 实践型模型

2.3.1 DoD模型概述

2.3.2 DoD DevSecOps 体系文件构成

2.3.3 DoD DevSecOps 实践价值

2.3.4 DoD模型安全工具链及周边支持生态系统

2.3.4.1 安全工具链及周边生态图和生态说明

2.3.5 DoD模型在实践保障方面的内容

2.3.6 DoD模型持续改进方面的内容

2.3.7 DoD模型总结

一、参考模型概述

1.1 概述

在 DevSecOps的发展过程中，从DevSecOps理论的出现，到如今 DevSecOps 大量实践的落地，先后产生了一系列与DevSecOps有关的模型，这其中比较有代表性的模型分别是：DevOps 组织型模型、Gartner 普适性模型、DoD 实践型模型。

二、参考模型分类

2.1 DevOps 组织型模型

DevSecOps起源于 DevOps，熟悉 DevOps模型有助于读者理解组织运转、周边协同、流程设置在 DevSecOps 中的作用。

2.1.1 DevOps 关键特性

2.1.1.1 模型特性图

DevOps作为 DevSecOps的基础，其本身具有如下图所示的4个关键特性，这些特性在DevSecOps落地过程中，为安全活动的执行提供了流程保障和组织保障。

2.1.1.2 特性讲解

2.1.1.2.1 自动化

自动化在DevOps模型中是指研发流程的自动化，尤其是在测试和部署阶段，使用自动化测试工具完成测试，并通过自动化构建、自动化发布加快生产部署的过程，提升整体研发效能。

2.1.1.2.2 多边协作

多边协作是 DevOps模型中倡导的协同文化，促进开发人员和运维人员的合作与整合，责任共担，减少因沟通和信息传递带来的损耗，从而提升生产效率，缩短交付周期。

2.1.1.2.3 持续集成

持续集成是指在DevOps中以IT自动化，以及持续集成(CI)、持续部署(CD)为基础、构建程序化的开发、测试、运维等管道化能力，以帮助企业在人工很少干预的情况下，向客户交付应用的效率更高、时间更短，并通过持续的产品质量改进，增加服务功能，实现精益发展。

2.1.1.2.4 配置管理

配置管理是指在 DevOps中使用配置文件，管理代码、测试环境、生产环境、保证应用程序与资源交互的正确性。在更小、更频繁的版本迭代中，降低变更风险，以应用程序为中心来理解基础设施，管理基础设施。

从DevOps关键特性可以看出，无论是组织层面的多边协作、拉通，管道化的持续集成能力，还是配置管理的自动化能力、都为DevSecOps的落地打下了良好的基础。

2.1.2 DevOps 生命周期

2.1.2.1 研发过程划分

在DevOps中，研发过程共划分为8个组成部分，如下图所示：

2.1.2.2 研发阶段划分

2.1.2.2.1 阶段划分图

这8个组成部分在DevOps生命周期中，根据包含组成部分的不同，又可以划分为不同的DevOps阶段。这些阶段之中，主要的有持续集成、持续交付、持续部署，它们之间的区别如下图所示：

2.1.2.2.2 阶段划分说明

2.1.2.2.2.1 持续集成

持续集成是指持续地将所有开发者的代码合并到源码仓库主干上，确保代码合并后的集成测试通过。业界通常称为CI，即Coninuous Integration 的缩写。

2.1.2.2.2.2 持续交付

持续交付是指持续地输出可交付产物，与持续集成的不同在于输出产物达到了可交付条件，保证产物在生产环境可用。而可交付产物部署到生产环境，往往通过手工操作完成。业界通常称为CD，即Continuous Delivery 的缩写。

2.1.2.2.2.3 持续部署

持续部署是指通过自动化手段，将持续交付阶段输出的产物自动化部署到生产环境业界通常称为CD，即 Coninuous Deploy的缩写。

2.1.3 DevOps 管道与流程

在DevOps中强调自动化的重要性，而自动化工作的完成主要依赖DevOps 管道及其相关工具。一个典型的DevOps管道操作流程如下图所示。

从上图中可以看出，研发过程中的关键活动在DevOps管道上有相应的信息化系统承载，如代码管理对应源码配置管理平台，构建测试调度对应CI/CD等。通过 DevOps 管道的流水线作业、将需开发求、编码测试、镜像管理、部署等环节串联了起来，各个不同的角色和岗位人员参与其中，共同推动交付过程。

2.1.4 DevOps 模型总结

从上文对 DevOps关键特性、DevOps生命周期、DevOps管道与流程的介绍，读者对DevOps模型有了基本的了解。同时，细心的读者也会发现，在DevOps模型中，安全在生命周期中的参与很少，仅靠 DevOps管道中当前对安全能力的引入无法真正解决实际所需的安全问题，这也是为什么后面业界提出DevSecOps的原因。但作为DevSecOps从业人员，必须了解 DevOps，它是 DevSecOps 的基础。只有了解了 DevOps 的关键特性、生命周期、流程管道，在后续的 DevSecOps实践中，才能更好地制定既符合组织发展，又兼顾多方利益的、可以落地的安全措施。

2.2 Gartner 普适性模型

2.2.1 Gartner对 DevSecOps的贡献

在 DevSecOps 发展的过程中，一直有着Gartner频频闪现的身影，甚至在关键时间节点上，Gartner 的推波助澜才使得 DevSecOps 真正发展起来。

Gartner对 DevSecOps的主要贡献主要有两个：

• 一是在业界首先提出了DevSecOps 的概念并加以倡导和细化，使之更易于落地;
• 另一个是在DevSecOps架构的基础上提出安全工具链指引模型，从普适性层面解决了大多数企业落地中切人点的难题(这也是为什么称它为普适性模型的原因)。

前文中曾提到，DevOps模型对 DevSecOps 更偏向于组织保障，缺少从安全视角对研发过程的深人理解。Gartner给出 DevSeeOps安全工具链的指引恰好弥补了这个缺陷，让广大企业管理者、安全从业人员能从安全的视角，全面地看清安全在DevOps中的实现方式。

2.2.2 Gartner 安全工具链参考模型

2.2.2.1 DevSecOps 安全工具链模型图

Gartner 给出的 DevSecOps 安全工具链模型如下图所示：

在谈及DevSecOps落地的场景时经常会用到此图。从上图中可以看出，Gartner对DevSecOps有着自己的理解，而不是完成对应DevOps，主要体现在以下几点。

2.2.2.2 Gartner 安全工具链模型与DevOps的比较

2.2.2.2.1 阶段划分

在介绍DevOps时，曾提及把研发过程划分为8个组成部分。在上图中，Gartner 把研发过程按照安全的视角一共划分了10个组成部分，并且在开发阶段和运维阶段都添加了安全监控与分析。同时，对每一个组成部分的命名也是从安全视角出发的，如检测(Detect)、响应(Response)。从这一点上说，Gartner认为安全需要融人 DevOps 流程，但并不完全一致，而是从安全管理的要求出发，将其中的组成部分拆分出更细粒度的组成模块。

2.2.2.2.2 全程贯穿

DevOps模型中对安全能力的引入通常更多的是指安全测试验证，而Gartner在设计此模型时，将安全能力分散到不同的研发活动中去，这与安全左移责任共担、多边协作的理念是一致的。

2.2.2.2.3 工具支撑

这个模型图中，很大一部分内容被各种安全工具所占据。从另一个侧面也表明，Gartner 认可安全工具在整个DevSecOps工作的关键作用。将安全工具对应到 DevOps 管道和流程上，更易于与既有流程和平台的整合，加速DevSecOps 的本地化落地。

2.2.3 Gartner 推荐的安全工具

在上节的模型图中，Gartner推荐了诸多的安全工具。需要大家注意的是，这里的工具不是仅仅指具体的某个软件产品，而是指解决安全问题的方式或手段，类似于项目管理中提及的工具的概念。如果将上节模型图按照表格的形式进行呈现，则如下表所示。

从表中可以看出、Gartner推荐的工具链很多是安全活动实践，在当前市场上，有一部分已被标准化成网络安全产品，有些还停留在人工安全活动实践阶段。它们更多的是想说明在不同的研发阶段采用什么样的实践方式解决当前阶段的安全问题。同时，表中也给初次了解 DevSecOps的读者提供了一种很好的技术实践指引，知道不同的安全活动或工具适合在研发过程的哪个阶段引人，如何通过安全左移达到安全治理的目的。

2.3 DoD 实践型模型

2.3.1 DoD模型概述

DoD是美国国防部英文名称Department of Defense的缩写，2019年美国国防部为了推动国防部企业 DevSecOps的落地，发布了一系列的DevSecOps实践规范。因为它是一套独立的、成体系化的指导 DevSecOps落地的文件，所以在这里把它归类为DevSecOps的实践型参考模型。

2.3.2 DoD DevSecOps 体系文件构成

在美国国防部的官网上，对外公开了其DevSecOps体系文件的目录，从这份目录来看一下其文件构成，如下图所示。

从上图的目录结构可以看出，整个体系文件由DevSecOps V2.1规范说明、DevSecOps 实施指南、DevSecOps 参考设计、云原生接入、开源软件安全5个部分组成，每一个部分又分别包含不同的文件。从体系文件管理上来看，DevSecOps V2.1规范说明属于一级文件，定义了 DevSecOps总体方针、策略和基本操作要求；DevSecOps实施指南属于二级文件，主要定义了 DevSecOps 中的关键活动、工具及操作指导；DevSecOps设计参考、云原生接人、开源软件安全均属于三级文件，为具体的安全设计提供参考指引。

从当前业界已公开的DevSecOps资料来看，DoD DevSecOps体系文件具有很高的实践参考价值，可以作为大多数企业开展DevSecOps 工作的首选指导书。

2.3.3 DoD DevSecOps 实践价值

美国国防部为了能够更迅速地应对安全战争与威胁，让新功能快速进场，通过内嵌安全到应用程序来解决此类问题，决定使用DevSecOps模型。意图通过DevSecOps文化，改变国防部IT部门中各个不同组织之间的协作流程、生产制造和运营维护，统一标准和要求，以加快从需求分析到成品交付的过程。

这套文件的技术栈是为美国国防部定制的，从上小节图中公开的文件目录中包含云原生接入点、K8s、AWS等也可以看出，此技术栈不是面向公众全员的，仅是面向美国国防部企业的，但这份文件中涉及的技术概念、DevSecOps能力构成、落地保障措施等都将对DevSecOps 的大范围应用产生深远的影响。

2.3.4 DoD模型安全工具链及周边支持生态系统

2.3.4.1 安全工具链及周边生态图和生态说明

DoD模型文件中首次对 DevSecOps 生态系统做了更具体的解释，除了包含一直被业界推崇的黄金管道之外，还有软件工厂、安全工具链及周边支持生态系统，如下图所示。

在工具链方面，文件中直接用DevSecOps替代DevOps，或者说在这份文件里认为DevOps的未来就是 DevSecOps。它给出更大范围的活动与工具选择的概览，以及活动的输人、输出、活动收益等，涵盖计划、开发、构建、测试、发布、交付、部署、操作和监控的每个阶段。

2.3.5 DoD模型在实践保障方面的内容

在实践保障方面，文件中阐述了组织、流程、技术和治理为DoD DevSecOps的四大支柱，如下图所示：

2.3.6 DoD模型持续改进方面的内容

在持续改进方面，文件定义了DoD DevSecOps的成熟度模型，对DevSecOps的能力一共划分为9个层级，如下图所示：

2.3.7 DoD模型总结

总之，作为第一份业界公开的 DevSecOps落地实践资料，DoD DevSecOps 实践型模型为业界提供了详细的参考资料，并从文件体系构建，技术路线选择、DevSecOps平台选型等多个方面为业界提供最佳实践参考样例。

好了，本次内容就分享到这，欢迎大家关注《DevSecOps》专栏，后续会继续输出相关内容文章。如果有帮助到大家，欢迎大家点赞+关注+收藏，有疑问也欢迎大家评论留言！

代码007普通

打赏 收藏 海报 链接