如何成功采用 DevSecOps

在整个软件开发生命周期中整合安全性非常重要，但并非总是易事。

图片来源：

Internet Archive Book Images。由 Opensource.com 修改。CC BY-SA 4.0

采用 DevOps 可以帮助组织转型并加快其软件的交付、测试和部署到生产环境的速度。这是众所周知的“DevOps 承诺”，也因此导致了采用的大幅增长。

我们都听说过许多成功的 DevOps 实施案例，这些案例改变了组织处理软件创新的方式，使其能够通过敏捷交付快速安全地领先于竞争对手。在这里我们看到了 DevOps 承诺的实现和交付。

但另一方面，一些 DevOps 采用反而导致的问题多于好处。这是 DevOps 的困境，在这种情况下，DevOps 未能兑现其承诺。

不成功的 DevOps 实施涉及许多因素，其中一个主要因素是安全性。当安全性被留到 DevOps 采用过程的最后时，通常会发生糟糕的安全文化。将现有的安全流程应用于 DevOps 可能会延迟项目、引起团队内部的挫败感，并产生可能使项目脱轨的财务影响。

DevSecOps 旨在避免这种情况。它的目的是“建立在‘每个人都对安全负责…’的理念之上”。它还在 DevOps 采用的各个层面都将安全性纳入考虑范围。

DevSecOps 流程

在 DevOps 和 DevSecOps 之前，应用程序安全流程看起来像下图所示。安全性在软件交付过程的后期出现，即在软件被接受用于生产之后。

Old software development process with security at the end

图片来源：

^{(Michael Calizo, CC BY-SA 4.0)}

根据组织的安全配置文件和风险偏好，应用程序甚至可能在验收期间绕过安全审查和流程。在这一点上，安全审查变成了审计工作，以避免不必要的项目延误。

Security as audit in software development

图片来源：

^{(Michael Calizo, CC BY-SA 4.0)}

DevSecOps 宣言表示，在各个层面上将安全性集成到开发和运维中的原因是：以更少的摩擦实施安全性，促进创新，并确保安全性和数据隐私不会被抛在后面。

因此，DevSecOps 鼓励安全从业人员适应和改变他们旧的、现有的安全流程和程序。这听起来可能很容易，但改变流程、行为和文化总是很困难，尤其是在大型环境中。

DevSecOps 原则的基本要求是在整个应用程序开发和部署过程中引入安全文化和思维方式。这意味着旧的安全实践必须被更敏捷和灵活的方法所取代，以便安全性可以迭代并适应快速变化的环境。根据 DevSecOps 宣言，安全性需要“像开发人员一样运作，以便将安全性和合规性作为服务来消费”。

DevSecOps 应该如下图所示，安全性嵌入在整个交付周期中，并且可以在每次需要更改或调整时进行迭代。

DevSecOps considers security throughout development

图片来源：

^{(Michael Calizo, CC BY-SA 4.0)}

常见的 DevSecOps 障碍

任何时候引入更改，人们都会发现新流程的缺陷或问题。这是自然的人类行为。与学习新事物相关的恐惧和不便总是会引起不良反应；毕竟，人类是习惯的生物。

DevSecOps 采用中的一些常见障碍包括：

供应商定义的 DevOps/DevSecOps： 这意味着原则和流程侧重于产品，并且组织将无法构建自己的方法。相反，他们将仅限于供应商提供的服务。
紧张的管理者： 发生变化时，对失去控制的恐惧是一个实际问题。通常，焦虑会影响管理者们的决策。
如果没坏，就不要修理它： 这是一种常见的想法，你真的不能责怪人们这样想。但是，尽管有新的交付软件和解决方案的方法，旧方法仍然可以生存的想法必须受到挑战。为了适应敏捷应用程序生命周期，你需要更改流程以支持它所需的速度和敏捷性。
Netflix 和 Uber 效应： 每个人都知道 Netflix 和 Uber 已经成功实施了 DevSecOps；因此，许多组织都想效仿他们。因为他们与你的组织有不同的文化，所以仅仅效仿他们是行不通的。
缺乏衡量： DevOps 和 DevSecOps 转型必须根据设定的目标进行衡量。指标可能包括软件交付性能或组织随时间的整体性能。
清单驱动的安全： 通过使用清单，安全团队遵循相同的旧的、静态的且不灵活的流程，这些流程对开发人员用来使软件交付精简和敏捷的现代技术既无用也不适用。引入“即代码”方法要求安全人员学习如何编码。
安全作为特殊团队： 这在从旧的软件交付方式（安全是一个独立的实体）过渡到 DevOps 的组织中尤其如此。由于分离，开发、运维和安全之间的信任令人怀疑。这将导致安全团队花费不必要的时间来审查和管理 DevOps 流程以及构建管道，而不是与开发人员和运维团队密切合作以改善软件交付流程。