《综述：美国国防部DevSecOps 最佳实践采用情况》赛博安全与美国国防部系统开发，71页技术报告

美国国防部（DoD）的软件密集型系统作为昂贵的采购项目，有着悠久而不幸的历史。这些系统交付迟缓、漏洞百出、界面复杂笨拙，或者三者兼而有之，既不能令客户满意，也不能令操作人员满意。半个多世纪以来，试图解决美国国防部软件采购问题一直是一个活跃的研究课题。

20 世纪 70 年代，美国国防部的软件采购模式被概括为瀑布模型。当时的想法是，客户向开发人员提出一系列需求。开发人员最终会提供可安装和使用的软件。这类似于桥梁的建造过程。需求说，跨越这条鸿沟。承包商说，这就是你的桥。不幸的是，物理系统工程中的流程模型并不适用于软件。需求从来都不是第一次就正确的。它们的实施效果也不好。即使软件成功了，瀑布模型也不允许结合使用软件如何改变工作场所模式的反馈和经验进行改进。

20 世纪 80 年代出现了其他的软件开发模式。许多模式都强调自动化：由工具支持的正式定义的流程、包括可执行模型在内的全面文档，以及允许管理层跟踪进度的广泛而复杂的规划工具。

2001 年提出的《敏捷宣言》就是对这种实践状态的回应。敏捷方法强调增量交付。增量不仅能修复错误，还能根据客户反馈进行改进。这些反馈不是来自正式提交的报告，而是客户与开发人员之间的协作。敏捷方法的支持者从未宣称他们的方法是万能的，只是说它更适合满足现代软件导向项目中出现的需求和问题。从敏捷方法被广泛采用的情况来看，软件开发界的许多人都同意这一点。

一些敏捷的批评者认为，敏捷强调的是与错误的群体合作。客户不一定是用户。这种认识催生了 DevOps 方法论，它鼓励的不是开发人员与客户之间的协作，而是开发人员与操作人员之间的协作。有了这些合作，增量将更好地反映真实需求。DevOps 被称为 "正确的敏捷"。

这种协作的危险在于可能会忽视安全性。每个人都承认安全的必要性，但对大多数运营商来说，安全大多是额外的步骤。运营商需要的是新功能，而不是麻烦的双因素身份验证。此外，很少有开发人员喜欢实施安全措施。在按时交付的压力下，安全问题可能会被搁置一旁，并被承诺在未来的增量中实现。

DevSecOps 方法试图在快速交付和安全需求（DevOps 中的 "Sec"）之间取得平衡。DevSecOps 在开发过程中增加了一个安全团队。安全团队负责确保安全问题尽早得到考虑，并且永远不会被忽视。当安全团队与开发人员、测试人员和操作人员合作，建立起一种既能协助将安全纳入其中，又不会过度阻碍进度的基础设施时，安全团队就能高效地发挥作用。

2020 年，Sarah Standard 委托国防分析研究所（IDA）研究美国国防部采用 DevSecOps 的情况。本报告讨论了 DevSecOps 的用途，涵盖了成功经验和问题领域，并就美国国防部可采取的行动提出了建议，以改进 DevSecOps 的使用。

方法路径

IDA 试图了解为什么在没有全美国国防部授权的情况下，越来越多的项目选择使用 DevSecOps。IDA 团队首先审查了与 DevSecOps 和安全相关的政策、实践、技术和标准。它审查了美国国防部的材料，密切关注其他政府标准，特别是国家标准与技术研究院（NIST）的标准，同时也注意考虑商业最佳实践、技术和标准。IDA 确定了几部被认为是 DevOps 和 DevSecOps 基础性实践的著作。其中特别值得关注的是《DevOps 手册》[4]，这是一本关于 DevOps 原则和最佳实践的手册。

由于这本手册广为人知并被广泛阅读，IDA 团队假定 DevSecOps 实践者会遵循其建议。团队准备了一份调查，以了解项目是如何使用 DevSecOps 的。团队之间如何建立互动？执行了哪些自动安全扫描？他们的经验是积极的还是消极的？遇到了哪些困难？有哪些经验教训？文献经常指出，采用 DevSecOps 需要整个组织的思想转变。该小组希望衡量这种转变的程度，并了解美国国防部今后可以采取哪些行动来促进这种转变。

项目发起人帮助 IDA 团队确定并联系了美国国防部内使用 DevSecOps 或非瀑布式软件开发方法的人员。IDA 团队在 2021 年 2 月和 3 月期间发送了调查问卷或进行了电话访谈，并对回复进行了分析，以找出共同点和不同点。该团队还寻找有效或无效的实践和技术，以及需要改进的领域。

研究结果

调查和访谈结果有助于描述美国国防部的部分项目是如何使用敏捷、DevOps 或 DevSecOps 方法的。为避免在美国国防部范围内开展全面调查，团队通过搜索现有文献拓宽了视野。2020 年国际开发协会的一份报告《DevSecOps：技术现状及与国防部的相关性》[5]，以及 Gartner 集团的一些产品都很有启发性。这些报告包含两项重要分析，有助于为本报告提供背景信息：

广泛的应用安全测试（AST）是成功的 DevSecOps 实践所必需的，有 14 家重要的商业公司开发了 AST 工具和支持这些工具的基础设施。在这 14 家公司中，有 5 家可被视为行业领导者。其他公司则试图迎头赶上，探索令人兴奋但未经证实的技术或填补空白。
Gartner 的 "炒作周期 "说明了技术应用的常见模式：最初的狂热、不切实际的承诺让人幻想破灭，随后逐渐实现原始技术功能上可行的子集，并缓慢但稳定地融入工作场所。Gartner 2021 年的预测显示，DevSecOps 将于 2023 年至 2026 年间成熟。

IDA 团队通过调查和访谈发现，DevSecOps 的采用有几个技术上的共性。其中包括

使用静态应用安全测试 (SAST) 工具。八个受访者表示使用了 Fortify 或 SonarQube（或两者）这两种业界领先的商业 SAST 工具。Fortify 由 Micro Focus 开发，Micro Focus 是 Gartner 认定的行业领先企业之一。
使用容器技术。容器提供了在隔离环境中运行应用程序（或应用程序套件）的能力，越来越多的人将其视为解决许多现代问题的方案，而这些问题曾是虚拟机（VM）的职责范围。与虚拟机相比，容器可以更快地部署、更容易地扩展、更快地启动、停止和重启。容器非常适合基于云的部署，因为基于云的处理器本身就是一个虚拟机。
始终如一地使用不同的环境进行开发、测试、暂存和部署。DevSecOps 方法提倡将这些不同的环境作为隔离活动和避免冲突的手段。开发绝不会干扰测试，反之亦然。更重要的是能够建立一个自动化流程，使开发中的任何工件在暂存之前必须通过测试，在部署之前必须通过暂存。每项变更都必须在不同的环境中进行测试，然后才能放入生产系统。
统一使用资源库。开发人员和测试人员将工件存储在 git 资源库中，这意味着工件受版本控制、配置管理、易于查看，并自动接受扫描和测试。

自动化扫描和测试是通过实施管道来实现的。管道是对工件从开发到测试、到暂存、再到部署的过程的描述。管道尽可能实现自动化。有些环境将管道完全自动化，以至于开发人员提交的任何变更，无论多么微小，都能自动且几乎立即进入生产阶段。这种管道是持续交付（也称持续部署，均缩写为 "CD"）的缩影，其中的增量开销可以忽略不计。

IDA 的研究结果表明，美国国防部的管道尚未达到这种效率水平。开发一个强大到可以信赖大多数变更的管道并非易事。美国国防部的情况很复杂，因为开发和测试通常在非保密系统上进行，而部署通常在保密系统上进行。这些不同的环境有不同的政策，运行不同的软件。软件无法自动从非机密系统转移到机密系统，因此不可能实现完全自动化的管道。机密工件也无法从机密系统转移到非机密系统，从而使运行过程中发现的问题的调试变得更加复杂。

下面的调查和访谈结果汇总表总结了 IDA 团队的调查和访谈结果。每一行都列出了不止一个答复中记录的内容（第三栏列出了编号）。

结论与建议

每个 DevSecOps 实践者都知道，将 DevSecOps 融入组织需要时间和决心。这涉及到在组织结构中引入新的、以前未曾考虑或定义不清的角色和职责。这些行动需要耐心、培训和承诺。受访者表示，与某些传统项目相比，DevSecOps 的启动开销更高。一些受访者说他们不得不 "重回瀑布式项目"，这也许就是他们不愿全力投入的原因。

其他组织对转向 DevSecOps 进行了研究，并提出了衡量承诺和进展的成熟度模型。IDA 发现了三种：

大西洋海军信息战中心（Naval Information Warfare Center Atlantic）根据组织的实践提出了一个九级成熟度模型。
美国国防部创建了 DevSecOps 成熟度审查，这是一份问题清单，旨在帮助了解组织的 DevSecOps 方法，并提出改进建议。
开放式 Web 应用程序安全平台 (OWASP) 提出了 DevSecOps 成熟度模型 (DSOMM)，这是一个以安全为重点的四级模型，用于确定将安全内置于应用程序的程度。

这些模型缺乏能力成熟度模型集成（CMMI）式成熟度模型的严谨性，但仍能对进展情况进行有用的定性评估。美国空军（USAF）首席科学官正在鼓励对 DevSecOps 进行类似 CMMI 的成熟度评估。如果他取得成功，企业将能够定量地判断其进展情况。

IDA 根据本报告中的结果和分析为美国国防部提出了 12 项建议，这些建议合在一起将促进 DevSecOps 在国防部项目中的应用。

1 定义并宣传 DevSecOps 的适当标准定义，特别是在 DevSecOps 方法中整合 DT 的传统角色。

2 在开发组织和文化中自上而下地理解、承诺和应用 DevSecOps 概念。

3 采用 DevSecOps 成熟度模型来衡量和改进开发项目的安全有效性。

4 了解将瀑布式项目转换为 DevSecOps、从小项目扩大规模以及跨领域开发过程中面临的文化和资源挑战。

5 确定以任务为重点的安全要求，并在前期纳入测试流程和环境。

6 确定、持续评估和管理客观的安全指标，确保 DevSecOps 环境生成的软件满足任务安全要求。

7 除开发人员外，投入足够的运营和安全人员，确保团队开发的软件满足运营和安全要求。

8 确保开发方法适合项目要求并可调整，特别是对于物理隔离或高度敏感的系统。

9 在开发环境和管道中纳入良好的架构和设计，以支持安全性。

10 努力识别并整合无法在规范的可重复 DevSecOps 流程中实现自动化的测试。