写在前面：
这个系列文档一共有5篇，分别是:
-
国防部企业DevSecOps Strategy Guide
-
国防部企业DevSecOps Fundamentals
-
DevSecOps Fundamentals Guidebook:DevSecOps Tools & Activities
-
DevSecOps Fundamentals Playbook
-
国防部企业DevSecOps Reference Design:CNCF Kubernetes
文档顺序为：
本文是第一篇。
目录
1 总纲
2 文档结构
2.1 DevSecOps战略指南
2.2 DevSecOps基本原理
2.3 DevSecOps参考设计
3 假设
4 DEVSECOPS定义
5 正式承认软件供应链
6 建设软件工厂
7 DEVSECOPS指导原则
7.1 不懈追求敏捷
7.2 软件工厂授权内嵌安全
7.3 集成、自动化&持续端到端测试和监控
7.4 通过“x即代码”设计特征，实现基础设施不可变
7.5 智能云，数据云架构的采用
8 DEVSECOPS流程回顾
9 DEVSECOPS管理和治理
9.1 管理结构
9.2 推荐治理
9.3 评估和授权
10 结论
1 总纲
国防部的许多程序和任务缺少符合行业敏捷标准的软件开发实践。当前的大多数网络安全框架（NIST网络安全框架，ODNI 网络威胁框架，NSA/CSS 技术网络威胁框架v2（NTCTF），MITRE ATT&CK）主要关注生产后的部署攻击平面。而且每个发布周期都变成了一场团队间的艰苦战斗：开发团队验证功能，操作测试和评估团队尝试确认特定功能，运维团队努力安装和操作产品，安全团队附加一些保护机制作为事后补救。国防部需要在开发流程中，实施重视网络安全和生存能力的战略，能够根据业务的要求，提供弹性的软件能力。在这个旅途上，国防部并不孤独，业界通过向DevSecOps（开发、安全、运营）文化的转变，已经将部署摩擦降至最低。
国防部首席信息官和国防部副部长采购和维护办公室（Office of the Under Secretary of Defense for Acquisition and Sustainment (OUSD A&S)）认识到迫切需要使用商业上的新方法及最佳实践，重新思考我们的软件开发实践和文化。DevSecOps就是这样一种最佳实践，能够根据业务的要求，提供弹性软件能力，这也是整个国防部软件现代化的中心论题。DevSecOps是一个被证实的方法，得到商业行业广泛接纳，在国防部内多个新项目中成功实施。DevSecOps是软件现代化、技术转变、推动组织软件开发生态系统更加弹性的核心原则，同时保证网络安全和指标/反馈处于最重要的地位。
DevSecOps软件生命周期方法打造了跨职能团队，统一了历史上不同的发展方向—开发、网络安全、运营。作为一个整体，他们遵循敏捷原则，认为只有在质量、稳定、和安全三者的交互点上，才能实现弹性软件，如图1所示。
采用DevSecOps的好处包括：
-
减少上线的平均时间（mean-time）：减少从新软件功能需求到上线花费的平均时间
-
加快部署频率：加快新的软件发布部署到生产环境的频率
-
减少平均修复时间：产品部署之后，减少从发现问题到解决问题平均时间
-
降低变更失败率：降低新功能导致操作失败的概率
-
全自动化风险管理：良好定义的控制门执行风险描述、监控和缓解，从最初想法到上线过程，每个步骤都要发布工件，并推动进入下个阶段
-
内嵌网络安全：根据有关业务的要求，交付软件更新和补丁
国防部企业DevSecOps战略及其支持文档集，给信息技术能力提供商、IT功能使用者、应用团队，和授权官（Authorizing Official，AO）提供教育、最佳实践和实施及操作指南。
2 文档结构
对DevSecOps的势头和兴趣持续快速扩展到整个国防部和国防部行业基地（Defense Industrial Base，DIB）。国防部DevSecOps早期采用者已经证明了其成熟性。快速跟进者的浪潮又创造了一批具有中等技能水平的实践者，随着新程序探索采用DevSecOps，这些新手实践者正在寻求帮助、指导、术语澄清和最佳实践。不断扩展的生态系统，证明从单个文档向文档集转变的正确性，如图2所示。文档集方法能同时更好地支持新手、中级人员和专家实践者，让他们能快速找到所需要的资料：DevSecOps战略启蒙、接触基本概念、DevSecOps生命周期的简明解释、和/或具有深入技术内容的特定参考设计指南。
2.1 DevSecOps战略指南
《DevSecOps战略指南》（本文档）提供DevSecOps的总纲，建立一组战略指导原则，每个被批准的国防部企业级DevSecOps参考设计必须支持这些原则。本文档主要供PEO（Production Engineering and Operations ，PEO）和任何处在非技术领导岗位的人员使用。
战略指南提倡一个版本化的DevSecOps治理流程，包括一个严格的不断发展的操作授权类型，叫作持续操作授权（Continuous Authorization to Operate，cATO）。持续操作授权基于整个软件供应链网络生存态势，由每一步收集到的实时指标来驱动。当前的方法是根据时间视图中三年一次的快照来授权网络。国防部创新委员会（Defense Innovation Board，DIB）软件采购和实践（software acquisition and practices，SWAP）研究强调软件从来不会完成，对这个陈述的隐含结论是网络安全攻击者永远也不会停止。今天为实现某种级别的网络生存能力所采取的行动，也许明天就不够用了。有必要把DevSecOps参考设计链接到一个特定cATO版本，为了避免老旧的流程可能导致的暴露甚至破坏。
2.2 DevSecOps基本原理
《DevSecOps基本原理》包括相关特定指南手册和战术手册，建立前后一致的命名系统，策划和版本化的技术地图。探索了一系列具体的、可衡量、可实现、相关的、时间限制（SMART）绩效指标，可用来管理和监控一个DevSecOps CI/CD管道。《指南手册》则希望能就某个特定领域，提供深度行业知识和最佳实践。《战术手册》中每个战术用一页纸来说明，结构上包括最佳实践介绍、要点、最后是检查清单或行动要求。基本原理和相关的指南手册及战术手册，常常由国防部企业平台提供商和特定国防部组织DevSecOps团队来使用，他们管理（实例化和维护）特定DevSecOps软件工厂实施。
2.3 DevSecOps参考设计
《DevSecOps参考设计》定义了特定的工具、技术、管道结构和架构。参考设计独立更新版本，必须基于基本原理文档之上，也要借鉴和参考各种指南手册和战术手册。旨在生成一个可组合的参考设计能力，消除冗余或不一致定义。授权参考设计去推动持续改进，采用一个“n-1”支持生命周期的行业最佳实践，保证程序持续现代化，避免停滞的解决方案。国防部程序应用程序团队在开发、保护、运维任务应用时常常采用《DevSecOps 参考设计》。
3 假设
本文档集做出如下假设：
-
对部署新业务方案或推动当前软件系统现代化的组织，从文化和技术的角度来看，首选的解决方案，是部署到已获批准或临时授权（provisionally authorized，PA）的云环境。对武器系统，可能会继续使用环境，但要以促进嵌入式系统硬件环路（hardware-into-loop）测试为前提。
-
随着新的开发能力进入/退出商用产品市场，快速变化的技术要求DevSecOps管道和模式的设计，具有灵活性。
-
网络安全基本部分将在可行的情况下使用云服务提供商（CSP）托管服务能力，团队将积极寻求去集成自动化反馈、补丁、报警和其他授权网络安全措施。
-
《国防部企业DevSecOps参考设计》渴望采用行业最佳实践和标准。每个参考设计必须指定特定的技术，作为支撑软件工厂管道的能力补充。《DevSecOps参考设计》希望比《DevSecOps战略指南》更频繁地迭代，鼓励以接近行业的速度快速创新。他们也必须提供支撑设计的技术能力和技术产品的详细说明。
-
每个国防部企业DevSecOps参考设计将清楚地说明符合某个版本的DevSecOps工具和活动指南，得到批准或临时授权参考设计必须符合事实上采用的软件行业标准主要版本n-1版的要求。这使得在DevSecOps基本原理文档内的通用最佳实践和工具地图随着时间不断发展，防止参考设计不经意间变得过时，面临被暴露和破坏的更大风险。
-
国防部必须承认一个绑定的态势；识别厂商绑定及产品、版本、架构、平台、技能和心理绑定。避免厂商绑定，却没有考虑其他类型的绑定是不明智的。最后，没有什么比心理绑定更危险
-
DevSecOps战略必须有能力扩展到任何需要软件能力的运营要求，包括：
-
业务系统
-
命令和控制系统
-
嵌入式和武器系统
-
情报分析系统
-
自治系统
-
人机协作系统
-
人工智能(AI)/机器学习（ML）
-
网络安全防御和进攻系统
这个战略和在DevSecOps基本原理中共同支持的文化原则，普遍适用于每个国防部企业DevSecOps参考设计。
4 DevSecOps定义
DevSecOps描述了一个组织的文化和技术实践。把他们按这样的方式来排列，帮助组织减少软件开发和安全及运维团队之间的分歧，通过日常协作、敏捷工作流、持续反馈闭环来改进流程。图3直观地描述了DevSecOps不同阶段和理念，每部分的详细说明可见《DevSecOps基本原理》。
使用DevSecOps好几年的探索性程序，已经具体地证明了它的采用能够根据业务的要求，提供弹性软件。如图3所示，通过在每一步集成网络安全，生成的工件和应用程序的网络生存能力都得到了加强。DevSecOps努力交付更快和更安全软件，同时实现持续的治理和控制。
整个文档集的构想承认没有不变的DevSecOps实践或工具，每个国防部组织希望定制自己的文化，让DevSecOps实践符合它自己独特的流程、产品、安全需求和运维过程。DevSecOps平台和他们底层的软件工厂成本很高，鼓励每个国防部组织寻找现有的参考设计平台，使用其自带的持续操作授权（cATO）。接受DevSecOps要求组织改变他们的文化、发展现有流程、采用新技术、加强治理。
5 正式承认软件供应链
软件供应链是一个物流通道，涵盖了所有的硬件、基础设施即服务（IaaS）、平台即服务（PaaS）、软件即服务（SaaS）、技术力量加乘、工具和实践，汇合在一起交付特定的软件功能。一个概念上的软件供应链，如图4所示。
业务系统、武器系统、软件开发和部署的任何地方都存在软件供应链。不考虑导弹中的嵌入式系统，并将其“隔离”或断开非常容易，但这非常幼稚和糊涂。导弹包括被编译的嵌入式软件、包括依赖第三方的库文件、链接到硬件驱动、依赖嵌入式固件的功能。此外，软件的性能可能使用高性能计算（High Performance Computing，HPC）云中运行的模型和仿真软件来测试。
DevSecOps理念跨越软件供应链的多个关联。没有这个物流供应链，DevSecOps无法存在。这个“物流供应链”包括IDE、构建工具、代码仓库、工件库、测试软件套件和许多其他软件，必须协同工作有效运行一个由DevSecOps支撑的软件工厂。当评估软件供应链时，必须考虑整体环境。
在整个软件供应链内，必须使用产品规则，计算一个特定工件和应用程序的网络安全及风险态势。如果编译器是90%安全，代码库90%安全，工件库90%安全，容器编排90%安全，那么整个系统不是90%安全，端到端的生态系统的网络安全水平是0.9*0.9*0.9*0.9，大约65%安全。这就是为什么生成加固的国防部企业DevSecOps参考设计如此重要。DevSecOps目标是在整个软件供应链聚合专家和知识，在每一步都降低风险。只有这样生态系统整体的网络生存能力才会明显提高。为进一步说明这一点，如果一个DevSecOps团队仅仅提高5%安全，把每个阶段安全水平从90%提高到95%，整体网络安全生存能力从65%跃升到81%。
6 建设软件工厂
如图5规范化软件工厂结构图，所描述的规范性示例，软件工厂和软件供应链紧密相连。就像实体工厂，软件工厂包含多条组装线，或者用专业术语来说，管道。每个管道包含和定义了一套工具、流程工作流、脚本和环境，共同生产一套产品质量软件工件。一个软件供应链“有一个”软件工厂，但软件工厂本身并不是整个软件供应链。
和实体工厂一样，自动化是中心议题。软件工厂在多个级别和多个活动上使用自动化，包括DevSecOps生命周期开发、构建、测试和发布及交付阶段。流程中的每个环境都保证安全的情况下，最大程度地实现自动化，使用可运行在各种工具中的基础设施即代码（IaC）和配置即代码（CaC）。一个软件工厂天生为多租户设计，能为多个项目自动化软件生产。
国防部需要多个软件工厂，根据软件系统的特定类型而调整，如web应用或嵌入式系统，也许在硬件回路自动化测试中包括明显数量的硬件。也要求软件工厂运维在不同的信息影响水平（Impact Level，IL），从IL-2到IL-6，甚至更高级别。在向持续操作授权（cATO）转变过程中，每个软件工厂将检查和认证其自己的流程、团队、和存储，导入到持续监控系统。此外，这个转变极大地减轻了为每个软件实现操作授权的初始负担，因为流程和回滚得到认证，导入持续监控架构。
从外部系统引入的工件（“原料”）及随后在软件工厂内生成的增值工件，推向下游消费者，需要更多的协调工作，大部分都是自动化的。软件工厂和他们的运营在《DevSecOps 基本原理》中得到深入说明。
7 DevSecOps指导原则
DevSecOps、推动着这些生态系统的软件工厂、持续操作授权三者结合一起，代表着国防部在根据业务要求，提供弹性软件能力的方向上，巨大的战略转移。这个战略体现在下边的DevSecOps指导原则中，这些原则单独考虑时会显得抽象，但为DevSecOps团队生成特定国防部企业参考设计和/或基于其工作创造了保护。每个指导原则将被展开，明确地解释意图和期望。DevSecOps指导原则如表1所示。
|
表1 DevSecOps 指导原则
这些指导原则代表采用DevSecOps时，建立通用术语和版本化方法的起点。《DevSecOps基本原理》文档构造在这些指导原则之上，正式确定了DevSecOps生命周期的每个阶段。当DevSecOps团队一部分和必需及更好的工具被认为是一个团队时，《DevSecOps工具和活动指南手册》定义了个人在每天执行的活动。此外，每个DevSecOps参考设计基于原则和实践构建，通过特定工具和流程层，解决特定技术互联，添加一个团队必需和更好的工具及活动。当原则、实践和工具正确地结合，结果是有效、透明、和谐的软件工厂，能够根据业务的要求交付新功能，同时维持在国家安全环境中所要求的安全级别。
7.1 对敏捷的不懈追求
敏捷宣言抓住定义功能关系的核心能力和DevSecOps团队认为最有价值的内容：
-
个人和互动 高于 流程和工具
-
工作软件 高于 详尽文档
-
客户合作 高于 合同谈判
-
响应变化 高于 遵循计划
第一个核心能力强调个人合作的价值和重要性，但不应该被理解为流程和工具是无关的。对其他核心能力也是如此；文档也仍然需要，但不是以工作软件作为代价；敏捷团队仍然生成冲刺（sprint）计划。
宣言进一步定义了12个敏捷软件原则，提出额外的强调，团队必须把客户的参与排在首位。
软件工厂的建设涉及到多个方面，包括采购、工程、测试、网络安全、运营，甚至领导层。敏捷原则的采用和向DevSecOps的转移对许多组织造成挑战。领导们想接受DevSecOps，但仍然没有准备好在整个组织内教授它，甚至没有准备好衡量它的实施。采购专员努力去了解如何签订DevSecOps合同，因为很难用精确的指标和价格标签去衡量一套概念性的原则。本质上的不确定性，制造了恐惧，产生了偏见。当从类似的情况中学到经验性的知识，采用就比较容易。没有这些经验性知识，偏见就会无意识地出现在理解和决策中。承认这些偏见是文化变革的第一步。
国防部有法定的义务，根据时间、资源和花费的金钱来综合考量，去评估是否给定的投资产生价值。一个名为“沉没成本的心理学”的研究被开展并发表在在1985年《组织行为和人工决策过程》一期杂志上。这个研究揭示了一个偏见，我们趋向于这样一种认知，感觉回报必须足够抵得上投资。这是我们为什么追赶一个好交易，尽管它也许需要3小时的车程，汽油的费用都超过了省下来的部分。在采用和执行DevSecOps文化的时候，承认沉没成本谬论非常重要。
7.2 软件工厂采取内嵌安全
在国防部，安全认证本身已经证明是一个漫长和琐碎的过程。软件工厂贯穿整个软件供应链流程，通过完整和全面的安全实践，采取坚定的网络生存能力立场。DevSecOps通过每个生命周期阶段嵌入网络安全，左移网络安全实践，推动零信任架构，承认从高自动化单元、功能、集成和安全测试中获得的价值。这是DevSecOps关键差异化的地方，使用一系列认可的控制门，同时构建和测试功能及安全能力，目标阻止缺陷逃逸和在发布到下一个环境之前，提高软件网络工件生存能力。这个方法也内嵌指标，能够传递到网络防御者，帮助更好的监控和更有针对性的反馈，返回给工程师，以便将来的更新和补丁。
7.3 集成、自动化&持续端到端测试和监控
向持续操作授权（cATO）的转变规定了持续测试和监控，把风险评估向更左端移动，使用实时的数据驱动指标、评估人、平台和流程。每个程序必须和授权官（AO）合作，打造和实施独有的集成测试和控制门的决策流程。作为一项原则，DevSecOps的每个阶段以他们自己独特的方式，对实时性能监控做出贡献，形成持续操作授权的基石。如同NIST SP 800-27所定义的，零信任有效性也要求持续监控。
7.4 通过“x即代码”设计模式，实现基础设施不可变
使用基础设施即代码、策略即代码、一切即代码（everything as code）技术向不可变的基础设施转移，在许多方面提供安全和价值。首先消除人工操作中，倦怠和容易犯错的按步部署和配置指导。过去人工操作方法，很容易不经意地跳过一步或误操作配置命令。其次，它确定命令会按照预期执行，执行之前，不需要任何类型的同行检查，降低变更风险。第三，提供一个标准的部署模型，一组标准的输出能自动导入到防御性网络操作（defensive cyber operation，DCO）平台和数据收集/视觉化媒介。这允许DCO立即开始，提供数据分析，确定必要的下一个创新。
指导原则对代码驱动的自动化基础设施配置建立了清晰的授权。代码能版本控制、测试、同行检查，跟踪执行（日志）。在《DevSecOps基本原理》和特定的软件工厂平台进一步地定义精确的实践和工具方法。
7.5 采用云智能，数据智能架构主题
有一个乐观的愿景，描绘了云产品无限的计算能力，保证可用性和更低的运营成本。事实是不正确设计架构的应用在云环境中和在本地的数据中心都很脆弱。如果没有被重新设计架构，也许事实上更不可靠和运营成本也更高。向云的迁移必须通过采用新架构设计模式来完成，基于现存企业服务，而不是偏向于重新创造重复的功能。
此外，数据生成、传输和消费，没有减退的迹象。软件架构必须有意识认识到这一点，使用更智能的应用程序接口（API）设计、缓存策略和数据标签/标记。开发团队必须理解甚至在软件工厂内产生的数据也是重要的，特别为授权官（AO）提供可信任的网络安全指标，支持持续操作授权（cATO）。
8 DevSecOps流程概述
整个DevSecOps生命周期阶段在《DevSecOps基本原理》中做了深入介绍。图6描绘了DevSecOps阶段、反馈闭环和控制门。生命周期围绕着一系列冲刺打造，每个冲刺包括计划、开发、构建、测试、发布&交付、运营、和监控阶段。这个图和图3类似，包含同样的步骤。但是“展开”后可以更有效地描述持续反馈闭环的多样性。视觉上，网络安全自动化被认为是基础核心，支撑所有生命周期各个阶段。渗入到每个阶段的多个接触点，基于从产品实际使用和性能得出的实时的指标来指导行动。
另一个反馈闭环是持续监控闭环。这个环路必须把深入和丰富的实时性能指标和支持数据整合在一起，持续评估软件环境的整体性。这个环路有两个主要功能：网络安全监控保证事件根据国防部授权和策略来处理，网络防御者和开发者之间实时地数据反馈和和交互。为做到这点，老式的网络安全快照视图方法被实时数据导入所代替。允许本地防御者、监控团队（网络安全服务提供商，CSSP），事件响应团队（网络保护团队，CPT），美国网络司令部/联军总部-国防部信息网络（Joint Force Headquarter JFHQ-DODIN）的命令和控制（C2）部分采取安全行为。
反馈闭环是非常重要的机制，和特定的DevSecOps生命周期阶段交织在一起，每个反馈闭环都建立在透明和速度的基础上。当一个软件开发人员提交代码到一个分支，触发自动构建，验证代码是否构建正确，如果没有，立即将问题通知给开发人员。DevSecOps基本原理文档解释了每个反馈闭环，和给软件供应链的软件工厂带来的增值。
9 DevSecOps管理和治理
在DevSecOps环境中的治理包括积极评估和管理生命周期中和任务程序有关的风险所使用的流程。治理活动永远不会结束，但现在集成到流程的每个步骤中，减少从开始到生产到运营的间隔时间。
DevSecOps战略的首要任务是网络安全自动化必须渗入到整个软件供应链，绝对不能事后再补充。DevSecOps底层软件工厂概念是软件供应链的一部分，但值得额外注意，因为这是敏感的、特定任务战术、技术、过程转变成敏感的软件算法的地方。软件工厂的DevSecOps管理和治理规定，一系列网络安全控制门执行深度、有意义、可重复和任务相关的自动化网络安全指标。见图7，我们看见其中的一个管道。黑色加红色的菱形图案代表自动化网络安全控制门，在任何工件推送到下一个开发环境之前，必须被清除。
这个自动化说明为保证网络安全渗入到DevSecOps每个阶段的意义。此外，它直观地展示了实用实验&评估（OT&E）必须左移时通过的大门。这个转移允许团队快速的发现质量或稳定性问题，应该在进入下一个阶段之前被解决。最后，在每个控制门收集和团队的绩效及网络生存能力都相关SMART绩效指标。这些指标形成了持续操作授权（cATO）背后的基石原则之一，生成一个经过认证的软件工厂。
9.1 管理结构
DevSecOps的管理目标必须是“自上而下”，同时也是“自下而上”，平衡整个国防部内软件现代化更大的战略目标。高级领导全身投入对成功至为重要，当然员工的投入也同样重要，导致一种归属感，鼓励适当地实施和治理相关的流程，使团队成员支持持续流程改进。持续流程改进-在任何时间和任何地点，寻找机会去简化和自动化，让治理对跟上快速变化的世界非常关键，同时实施一个持续反馈闭环，保证自动化不是以牺牲安全为代价。
9.2 推荐治理
早期国防部在DevSecOps努力投入，如国防威胁减少局（defense Threat Reduction Agency，DTRA）已经成功地使用和采用了商业上的最佳实践。国防威胁减少局（DTRA）治理文件确定了下一代治理（Next Generation Governance，NGG）5个基本原则：
1. 根据使命运行IT：把需求结合到组织的使命中。每个行为应该同使命一致，如果不一致，那就要使用持续流程改进来评估，解决如何把行动和使命绑定在一起。
2. 投资自动化：把每件可能的事情都自动化，包括行为、业务流程，决策、批准、文档等。自动化测试应该验证设计、公共接口行为、执行广泛的功能和安全测试。从这些自动化活动中生成的文档，成为风险管理框架（Risk Management Framework，RMF）要求的证据主体，需要时提供给历史审计。
3. 拥抱适应性：接受随时都可能要求改变，所有的选择都可以帮助实现这个目标。快速失败、小的失败和失败中学习（fail forward）。失败中学习的典型例子是：考虑一次产品发布，无法按计划进行，与其恢复到部署前的状态，开发人员的更改应该非常分散，他们能快速修复解决这个问题，发布一个更新的版本，两者使用的时间差不多。
4. 提高透明：提供跨组织开放访问，查看发生在自动化流程内的活动，查看自动生成工件的记录。透明生成了一个共享想法和开发方案的环境，由企业内行业专家（Subject Matter Expert，SME）或团队领导一起组成跨职能团队，避免“隔离效应”。当所有相关的人集合到一起，团队拥有需要打造任务系统的所有技能，集合必要的才智，战胜所有遇到的挑战。
5. 固有责任：把职责下放和委托到最底层：
-
战略：这个和变更控制委员会（Change Control Board，CCB）或技术审查委员会（Technical Review Board）有关。涉及到“重大变化”非结构化决策。这些不频繁和高风险的决策有潜力去影响组织的战略和使命。
-
运维：（各种Scrum）交叉、半结构化决策。在这个频繁和高风险的决策中，不同的小组，生成一系列相互关联的小决策，作为一个协作的、端到端决策流程的一部分。
-
战术：（全球企业合作伙伴（global enterprise partner，GEP）/产品所有者/开发人员活动）代表授权的结构化决策。这些频繁和低风险决策被个人和工作团队有效地处理，很少需要从他人获取信息。
9.3 评估和授权
国防部指令（DoDI）8510.01（这个指令的名称是 Risk Management Framework）是现存的治理策略，定义所有国防部信息系统和平台信息技术系统必须遵循的流程。网络事件处理程序6510.01B（Cyber Incident Handling Program，CJCSM）定义整体网络事件处理。现代软件架构和DevSecOps中的一些概念对该策略的当前版本提出了挑战，包括：
-
微服务架构，“系统边界”不断变动
-
分布式系统，没有传统的“系统边界”
-
持续集成/持续部署，系统可以控制，但发展快速
随着国防部最终确定它的软件现代化战略，一个认识是国防部必须持续评估和更新策略、法规，和国防部标准（统称为“合规”）。国防部企业DevSecOps战略指南，DevSecOps基本原理文档，任何特定的国防部企业DevSecOps参考设计范围内的任何内容都不能否决国防部现有的治理策略。然而，应该以更主动的态度、积极的合作、认识当前程序缺陷、解决过时合规方法。
10 结论
主张采用DevSecOps文化和理念实践，是国防部软件现代化的中心议题，将推动软件能力按照业务的要求交付。本文档为整个国防部，建立了一套统一DevSecOps指导原则。这些原则贯穿本文档集其他文档中，如图2所示。认识到在整个国防部内软件开发活动的深度和广度，特定的DevSecOps参考设计授权特定场景，证明没有一刀切的方案，国防部未来的成功和全球相关性要求加速采用软件行业的最佳实践。
原文始发于微信公众号（安全行者老霍）：（一）国防部企业DevSecOps战略指南
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论