01 引言
“谁能最快地实现软件定义的军事能力，谁就在未来的冲突中处于优势地位。我们必须将开发周期从数年缩短到数月，以便我们能够在面对威胁的观察-导向-决定-行动(OODA)循环内作出反应和响应。诸如DevSecOps之类的敏捷方法可以实现这种快速循环方法。“– Defense Innovation Board (DIB), Software Acquisition and Practices (SWAP) Study, May 3, 2019, [1], DIB SWAP。
导弹防御，人工智能，高超音速飞机/武器，命令与控制（C2），自治系统，情报，监视与侦察（ISR），网络基础设施，四潜艇战，网络/电子战，机器辅助人类作战等跨越多个领域和任务，但是它们都有一个共同的组件并且关键的依赖就是软件。
软件可以用作增速器，实现精确的杀伤力和更快的决策。但是，软件可能需要数月或数年的时间来更新产品，这可能会成为一个严重的障碍，既延迟了重要的新功能，也造成了网络安全漏洞。从部署软件开始，漏洞就开始出现在软件组件中，例如操作系统，库和其他软件组件。在网络战争中，必须能够尽快更新和修补软件。使用旧的构建和部署软件的方式是不可能的，而部署新版本可能要花费数月甚至数年。
DoD认识到，迫切需要重新思考软件开发实践和文化，寻求新的方法和最佳实践。
DevSecOps就是这样一种最佳实践。它是一种软件工程文化，结合了一套工具和行业最佳实践，将软件开发(Dev)、安全(Sec)和运行(Ops)结合在一起。DevSecOps的主要目标是自动化和监控软件开发、网络安全和运行的所有步骤，并为应用程序提供“内置”安全。
DevSecOps在开发人员、测试人员、安全团队和运维团队之间架起了桥梁；它改善了团队之间的沟通和协作，其目标是更快、更高效地交付。将DevSecOps与敏捷开发相结合是另一个行业最佳实践。DevSecOps有助于实现敏捷性，这意味着旧式的“大爆炸”交付将被更小但更频繁的交付所取代，从而实现更快的变更和更灵敏的开发过程。理想情况下，每一个小的交付都是通过一个完全自动化的DevSecOps管道进行的，只需最少的人工干预，可以加快新功能和更新功能的部署和安全性。
DevSecOps在交付时间、代码质量和代码安全性方面提供了比传统软件生命周期方法更好的改进。在DevSecOps中，通过自动化单元、功能测试、集成测试和安全测试，测试和安全都被“左移”。
DoD推荐DevSecOps作为整个部门未来软件开发工作的最佳实践。这将需要国防部内部的文化变更，新的政策、对政府人员的再培训、新的采购方法等等。
DevSecOps将重新激活国防部的软件开发，并为国防部迅速实施机器学习、自主武器等新功能做好准备，这些功能都依赖于高质量、安全、经过认证的软件。现代网络战要求具备快速、安全地更新软件产品的能力。DevSecOps是实现这一目标的最佳方式。
国防部转向DevSecOps，主要原因有两个：
提高了安全性
能够更迅速地应对安全威胁；
内嵌安全到应用程序中。
允许更加快速的更新软件
加快部署速度；
让新功能更快地进入现场；
应对网络战争等新威胁；
不能在部署速度上落后于对手。
实施成功的DevSecOps方法有几个关键原则：
消除瓶颈(包括人工瓶颈)和手动操作。
使尽可能多的开发和部署活动自动化。
采用从规划和需求到部署和运营阶段的通用工具。
利用敏捷的软件原则，支持小规模、增量、频繁的更新，而不是更大、更零星的发布。
在整个软件生命周期中应用开发、网络安全和运营的跨职能技能集，采用并行的持续监控方法，而不是等待依次应用每个技能集。
必须度量和量化底层基础设施的安全风险，以便了解软件应用程序的总体风险和影响。
部署不可更改的基础设施，如容器。不可变基础设施的概念是一种IT战略，在这种战略中，部署的组件被整体替换，而不是就地更新。部署不可变的基础设施需要对通用基础设施组件进行标准化和仿真，以实现一致和可预测的结果。
02 DevSecOps概念
DevSecOps描述了一个组织的文化和实践，使组织能够在开发人员、安全团队和运营团队之间架起桥梁;通过协作和敏捷的工作流程改进流程;通过技术推动更快、更安全的软件交付;并实现一致的治理和控制。没有统一的DevSecOps实践。国防部中每个组织都需要根据其独特的流程、产品、安全需求和运营流程来调整其文化和DevSecOps实践。采用DevSecOps要求组织改变其文化、演进现有流程、采用新技术并加强治理。
概念模型
下面的概念模型显示了本文中描述的一些最重要的概念以及它们之间的关系。这应该有助于澄清这些关系。当沿着箭头阅读文本时，请遵循箭头的方向。因此，DevSecOps生态系统包含一个或多个软件工厂，每个软件工厂包含一个或多个管道。该图还显示，每个软件工厂只包含一个CI/CD Orchestrator，并且许多软件工厂使用DCAR。
DevSecOps软件生命周期
DevSecOps软件生命周期阶段如图所示，共有9个阶段：计划、开发、构建、测试、发布、交付、部署、操作和监控。安全嵌入到每个阶段。
使用DevSecOps，软件开发生命周期不是单一的线性过程。瀑布流程的“大爆炸”式交付被小而频繁的交付所取代，因此更容易在必要时改变路线。每一次小型交付都是通过完全自动化或半自动流程来完成的，只需要最少的人为干预即可加速持续集成和交付。
DevSecOps生命周期具有很强的适应性，并且有许多反馈循环来驱动持续改进。
DevSecOps分层
DoD的视角中，DevSecOps由小到上分为5层：基础设施层、平台层、CI/CD层、服务网格层、应用层，不同的团队关注自身相关的层级。
DevSecOps支柱
DevSecOps由四个支柱支持：组织、流程、技术和治理。
对于每个国防部组织，DevSecOps的实践都是从组织内的高级领导对DevSecOps理念的认可开始的。这将导致组织文化的改变，同时开发新的协作流程、技术和工具，以使流程自动化并应用一致的治理。一个项目必须在所有四个方面都取得进展才能取得成功。
组织
组织应遵循以下理念和想法，并将其纳入日常活动和软件生命周期管理过程。
改变组织文化，以采取整体观点，并共担软件开发、安全和运维的责任。用DevSecOps概念和新技术培训员工。逐步获得所有利益相关者的认同。
打破组织孤岛。在软件生命周期的所有阶段增加团队沟通和协作。
可操作的安全和质量保证（QA）信息，如安全告警或QA报告，必须在每个软件生命周期阶段自动提供给团队，以使协作行动成为可能。
通过在整个组织内分享正面和负面事件的事后报告，建立安全文化。团队应利用成功和失败作为学习机会，改进系统设计，强化实施，并增强事件响应能力，作为DevSecOps实践的一部分。
进行许多小的、增量的更改，而不是较少的大更改。较小更改的范围更有限，因此更易于管理。
接受反馈和用户驱动的更改，以响应新的、新兴的和不可预见的需求。
为持续的代码重构制定计划和预算，以确保不断减少累积的技术债务。
流程
根据任务环境、系统复杂性、系统架构、软件设计选择、风险容忍度和系统成熟度，每个程序的软件生命周期都有自己独特的管理流程。
例如，假设一个成熟的Web应用软件系统采用了微服务设计。它的开发、试生产和生产环境都在同一个云上。测试过程是完全自动化的。该系统可以有一个自动执行开发、构建、测试、安全和交付任务的流程流，以便在没有人工干预的情况下将更新快速推送到生产中。另一方面，复杂的任务关键型嵌入式系统，如武器系统，可能有不同的过程，需要一些不能完全自动化的测试。该系统的软件生命周期过程将与web应用程序系统的过程显著不同。
要成功地采用DevSecOps过程，请在多个迭代阶段中实现它。先从一些易于自动化的任务开始，然后逐步建立DevSecOps功能并调整流程以与之匹配。下图说明了这个概念；它显示了一个软件系统可以从一个连续的构建管道开始，这个管道仅在开发人员提交代码之后自动执行构建过程。久而久之，它就可以进展到持续集成、持续交付、持续部署、持续运营，最后持续监控，实现DevSecOps的全闭环。一个程序可以从一个合适的过程开始，然后逐步发展。过程改进是频繁的，它响应反馈来改进应用程序和过程本身。
流程设计没有“一刀切”的解决方案。每个软件团队都有自己独特的需求和约束。以下是指导流程设计的一些最佳实践：
1.流程设计是多学科团队的集体努力。
2.大多数流程应该通过工具和技术实现自动化。
3.DevSecOps生命周期是一个迭代闭环。从小处着手，循序渐进，力求持续改进。必要时，根据流程的成熟度级别和团队对自动化的信任水平，在控制门设置人工干预。从更多的人工干预开始，并尽可能地逐渐减少。
4.AO应该考虑尽可能地使操作权限(ATO)过程自动化。
技术
许多DevSecOps工具可以自动执行软件生命周期中的许多任务，而无需人工参与。其他DevSecOps工具，如协作和通信工具，可以促进和刺激人与人之间的交互以提高生产力。一些DevSecOps工具旨在帮助处于特定生命周期阶段的活动。例如，用于开发阶段的集成开发环境（IDE）DevSecOps插件，或用于构建阶段的静态应用程序安全测试工具。大多数工具都有助于一组特定的活动。添加到工件库中工件的标记有助于保证同一组工件沿着管道一起移动。后面将介绍各种DevSecOps工具。
DevSecOps环境的实例化可以从配置文件进行编排，而不是一次手动设置一个组件。基础设施配置文件、DevSecOps工具配置脚本和应用程序运行时配置脚本称为基础设施即代码（IaC）。采用与IaC相同的方法，安全团队将安全策略直接编程到配置代码中，并将安全合规检查和审计作为代码来实现，这称为安全作为代码（SaC）。IaC和SaC都被视为软件，并经历了严格的软件开发过程，包括设计、开发、版本控制、同行评审、静态分析和测试。
技术和工具在DevSecOps实践中扮演着缩短软件生命周期和提高效率的关键角色。它们不仅使软件生产自动化成为软件工厂的一部分，而且还允许操作和安全流程编排。
治理
治理在整个生命周期中积极评估和管理与任务计划相关的风险。治理活动不会在ATO之后停止，而是在整个软件生命周期中继续进行，包括操作和监视。DevSecOps可以促进和自动化许多治理活动。
管理架构
DevSecOps的管理目标必须是“自上而下”和“自下而上”，以平衡更大的战略目标。研究表明，高层领导的认同对成功至关重要。但员工层面的认同对于产生主人翁意识、鼓励适当实施与治理相关的流程以及使团队成员能够支持持续的流程改进也很重要。持续的流程改进—在任何可能的时候和任何可能的地方寻找简化和自动化的机会—对于治理跟上快速变化的世界是至关重要的
DevSecOps的管理目标必须是“自上而下”和“自下而上”，以平衡更大的战略目标。研究表明，高层领导的认同是成功的关键。但是，员工层面的认同对于产生主人翁意识、鼓励与治理相关的流程的适当实施以及使团队成员能够支持持续的流程改进也很重要。持续的流程改进-随时随地寻求简化和自动化的机会-对于治理跟上快速变化的世界至关重要。
国防部早期的DevSecOps工作利用并采用了商业最佳实践。该文件确定了下一代治理(NGG)的五项基本原则
1.以使命纪律运行IT：将需求与组织的使命联系起来。每一项行动都应该与使命相一致。如果不是，则应通过持续的流程改进来执行评估，以解决如何将行动与使命相关联。
2.投资于自动化：实现一切可能的自动化，包括行动、业务流程、决策、审批、文档等。自动化，包括设计、接口、功能和安全测试，以及它们的相关文档，创建了记录构件，这些构件提供了风险管理框架(RMF)所需的证据正文，并在需要时用于历史审核。
3.拥抱适应性：接受随时可能需要的更改，并且所有选项都可以实现它。失败要快，失败要小，失败要向前。向前失败的一个例子是当开发人员发现某个版本不起作用时。然后，开发人员不应使用以前的软件将服务器恢复到部署前的状态，而是应该进行足够离散的更改，以便他们可以通过较新的版本修复并解决问题。
4.提高透明度：提供整个组织的开放访问，以查看自动化流程中发生的活动和自动生成的记录构件。透明度为共享想法和开发解决方案创造了一个环境，这些解决方案由主题专家(SME)或来自整个企业的领导以跨职能团队的形式组成，以避免“竖井效应”。当团队由所有有代表性的利益相关者组成时，团队拥有建立任务系统所需的技能和克服所有遇到的挑战所需的集体创造力。
5.固有责任：向下推责任或将责任下放到最低层：
战略：这与变革控制委员会(CCB)或技术审查委员会(TRB)有关；它涉及“重大变革”的非结构化决策。这些不常见的高风险决策有可能影响组织的战略和使命。
可操作性：(各种Scrum)横切的、半结构化的决策。在这些频繁且高风险的决策中，作为协作的端到端决策流程的一部分，一系列相互关联的小决策由不同的团队做出。
战术：(全球企业合作伙伴(GEP)/产品所有者/开发人员活动)授权的结构化决策。这些频繁且低风险的决策由个人或工作组有效处理，其他人的投入有限。
下图总结了这5条原则。
授权官员
国防部指令(DODI)8510.01是所有国防部信息系统和平台信息技术系统必须遵循的终极治理政策和规定的流程。它正在修订中，以下与DevSecOps相关的治理信息将包含在未来版本中。
对于新的DevSecOps软件工厂实例和生产运营环境的初始设置，RMF流程遵循企业级流程。评估和授权(A&A)应继承底层基础设施(例如，国防部云临时授权)和国防部企业加固容器的认证和授权，而无需重新认证。该计划应与底层基础设施提供商签订正式的服务级别协议(SLA)，说明包含哪些服务以及可以继承哪些授权。
这会影响适用评估过程的状态，并为继承操作环境和应用程序做好准备。一旦实例获得授权并可操作，功能组件的特定AO或项目的当地AO具有对环境进行持续授权的资格。功能区的专业AO或项目的本地AO负责任务申请的持续授权。
DevSecOps生态系统
DevSecOps生态系统是在工具上创建和执行的工具和流程工作流的集合，以支持整个DevSecOps生命周期中的所有活动。如图所示，DevSecOps生态系统由三个子系统组成：计划、软件工厂和生产运维。DevSecOps生态系统与外部企业服务交互以获得所有依赖支持，并与企业和本地AO交互以获得操作授权。
DevSecOps管理团队负责管理生态系统工具和自动化流程工作流。任务应用团队专注于使用生态系统的开发、测试、安全和操作任务。
计划
计划阶段包括帮助项目管理时间、成本、质量、风险和问题的活动。这些活动包括业务需求评估、项目计划创建、可行性分析、风险分析、业务需求收集、业务流程创建、系统设计、DevSecOps设计和生态系统实例化等。当DevSecOps生命周期循环时，计划阶段重复。作为开发的第一件事，为关键业务需求开发一个最小可行产品（MVP）是一个最佳实践。然后尽快进入反馈循环过程；这是精益启动方法论中的建议。DevSecOps设计创建了DevSecOps流程和控制门限，它们将指导整个生命周期的自动化。DevSecOps生态系统工具将促进流程自动化和一致的流程执行。
DevSecOps规划子系统使用一组通信、协作、项目管理和变更管理工具来支持规划阶段的活动。在此阶段，流程工作流不是完全自动化的。计划工具有助于人员交互并提高团队工作效率。
软件工厂
如图所示，软件工厂包含多个管道，这些管道配备了一组工具、流程工作流、脚本和环境，以最少的人工干预生成一组软件可部署构件。它自动化了开发、构建、测试、发布和交付阶段的活动。软件工厂中设置的环境应该使用脚本编排，脚本包括IaC和SaC，并在各种工具上运行。软件工厂必须设计成支持多租户，并使多个项目的软件生产自动化。一个国防部组织可能需要为不同类型的软件系统(如Web应用程序或嵌入式系统)提供多条管道。
工厂从开发应用程序代码和IAC的开发团队、开发测试脚本的QA团队，以及使用合适的IDE开发SAC的安全团队开始。整个软件工厂应该利用符合OCI标准的容器和DoD加固容器(只要可用)。一旦商用现货（COTS）、政府现货(GOTS)或新开发的代码和脚本被提交到软件工厂的代码库中，装配线自动化就开始了。
可能有多个CI管道实例作为装配线。每一个都用于特定的应用程序子系统，例如用于Web前端的JavaScript装配线、用于数据分析的Python或R装配线或用于后端应用程序的GoLang装配线。CI装配线通过构建代码和合并来自本地构建仓库的依赖项（如库）来指导子系统进行持续集成。此外，它还在开发和测试环境中进行测试，如单元测试、静态代码分析、功能测试、接口测试、动态代码分析等。
通过CI装配线控制门限策略的子系统将进入预生产环境进行系统集成。CD装配线从此处开始接管控制权。在此环境中执行更多的测试和安全扫描，如性能测试、验收测试、安全合规性扫描等。如果符合控制门限策略，CD装配线将发布最终产品包并将其交付到已发布的制品库。
使用DevSecOps软件工厂开发应用程序带来了很多好处：
提高了软件产品的一致性和质量
缩短了上市时间并提高了生产效率
简化了管理
运维
在生产环境中，发布的软件从发布的制品仓库中提取并部署。执行运维、运维监控和安全监控。生产工具运维旨在简化和自动化部署、运维和监控活动。应根据系统功能需求及其对生产环境基础设施的适用性来选择工具。
外部系统
DevSecOps生态系统本身和程序应用程序依赖于一些国防部企业服务来获取必要的基线工具、应用程序依赖项和安全服务来运行。
国防部集中式制品仓库库(DCAR，DoD Centralized Artifact Repository)保存了加固VM映像和加固的OCI合规容器映像：DevSecOps工具、容器安全工具和通用程序平台组件(例如COTS或开源产品)，国防部程序软件团队可以将其用作简化授权过程的基线。
国防部通用安全服务是国防部企业级通用服务，可促进网络安全实施和IT管理。一个安全服务将执行流量和过滤，以保护任务飞地(mission enclave)和任务应用程序。一些安全服务示例包括防火墙、入侵检测系统(IDS)/入侵防御系统(IPS)、恶意软件检测、数据防泄露、主机安全、日志/遥测聚合和分析以及身份、凭证和访问管理(ICAM)。网络安全服务提供商(CSSP)将提供附加服务，包括攻击感知和告警(ASW)、取证媒体分析(FMA)、保障漏洞管理(AVM)、事件报告(IR)、事件处理响应(IHR)、信息作战防御态势(INFOCON)、网络保护态势(CPCON)、恶意软件通知保护(MNP)和网络安全监控(NSM)。
DevSecOps生态系统为初始软件工厂ATO和初始应用程序ATO与企业AO交互，并为应用程序的连续ATO与本地AO交互。
DoD企业DevSecOps架构
下图为DoD企业DevSecOps架构。每个程序都可以在任何云上拥有自己的DevSecOps平台实例。可以使用单个命令安装，也可以部署在任何云上。提供资产的完全可见性、安全性、漏洞状态等，可以集成到现有的网络安全共享服务中。
03 DevSecOps工具和活动
国防部在DevSecOps生态系统各个阶段使用了丰富的工具，既有研发、测试和运维工具，也有安全工具。
国防部采用的技术栈如下：
对于研发类工具这里就不做详细描述了，我们重点关注安全工具，下面以表格形式详细列出各个阶段采用的安全工具。工具表中的基线(baseline)列有两个值：
最小可行产品(MVP)：工具是否必须在DevSecOps生态系统MVP中可用作为阈值。
目标(Objective)：工具是否是随着生态系统成熟而达到的目标。
DevSecOps生态系统各个阶段的主要活动如下：
安全性不是DevSecOps生命周期的单独阶段；相反，安全活动发生在所有阶段。
DevSecOps安全实践促进了整个应用生命周期的自动化风险画像、监控和缓解。DevSecOps生态系统中所有阶段的安全活动如下图：
威胁建模：识别潜在威胁、弱点和漏洞。定义缓释计划。
安全代码开发：安全策略实施脚本编码。
代码提交扫描：在将更改推送到主仓库之前，检查更改中的敏感信息。如果发现可疑内容，通知开发人员并阻止提交。
提交前代码静态扫描：在开发人员编写代码时对其进行扫描和分析。通知开发人员潜在的代码缺陷并建议补救措施。
容器或虚拟机加固：加固生产部署的交付物。
静态应用安全测试和扫描：对软件系统执行SAST静态安全测试。
依赖项漏洞检测：识别开源依赖组件中的漏洞。
动态应用安全测试和扫描：对软件系统进行DAST或IAST测试。
人工安全测试：例如渗透测试，它使用一套工具和程序，通过向系统注入授权的模拟网络攻击来评估系统的安全性。CI/CD 编排器不会自动化进行该测试，但测试结果可以作为管道中的控制点。
容器策略实施：检查已开发的容器以确保它们符合容器策略。
合规扫描：执行合规审计。
数据库安全测试：执行安全扫描和安全测试。
发布通过/不通过决策：这是配置审核的一部分；决定是否将制品发布到生产环境的制品库中。
部署后安全扫描：系统和基础设施安全扫描。
系统安全监控：监控所有系统组件的安全性；安全漏洞评估；系统安全合规性扫描。
数据库监控和安全审计：数据库性能和活动监控与审计。
04 DoD企业DevSecOps容器服务
DoD企业DevSecOps容器服务创建DevSecOps加固容器，并向国防部程序提供加固容器访问服务，以实例化其自身的DevSecOps生态系统。
上图说明了国防部企业DevSecOps容器服务体系结构。它包含一个国防部企业DevSecOps容器工厂和一个国防部集中式制品存储库(DCAR)。容器工厂将公共容器镜像作为输入，并自动执行容器加固过程，以产生加固的容器镜像。DCAR存储强化的容器图像，并允许国防部程序访问这些镜像。
国防部企业DevSecOps容器工厂
容器工厂生产DevSecOps工具的容器容器。容器工厂必须尽可能实现加固过程的自动化。它通过在专门为强化DevSecOps工具容器而配置的软件工厂实例中利用CI/CD管道来实现这一点。
国防部加固容器
国防部加固容器是符合开放式容器镜像（OCI）的镜像，它是安全的，并符合国防部容器加固安全要求指南。
容器镜像应遵循OCI镜像格式规范，以确保可移植性。每个容器加固都包含“全局配置”，其中包含所有安全加固配置。打包的容器使用完整性元数据（如数字签名或数字哈希）进行标记。标签可以实现为绑定到对象的元数据，或者实现为与对象关联的文件中的属性。可以更改某些配置值以供本地使用，例如DNS位置。这些“本地配置”值不在integrity标记的范围内，并且不会“破坏”加固容器的信任链。
加固容器工厂生产以下类型的容器：
DevSecOps CI/CD管道工具的加固容器
Sidecar Container Security Stack容器，用于运行时环境中的容器安全
通用容器(如操作系统、数据库、Web服务器等)，用作程序开发基线
容器加固过程
容器加固过程，包括所需的文档、加固容器的保障和网络安全要求，在国防部企业DevSecOps计划加固容器中有详细描述。基本流程如下图：
选择容器基础镜像
基础镜像是来自供应商或开放源码社区的容器镜像；它被用作创建加固容器映像的起点。在不创建分叉的情况下使用基本镜像，以实现与其更新的直接耦合。容器应该从各自的国防部加固的基本OS STIG映像开始构建。
加固容器
容器工厂使用给出的一组说明来加固容器，确保符合国防部的要求。在不同版本之间尽可能多地重用这些指令，以便在不同版本之间加固是一致的。在不同版本之间尽可能多地重复使用指令，以便在不同版本之间实现一致的加固。新版本可能会带来新功能，这可能需要额外的加固。
国防部集中式容器源代码仓库库(DCCSCR)用于存储构建容器镜像、相关校验和和各种文档的指导文件。源代码仓库集加固中托管，因此加固人员可以存储代码并利用CI/CD管道(容器工厂)。这为容器加固过程和DCAR仓库提供了支持。
使用CI/CD编排工具；将DCCSCR文件夹内容下载到管道中，并使用指令文件构建容器。
然后，CI/CD管道将运行所需的容器加固扫描器，扫描容器镜像像。根据容器加固扫描器的检测结果，根据需要添加指令以缓解问题。重建并重新扫描，直到发现的问题得到缓解或接。
存储加固容器
DCAR用于存储加固容器、相关校验值和以及各种文档。仓库将集中托管。每个容器在DCAR中都有自己的文件夹。子文件夹应用于版本控制。
在DCAR中存储加固容器和校验和。它也将被标记为“预生产”，直到制品收到ATO，在这种情况下，它将被标记为“生产”。
文档
为加固容器提供的内容和文档将包括：
容器描述、如何部署容器、容器提供的功能和接口。
脚本，包括用于构建容器的说明文件，以及用于部署和扩展加固镜像或容器的相关配置文件
安全测试结果，包括发现的问题、误报和建议的缓解计划。
已接受的风险，包括尚未解决的严重和高危问题的行动计划和里程碑（POA&M）。
自上一版本以来重大变更的变更日志。
容器中包含所有产品的可读许可证。COTS许可密钥将不包括在内，它们需要单独获取。
持续工程化
加固容器工厂CI/CD管道搜索并下载供应商发布的或开源社区仓库中发布的新基础映像，并运行2）中的步骤。一旦新镜像发布到开源仓库中，这些步骤就会自动触发。如果构建通过了所有扫描，它应该将新容器自动存储到DCAR中，在那里它将被标记为“预生产”。如果构建未能通过任何扫描，它还会自动通知团队。
网络安全
工厂生产的加固容器应满足相关的网络安全要求，包括NIST SP 800-53、NIST SP 800-37、国防部DISA安全技术实施指南（STIG）和安全需求指南（SRG）以及行业最佳实践。
国防部集中制品库
DCAR保存国防部企业DevSecOps容器工厂生成的国防部加固容器镜像。国防部程序DevSecOps团队可以利用这些来实例化他们自己的DevSecOps生态系统和软件工厂。DCAR还包含用于基本操作系统、Web服务器、应用服务器、数据库、API网关、消息总线和附加企业功能的国防部加固容器，供国防部程序软件团队用作程序系统部署基线。为不同版本的基础镜像创建单独的加固容器镜像。DCAR加固的容器镜像受版本控制。
这些加固的容器，以及安全认证互惠，极大地简化和加快了获得连接批准(ATC)或操作授权(ATO)的过程。
DCAR提供了允许DoD程序(包括经批准的Dod承包商) 从仓库中搜索、列出信息并从仓库中下载构件的功能，以便在经批准的环境中进行DoD软件开发。
05 DevSecOps生态系统参考设计
下面将介绍两个软件工厂参考设计。
一种是基于DoD Enterprise DevSecOps Container Service产品，使用DCAR的DevSecOps工具强化容器创建软件工厂。
另一种是基于CSP提供的国防部授权的云DevSecOps服务。
还会介绍通过利用DCAR中的容器安全工具在生产环境中实现容器化应用程序的安全操作。
容器化软件工厂
可以使用DCAR中提供的一组DevSecOps加固容器来实例化容器化的软件工厂。这些企业容器是预先配置和保护的，以减轻认证和认可负担，并且通常以预定模式或管道的形式提供，需要有限的配置或不需要配置。
下图展示了一个容器化软件工厂参考设计。软件工厂构建在底层容器编排层和主机环境上。它生产国防部的应用程序。这些应用程序使用来自DCAR的不同的加固容器集，而不是用于创建软件工厂的容器集。
国防部项目组可能已经实现了DevSecOps平台。其中一个痛点是维护这个平台。强烈建议在对现有平台进行增量更新时，该项目组将功能迁移到国防部企业级DevSecOps加固容器。对于国防部企业加固容器不可用或需要自定义策略的情况，鼓励项目组与国防部企业DevSecOps项目办公室共同创建、维护加固容器，并将其交付给DCAR。
托管环境
参考设计不限制软件工厂托管环境，该环境可以是经国防部批准的云服务提供商、国防部数据中心，甚至是内部部署的服务器。托管环境以物理或虚拟形式提供计算、存储和网络资源
容器编排
为了支持容器化软件工厂工具，底层容器编排必须使用CNCF认证的Kubernetes，并支持符合OCI的容器。CNCF认证的Kubernetes编排容器，与底层托管环境资源交互，高效地协调开发、测试和预生产中的大规模节点集群。容器编排层有两个方案，如图所示：
在方案A中，项目组负责使用COTS解决方案构建和维护容器编排层(CNCF认证的Kubernetes)。容器编排层可以部署在国防部授权的云环境、国防部数据中心或裸机服务器上。容器编排系统组件在该托管环境中受DoD策略的监控和安全控制，如DoD云计算安全需求指南(SRG)和DISA针对云环境的安全云计算架构(SCCA)。
在方案B中，项目组使用CSP容器服务，该服务必须具有国防部临时授权，并且必须基于CNCF认证的Kubernetes。
使用加固容器的软件工厂
软件工厂利用技术和工具自动执行DevSecOps生命周期计划阶段定义的CI/CD管道流程。关于CI/CD过程应该是什么样子以及必须使用什么工具没有“一刀切”或硬性规定。每个软件团队都需要接受DevSecOps文化，并定义适合其软件系统架构选择的流程。工具链选择特定于软件编程语言选择、应用程序类型、每个软件生命周期阶段的任务以及系统部署平台
软件工厂建设本身遵循DevSecOps理念，并经历自己的设计、实例化、验证、运行和监控阶段。它在应用程序生命周期迭代过程中不断发展。下图说明了软件工厂阶段、活动以及与应用程序生命周期的关系。必须在软件工厂各个阶段嵌入安全。
前面所述的软件工厂的参考设计图，包括用于开发、构建、测试、安全、发布和交付用于生产部署的软件应用程序的工具和流程工作流。所有工具都基于国防部企业级DevSecOps加固容器。将代码提交到代码仓库中将启动自动化工厂CI/CD管道工作流。CI/CD编排器通过协调不同工具执行各种任务来执行工作流。
有些任务由一套DevSecOps工具完成，如构建、静态代码分析、单元测试、发布制品、构建容器镜像等。其他任务可能需要底层容器编排层的帮助，如部署应用程序到测试、试生产和最终生产环境。一些测试和安全任务可能需要人工参与。
DoD应用程序
术语“DoD应用程序”指的是由信息系统托管的DoD软件程序，它广泛地从依赖于基础设施的传统单体应用程序传播到与基础设施无关的现代模块化应用程序。大多数系统都在棕色地带，使用传统应用程序或混合使用传统应用程序和现代应用程序。在设计软件工厂时，程序应该考虑其应用程序的性质和部署环境。建议利用绞杀者模式（Strangler Pattern）将传统应用程序重构为现代微服务/容器化应用程序。
国防部应用程序环境的所有阶段(开发、测试、试生产、生产)都受到国防部公共安全服务的安全控制。
在重构遗留代码或编写新代码时，强烈建议利用DoD加固容器或加固脚本来促进应用程序的ATO。
使用云DevSecOps服务的软件工厂
国防部授权的云可能已经或即将提供DevSecOps服务，如代码库、制品库、构建服务、代码部署服务等。程序应该考虑使用这些本地托管服务来替代自建和自维护的DevSecOps工具集，但他们应该理解使用它们可能会导致受限制于CSP。CSP负责维护每项服务的服务提供和国防部临时授权(PA)。程序仍需要遵循软件工厂生命周期并执行设计、DevSecOps服务选择而不是工具选择、CI/CD管道流程工作流自动化、验证工作流、运行和监控工作流。
另一个考虑因素是CSP可能无法提供完整的解决方案集。对于无法使用带有DoD PA的DevSecOps服务的功能，应使用提供适当功能的相应DoD 企业加固容器。容器运行时需要CNCF认证的Kubernetes容器编排服务。软件工厂说明了同时使用云DevSecOps服务和自我维护的安全工具的软件工厂。
无服务器支持
所谓的“无服务器计算”在DoD中正变得越来越流行，并且在工业中得到了广泛的使用。这是一种平台即服务（PaaS），有时也称为功能即服务（FaaS）。尽管有“无服务”的绰号，但FaaS仍然需要服务器，但是开发人员不必担心服务器，而只需担心如何向其部署代码，如何设置自动扩展以及其他部署任务。这使开发人员可以将精力解放于代码上。
下图展示了FaaS可以降低基础架构即服务（IaaS），容器即服务（CaaS）或某些平台即服务（PaaS）产品的开发复杂性并提高效率。尽管软件即服务（SaaS）产品更加高效，并且在满足要求时易于使用，但SaaS通常只专注于少数功能，不能提供国防部开发定制应用程序所需的灵活性。另一方面，好的FaaS确实提供了这种灵活性，尽管某些应用程序将需要IaaS更高的灵活性。
FaaS概念已进入Kubernetes环境。基本概念是向FaaS提供一些代码，然后FaaS将根据该代码构建镜像，并使其在Kubernetes上运行。
FaaS必须具有以下功能：
1）构建-从源代码构建容器
使用容器镜像作为部署单元
提供源代码，构建代码并创建容器来容纳它
2）服务–运行由构建创建的容器，并根据需要自动按比例放大或缩小
使用CNCF Kubernetes作为底层的容器编排层
自动向上扩展（假定已编写代码允许这样做）
自动向下扩展一直到归零
新版本的逐步推出
群集内的网络路由，以及到群集的入口连接
3）事件–允许功能/应用程序发布和订阅事件流，以启用松耦合的，事件驱动的系统
事件的通用订阅，交付和管理
将事件绑定到函数或容器
通过和请求超文本传输协议（HTTP）调用时触发函数
每天自动将少量事件扩展为实时流
Knative是为Kubernetes实现FaaS的一种流行的开源产品。另一个开源产品是Kubeless。DevSecOps软件工厂必须提供Knative支持。他们还可能为Kubernetes支持Kubeless或其他FaaS。
应用程序安全运营
下面重点介绍生产环境中的软件应用程序生命周期。持续部署，持续运营和持续监控是简化和安全运行的关键。
持续部署
持续部署是由已发布的制品成功交付到制品库触发的，并且可以根据程序应用程序的性质在人工干预下进行控制。
持续部署的典型活动包括但不限于：将新软件版本部署到生产环境、应用必要的基础结构和安全配置更改，运行冒烟测试以确保基本功能正常运行以及执行安全扫描。每个活动都由特定工具或配置/编排脚本完成。工具和配置/编排系统的选择取决于应用程序和生产平台。例如，如果应用程序是容器化的，并且生产平台使用Kubernetes，则编排由Kubernetes完成。在这种情况下，配置脚本将是Kubernetes Operators或Helm chart。另一方面，如果应用程序是基于VM的，则配置/编排工具可以是Chef，Puppet或Ansible。
持续部署与其他DevSecOps组件进行交互，例如用于获取新版本的制品库，用于记录部署事件的日志存储和检索服务，以及用于记录所有部署问题的问题跟踪系统。首次部署可能涉及繁重的基础架构配置，依赖项配置（例如监控工具，日志记录工具，扫描工具，备份工具等）以及外部系统连通性（例如DoD通用安全服务等）。
持续运营
持续运营是持续部署的延伸。它由成功部署到生产环境触发，因此它运行最新的稳定软件版本。
持续运营的活动包括但不限于：系统打补丁、合规性扫描、数据备份、发生故障时的系统恢复以及通过负载均衡和扩展进行的资源优化。促进活动的工具的选择取决于应用程序和环境。资源优化在很大程度上依赖于底层平台。容器化应用程序可以依赖Kubernetes自动跨集群节点扩展容器。另一方面，没有容器的基于VM的应用程序可以依赖底层CSP的扩展服务。
持续运营与日志记录系统、问题跟踪系统和底层基础设施平台交互。
持续监控
持续监控是对持续操作的延伸。它持续清点所有系统组件，监控所有组件的性能和安全性，并记录应用程序和系统事件。
上图展示了一个简化的监控、日志记录、日志分析和告警示例流程，该流程也适用于非容器环境的部署。该流程开始于Kubernetes Pod级别的应用程序日志记录、计算资源监控、存储监控、网络监控、安全监控和数据监控(容器部署的情况下是应用程序日志记录、计算资源监控、存储监控、网络监控、安全监控和数据监控)，或者是VM部署的单个子系统级别的监控。每个应用程序都需要确定如何将其划分为子系统、子系统的数量以及子系统内的特定监控机制。
每个子系统内的安全工具(例如，Sidecar Container Security Stack)将汇总从监测收集的事件日志，并将其转发到平台上的本地集中汇总日志数据库。这应该在Kubernetes集群内自动执行。在通过程序应用配置的日志过滤器后，聚合的日志将被进一步转发到DoD公共安全服务中的日志/遥测分析。该程序的本地日志分析功能将分析聚合日志并生成事件告警和报告。事件将被转发到任务项目事件管理系统，以便生成事件解决的变更请求。事件管理部门应就事件向责任人员发出告警或通知。可以创建变更请求以解决该事件。这些操作使DevSecOps管道成为从安全运行到计划的完整闭环。
Sidecar 容器安全栈
DevSecOps和基于容器的Kubernetes运行时环境支持的一个新服务是Sidecar容器安全栈（SCSS）。此安全栈支持：相关和集中的日志、容器安全、东西向流量管理、零信任模型、白名单、基于角色的访问控制（RBAC）、持续监控、使用CVE的基于签名持续扫描、运行时行为分析和容器策略实施。
使用SCSS的一个好处是，一旦配置好，Kubernetes就可以自动化注入sidecar，而团队不必做任何事情。
sidecar模式如图所示。容器组或Pod是一组部署在一起的容器。sidecar是在Pod内与应用程序容器并排运行的容器。
sidecar可以与应用程序容器共享状态。具体地说，这两个容器可以共享磁盘和网络资源，同时它们的运行组件彼此隔离。
sidecar是一种通用的容器模式。Sidecar Container Security Stack有一个sidecar容器，其中包含一个安全栈，以及一些在宿主环境中运行的支持服务，例如日志记录服务。
安全sidecar容器中的安全栈将包括：
日志代理，用于将日志推送到平台集中日志服务。
容器策略实施。这包括确保DCAR容器的加固得到保护，并符合NIST 800-190要求。
运行时防护，既可以进行基于签名的检测，也可以进行基于行为的检测。这也可用于在出现异常行为时发送通知。
漏洞管理。
连接到服务网格(service mesh)的服务网格代理
容器级别的零信任。零信任要求严格控制，决不默认信任任何东西，并始终核实。容器级别零信任的关键方面包括相互传输层安全身份验证(MTLS)、容器之间的加密通信隧道、使用证书的每个Pod的强身份以及列入白名单而不是黑名单。
除了sidecar中的组件之外，还有一些服务支持安全sidecar。其中包括：
特定于程序的日志存储和检索服务。
服务网格。
特定于程序的制品库。
运行时行为分析人工智能（AI）服务。
加固容器的DCAR。
常见漏洞和暴露（CVE）服务/主机的安全性，为安全容器提供CVE。
这些服务与sidecar组件的交互如所示。箭头显示了数据流的方向。紫色的项目是由国防部提供的服务，蓝色表示由国防部提供但由程序实例化和操作的组件。
上图描述了sidecar的另一个视图，以及其他一些DevSecOps组件。同样，箭头显示了数据流的方向，并没有指示所描述的组件之间的所有交互。程序仪表板显示有关应用程序的信息。仪表板部分使用日志可视化服务中的可视化功能构建。紫色和蓝色的项目是国防部提供的服务或组件。但那些穿蓝色衣服的人将被这个计划支持。例如，服务网格作为加固容器提供。类似地，sidecar容器安全栈作为加固容器提供，程序将其安装在每个Pod(容器组)中；这是由Kubernetes自动注入的，无需应用程序开发人员参与。
06 DevSecOps成熟度模型
行业研究表明，组织不可能立即从没有DevOps或DevSecOps过渡到完全成熟的DevSecOps。相反，他们必须经过几个成熟度级别才能实现完整的DevSecOps功能。尽管学习新工具并将其集成到业务流程中是其中的一部分，但这一运动需要时间的很大一部分原因是必须进行文化变革。
为了帮助组织发展其DevSecOps能力和过程，国防部开发了DevSecOps成熟度模型。此模型详细说明了组织可以采取的许多步骤，以逐步提高DevSecOps成熟度级别。该模型结合了多个成熟度模型的内容，包括：
U.S. General Services Administration, "DevSecOps Guide".
Puppet Labs, "Puppet State of DevOps Report 2018," Puppet Labs, 2018.
J. H. a. R. Russell, "The Agile Maturity Model, Applied to Building and Releasing Software," ThoughtWorks Studios, 2009.
国防部DevSecOps成熟度模型划分为9级：
DevSecOps成熟度模型每一级的详细描述如下：
07 总结
本文介绍了DevSecOps的关键概念，描述了DevSecOps生态系统，包括软件工厂和sidecar容器安全栈，并指出了如何建立和使用该生态系统。关于这里描述的组件（如DCAR）的更多细节，可以在其他国防部CIO文档中找到。
迁移到DevSecOps可以提高敏捷性，并加快新功能上线的速度。但这也需要新的政策、流程和文化变革。
文章参考来源：
DoD Enterprise DevSecOps Reference Design
DoD Enterprise DevSecOps Playbook
DoD 其他资料
声明：本文来自DevSecOps联盟，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
