DevSecOps-你需要知道的一切

在过去的几年中，DevSecOps 已经成为 DevOps 生态系统中最热门的流行词之一。从理论上讲，很容易理解 DevSecOps 的含义以及人们为什么关心它: 它是一种将 DevOps 效率扩展到软件安全的策略。

但是，当您坐下来实际开始推行 DevSecOps 时，事情可能会变得非常棘手。没有一个现成的开关可以将 DevOps 转换为 DevSecOps。这实现需要一组自动化工具和长期实践。

让我们来看看如何做到这一点。

什么是DevSecOps

传统的开发实践是一个瀑布式的过程，开发人员创建软件，然后由安全从业人员进行扫描和测试。但是随着开发周期持续缩短，这种瀑布开发的方法造成了一个瓶颈，开发周期很难再继续缩短。

DevSecOps (开发、安全和运营的简称)旨在通过将安全性集成到软件开发生命周期的每个阶段(从最初的设计到集成、测试、部署和软件交付)来解决这个问题。

将安全性左移至软件开发生命周期(SDLC)的早期阶段，可以让开发团队在生产过程的早期阶段实现修复，在那时修复会更容易、更快、成本更低。最终，DevSecOps 使AppSec成为开发、安全和 IT 操作团队的共同责任。

 

​

DevSecOps为什么重要？

DevSecOps 旨在提供“更安全、更快的软件”，这是当今应用程序驱动世界日益重要的需求。这将带来以下主要优势:

• 通过减少团队在事后必须花时间解决安全问题的可能性来降低开发成本。

• 通过扫描和测试整个开发周期中的安全问题的代码来构建主动安全性。

• 改善开发人员和安全团队之间的沟通。

• 增加组件和依赖项的可见性，这有助于加快安全扫描和补救。

• 通过将漏洞扫描和补丁集成到发布周期中，加速漏洞检测和补丁。

• 启用频繁和简单的增量软件更新 。

• 通过自动化简化审计和法规遵循报告。

• 在现代云环境中进行无缝集成。

• 培养持续改进的文化。

DevOps和DevSecOps的区别

开发人员和 IT/运营专家在 DevOps 中作为一个团队一起工作。他们建立共享的目标、过程和 KPI 来交付软件和应用程序，并分析、更新和改进交付过程。

在 DevSecOps 中，开发人员和 IT/操作人员由安全人员加入，以实现上述这些共同目标，并为SDLC增加安全性。DevSecOps 集成了与安全相关的工具，并在 SDLC 的早期和整个过程中实现了安全实践。这改进了安全性与 CI/CD 进程的集成，使得在整个 SDLC 中进行安全性更改变得更简单、更快和更有效。

顶级DevSecOps实践与工具

1.漏洞扫描

扫描代码中的漏洞是保护产品安全的基本第一步。将漏洞扫描集成到 CI/CD 过程中显然是实现 DevSecOps 的起点。

这意味着要确保在交付管道的每个主要阶段(从编写代码到将其部署到生产环境)检查代码是否存在漏洞。要实现这种级别的集成，您需要确保负责管道的这些不同阶段的各方都受过培训，并拥有检测代码中漏洞所需的工具。

有一系列的工具可以做到这一点，如下:

①软件成分分析(SCA)。SCA 工具执行对应用程序代码库(包括容器和registry等相关构件)的自动扫描，以识别所有开源代码组件、其许可证遵从性数据以及任何安全漏洞。除了提供开放源码使用的可见性之外，高级 SCA 工具还根据风险级别对漏洞进行优先排序，并自动补救它们。目前最常用的SCA工具有：FOSSA、Mend SCA、UniSCA、Black Duck等。

②静态应用程序安全性测试(SAST)。也被称为白盒测试，SAST 使开发人员能够检测自定义源代码中的安全漏洞。它通常在开发周期的早期实现，因为它在编译代码之前扫描应用程序。SAST 是应用程序安全性测试(AST)工具中最成熟和最容易部署的。目前最常用的的SAST工具有：CodeAnt、Mend SAST等。

③交互式应用程序安全性测试(IAST)。IAST 在运行应用程序时使用代理和传感器来实时检测漏洞。IAST 可以识别有问题的代码行，并通知开发人员立即进行补救。它具有高度可伸缩性，并且很容易集成到 CI/CD 管道中。动态应用程序安全性测试(DAST)是一种黑盒安全性测试，通过在应用程序运行时模拟对应用程序的外部攻击来查找安全漏洞。它试图通过检查应用程序公开的接口中的漏洞和缺陷来从外部渗透应用程序。目前最常用的IAST工具有：灵脉IAST、Semmle QL、openrasp-iast等。

2.运行时保护

运行时保护是另一个关键的安全过程，应该作为 DevSecOps 战略的一部分跨 CI/CD 管道集成。

运行时保护可以保护软件免受应用程序开始运行时可能出现的威胁。虽然关于运行时安全性的讨论传统上集中在软件只有在生产环境下才能安全运行，但是运行时威胁也可能存在于管道的早期阶段——即使它们不存在，在交付过程的早期考虑运行时安全性有助于确保当你部署时，你已经减轻了运行时威胁。这两个原因都是为什么运行时安全性应该跨 CI/CD 管道集成，而不仅限于生产环境的原因。

用于运行时检测的特定工具和策略将根据您的特定需求而有所不同。但是，您至少需要确保正在监视应用程序，以防出现可能发出违规信号的异常行为。同样重要的是，您应该知道哪些环境变量或配置设置可能在运行时创建安全漏洞，并且有一个确定这些风险的流程。

3.你的云服务提供商

将安全性集成到应用程序交付过程中的另一个重要策略是利用云服务提供商(CSP)提供的安全特性。其中许多工具位于 DevOps 链的部署和部署后端，因此类似于更传统的事后安全服务。但是作为应用程序外部防御的一部分，它们仍然发挥着重要作用——而且因为它们是云基础设施的一部分，所以通常很容易实现自动化和系统化。

请注意，您的 CSP 的安全特性可能在默认情况下没有启用，并且它们可能需要一些配置，因此您可能需要采取主动步骤来最好地利用它们。

4.标准和政策

设置安全标准和策略在很大程度上是一项动手的工作。您可以扫描您的源代码和基础设施以寻找漏洞，但是决定您的安全优先级应该是什么以及如何实现它们的过程仍然需要认真思考。在设计和代码级别构建安全标准也是如此。

欧盟实施的GDPR使得在设计层面明确制定和实施安全标准变得更加重要。另一方面，通过使用编排工具/服务网格特性(如 RBAC (以角色为基础的存取控制))来实施高度粒度的策略，在操作层面上构建这些标准可以在很大程度上实现自动化。应该像设计应用程序源代码中的安全标准一样重视基于角色的访问策略的设计——而且它们都应该被视为高优先级任务。

5.容器和服务管理

在部署大型的、基于容器的应用程序时，像 Kubernetes 这样的容器编排工具已经成为一种近乎必需的工具。服务网格可以与编排工具一起工作，管理服务发现和访问，以及用户、基于容器的应用程序和外部服务之间的关系，它们本身正变得越来越重要。

这些工具是 DevSecOps 在部署级别的关键元素。它们充当容器和外部世界之间高度可伸缩的隔离层(这样用户和潜在的攻击者只能访问隐藏在代理后面的服务，而不是单独的容器) ，它们可以处理诸如身份验证、授权和加密等任务。它们是为自动化而设计的。然而，甚至比使用 CSP 安全工具更需要注意编排工具和服务网格提供的安全特性，并且需要启用(如果需要)和配置它们。例如，在大多数情况下，Kubernetes 的基于角色的访问配置(RBAC)应该是 DevSecOps 的一个关键元素，但是默认情况下不启用它。

6.软件供应链安全

近期发生的重要违规事件表明，软件供应链受到攻击的频率正在上升。Log4j漏洞和SolarWinds供应链攻击事件提醒我们，软件组件可能是一种安全威胁。由于这些类型的攻击相对较新，大多数组织往往难以确定他们的应用程序在何时会受到何种影响，以及采用何种方法来应对新的威胁。

为了确保软件供应链的安全性，需要对应用程序的每个部分都有一个清晰的视图和控制。虽然技术控制是必不可少的，但是为业务流程、策略和过程开发一个具体的治理、风险和遵从框架也是至关重要的。目前最常用的软件供应链安全工具有：UniSCA

从DevOps向DevSecOps的转变

实现 DevSecOps 需要您对现有的 IT 资源和 DevOps 流程进行广泛的评估，然后构建一个将更强的安全性集成到所有流程中的整体策略。要成功地从 DevOps 过渡到 DevSecOps，你需要:

• 仔细计划，确保你的目标是明确的。

• 逐步引入新思想。

• 在过渡进程中吸收和教育所有团队，鼓励改变以安全为优先事项的思维方式。

• 对开发人员进行安全编码方面的培训。

• 为您的团队和组织选择和使用正确的工具。

• 衡量成功来评估进展。

• 继续学习和更新预防和补救漏洞的方法

如何建立DevSecOps文化

正如前面提到的，DevSecOps 对于安全扫描和修复如何以及何时发生采取了不同的方法。要确保这种方法能够很好地工作，需要您的组织采用一种支持 DevSecOps 理念的新文化。为了实现这一点，您需要对现有的 IT 资源和 DevOps 流程进行广泛的评估，并实现以下变更: