美国防部国防创新部门位于波士顿的“克赛尔航程”项目软件开发团队

轧棉机的发明者Eli Whitney曾在1801年向美国国会、John Adams总统以及当时已经当选的新任总统Thomas Jefferson展示了标准化替换零件的巨大价值。Whitney将几把火枪拆散，又用拆下来的部件重新拼凑成一把能够正常使用的火枪，快捷直观地证明了可互换零件的可行性与军事价值。

如今，零件的可互换性早已成为共识，无论是步枪的螺栓支架还是汽车上的交流发电机，我们总是默认一款零件永远与另一款零件同样稳定可靠。但正如Whiney时代下的传统火枪一样，当前我们使用的信息系统在很大程度上仍然类似于手工制品。其中的每个部件都需要定制化安装，借此适应其他各个组件的调整与变化。更要命的是，开发人员还得定期更换这把“火枪”上的“撞针或枪托”，否则信息系统很快就会罢工崩溃。相信经历过专业团队临危受命，在故障情况下进行系统配置的朋友，肯定对这一点深有感触。

为了解决信息系统的定制化属性，并在信息系统中建立起独特的、类似于可互换零件的全新规范，美国国防部开始大力推行DevSecOps。过去两年以来，这种新方法已经得到越来越多公共部门的采用，并形成一股值得关注并深入剖析的全新趋势。

首先，DevSecOps是什么？DevSecOps是流程、工具与人员的结合，旨在将开发、安全与运营的学科价值集于一身。DevSecOps还建立起一种独特的文化，帮助我们更高效地交付并管理安全软件。

目前，业界已经见识过DevOps实践在增强安全性方面的卓越能力。更重要的是，我们需要立足整体流程将安全性整合至政府运营体系当中，从而更高效地实现迭代改进带来的收益。传统开发流程通过将安全性作为一个个拦截式的检查点，但却未能在将安全真正融入整个流程之内。DevSecOps将安全问题视为头等大事，而不再是额外的检查关卡。DevSecOps亦在整个联邦政府当中得到广泛采纳，包括总务管理局、空军、陆军以及海军等等。

DevSecOps流程

从流程的角度来看，DevSecOps可以算是对敏捷开发以及持续集成/持续交付（CI/CD）方法中已经日趋成熟的软件开发生命周期实践的有力扩展，有助于改善已部署系统的运营行为——特别是安全相关活动。以持续部署为指导，我们将敏捷化的基本思路引入运营管理，并以代码形式注入配置当中，在借此实现运营任务自动化的基础之上，最终提升系统的整体弹性。

结果就是，业务系统将实现按钮式自动化——只要启动适当的自动化手册，即可轻松完成从裸机到重新部署、再到建立完整运营能力的全面基础设施操作任务。

DevSecOps工具

DevSecOps中涉及的具体工具多种多样。能否选择正确的工具，将直接决定DevSecOps的实际成果。换言之，即使生搬硬套其他部门的成功工具组合，我们也未必能够重现其强大的业务保护能力。DevSecOps是流程、工具与人员这三大支柱的融合产物，并不存在什么即买即用的现成解决方案。这是种遗憾，我们无法简单买到能够直接安装在数据中心内的完善DevSecOps框架。

DevSecOps工具集拥有广泛的覆盖范围，包括源代码版本控制、构建自动化、测试自动化、安全验证、性能测试、配置管理等等，甚至可能进一步扩展至优先级划分、问题跟踪与团队协作式项目管理系统等相对细化的领域。

DevSecOps人员

在国防部中，DevSecOps原则中的人员要素往往最难以实现。康韦定律提出，组织更倾向于能够反映组织沟通结构的设计引导产品构建。换言之，以孤岛形式组织起来的机构，会倾向于将应用程序放置在一个个孤岛当中。而随着DevSecOps对于人员角色提出的紧密集成要求，不少政府机构发现自己必须调整组织结构，从而将IT专业人员整合到跨项目/跨职能的综合性团队当中，借此替代以往单纯通过工单系统按既定岗位角色进行交流的僵化治理模式。

人员的重组与调整，让每一个人凝聚起来，朝着同一目标携手前进：成功发布产品，全面推动以结果为导向的工作理念。

DevSecOps的优势

DevSecOps为国防部下辖各机构带来了诸多优势，包括缩短价值实现时间、加快新功能迭代速度、以及实现风险左移（即预先把控风险因素）等。其中最具价值的优势，当数缩短价值实现时间——这种价值可能表现为创新能力、产品可靠性，也可能直接体现为同一产品的快速发布。

以往，联邦政府往往以瀑布式流程作为常规开发思路，着重于组织大量需求文档与预开发工作。虽然这些准备工作能够为产品的第一个版本制定明确的功能与特性目标，但这些功能特性往往并没有预先估计的那么重要，也无法为整个用户群体提供广泛价值。与之对应，DevSecOps能够通过迭代反馈过程加快向各个部门馈送价值的速度。

DevSecOps的实施障碍

在政府采用DevSecOps的过程中，最大的实施障碍当数最低可行产品（MVP）。但MVP本身，又是通过风险左移实现价值回馈当中的关键组成部分。

二八原理在产品开发中堪称箴言。一般来说，80%的用户只使用20%的产品功能。如果通过传统的瀑布式方法开发产品，那么在开发并测试这些非常用功能的过程中，将有高达80%的用户陷入漫长且毫无意义的等待。而在试图满足瀑布式发布时间表中设定的各项所需功能目标时，残酷的现实又将再次印证“完美是优秀的敌人”这一论断。这种方式不仅令一切功能集成与测试变得异常复杂，同时也将延缓有价值功能的交付时间。

DevSecOps的目标，明显是要深刻影响联邦政府通过近2000页的《联邦政府采购法规》（FAR）所建立起来的传统采购与开发流程。FAR定义了执行机构获取产品及服务所必须遵循的流程。在法规的指导下，FAR流程设定了明确的实施节奏，从另一个角度上坐实了瀑布式开发实践的必要性。但业界已经证明，在开发创新型、特别是前所未有的解决方案时，瀑布式软件开发模式存在着重大缺陷。

通过DevSecOps解决问题

在解决新问题时，我们往往面对着两种未知。首先是已知的未知，即我们事先已经明确理解的、需要解决的挑战。其次是未知的未知，即我们在打造新型解决方案、实现新的业务突破时，所无法预见到的种种挑战。

在开发创新型解决方案的过程中，未知的未知才是真正的绊脚石，往往只会在瀑布开发模式中的时间表设定完成之后才缓缓现身。在这方面，我们当然有必要通过DevSecOps反馈循环始终将变更保持在较小、战略性、增量式的范围之内，借此实现风险左移。如果某项特定功能难以处理或者极度复杂，则应在开发流程早期对其进行优先级划分，包括废弃、剖析或者重新设计，避免因这一项功能影响到其他有价值功能的顺利交付。

很多人在提起DevSecOps时，首先想到的往往是使用微服务或无服务器架构，或者基于容器类工作负载组成的云原生Web应用程序。这里需要强调，DevSecOps代表的绝不仅仅是开发这类现代架构的过程。DevSecOps同样适用于开发传统单体式应用程序、n层架构、面向服务架构甚至是嵌入式系统。最重要的是，DevSecOps理念能够极大提升这类复杂系统的构建可行性与成功几率。

国防部目前正在推进的一项关键概念，名为“软件工厂”。软件工厂属于DevSecOps概念的具体实现，专注于修复当前国防部在IT系统中使用的种种定制化技术。软件工厂沿袭的是工业革命中的一项核心发明，即装配流水线。软件工厂植根于DevSecOps原理，但DevSecOps的实现并不单纯依赖于软件工厂——软件工厂只是DevSecOps中的一个子集，二者的关系类似于可互换零件之于装配流水线。随着DevSecOps的持续普及，国防部正迅速向着结构精简化、反应敏捷化且执行高效化的新时代军事形态迈进。

原文链接：

https://fcw.com/articles/2020/08/12/yates-devsecops-ibm-center.aspx

声明：本文来自安全内参，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。