Jan 01, 1970
10,975 讀數
如何将 DevOps 管道转变为 DevSecOps 管道：左移概念概述
太長; 讀書
我解释了左移概念是什么以及它如何帮助减少错误修复成本和开发时间：在开发过程中越早开始安全检查越好。 然后，我解构了 DevSecOps Pipeline 结构，并查看了 Pipeline 的每个阶段执行了哪些安全检查。嗨，黑客午！我叫 Sofia，是一名 DevOps/云工程师。我决定参加 HackerNoon 和 Aptible 举办的比赛。
在这篇文章中，我将讨论 DevSecOps 管道的特性以及 Shift Left 的概念。您将了解 DevSecOps 管道的主要阶段、软件开发中的自动安全检查以及免费和开源工具。您还将找到一些提示，帮助您尽早检测漏洞并提高应用程序安全性。
本文将帮助您评估 DevSecOps 管道的成熟度，为其开发制定路线图，为每项任务选择正确的工具，并更好地了解如何遵循 DevSecOps 理念来管理项目。
左移概念
DevSecOps 方法的主要目标是将自动化安全检查引入 DevOps 管道，即软件开发过程本身。
不久前，信息安全专家在完成开发过程后进行了测试。这种方法效率低下——如果在安全测试过程中发现错误，整个开发周期就必须重新开始。这既耗时又昂贵。
看看下面的图片。您可以看到纠错成本随着每一步的增加而增加。
修复开发和功能测试期间发现的安全问题几乎不需要花费任何成本。可以立即对源代码进行所有必要的更改并发送以供重新检查。
在工件构建阶段修复问题的成本至少是两倍。您将必须对构建过程进行更改，例如编辑 Dockerfile，这意味着您将需要 DevOps 工程师的帮助。
如果在集成测试期间检测到错误，修复它的成本将增加 10 倍。在这种情况下，您必须重新启动开发周期并让开发人员、DevOps 工程师和测试人员参与进来。
在部署阶段检测到的安全问题可能会导致用户数据泄露。该公司可能会收到数百万美元的罚款并损害其声誉，这意味着错误的成本会增加数百倍。
因此，主要结论是应尽早进行安全检查。如果您可视化它，请将它们移动到管道的左侧。这就是安全专家非常喜欢谈论的“左移”概念。
DevSecOps 管道结构
DevSecOps 管道是一个自动化的流程和工具链，用于在生产环境中构建、测试和交付应用程序，并在每个阶段保护它们。
上图显示了 DevSecOps Pipeline 结构以及安全检查的所有主要阶段。以下是关于他们每个人的几句话：
- 预提交。它意味着在开发人员将代码提交到版本控制系统之前检查源代码的安全性。通过此检查，您可以检测未加密的机密信息，例如密码或 API 密钥。
- 预构建。它意味着在源代码进入版本控制系统后对其进行安全性检查。这些工具对源代码及其依赖项进行静态分析，以检测常见漏洞，例如许多
OWASP 前十名 列表。
- 构建后。它是对从源代码构建的工件（例如 Docker 文件、RPM 包或 JAR 存档）的安全检查。这些工具分析应用程序环境和依赖关系，查找已在新版本中打补丁的包和库的过时版本。
- 测试时间。它意味着测试从收集的工件运行的应用程序的安全性。此阶段的工具尝试通过模拟攻击者的操作来“破坏”应用程序。
- 部署后。它意味着在将应用程序部署到生产环境后检查应用程序的安全性。这些工具实时监控已知漏洞的开放注册表，并在检测到应用程序威胁时发出通知。
接下来，让我们仔细看看这些检查是什么以及使用哪些工具来执行这些检查。
预提交检查
预提交检查允许您在将更改提交到存储库的本地副本之前分析开发人员计算机上的源代码。如果任何语句返回错误，则不会执行提交。在这种情况下，开发人员必须修复错误并再次提交。
此检查可以避免未经检查的代码（例如，具有未加密秘密的代码）进入存储库的情况。
为了执行预提交源代码检查，需要在开发人员的本地机器上安装工具。这种方法不仅有优点，也有缺点。例如，环境差异：不同版本的仪器、不同的操作系统，甚至处理器架构。
如果开发人员使用不同版本的预提交工具，检查的结果会有所不同，这可能会使协同工作变得困难。在团队内或整个公司内实施提交前检查时请考虑这一点。
预提交检查工具
许多开源工具可用于设置预提交检查：
这些是预提交检查的好工具。
预构建检查
在预构建阶段，执行白盒测试。这些检查用于分析源代码，就像上一步一样。在这种情况下，应用程序是一个“白盒”，因为我们知道并理解它的架构和内部结构。
有几种类型的预构建检查：
- 秘密侦查
- 静态应用程序安全测试 (SAST)
- 软件成分分析（SCA）
现在，让我们详细讨论它们。
预构建秘密检测检查
秘密检测是一种自动检查，可检测未加密的敏感信息：已进入版本控制系统的源代码中的未加密秘密。
预构建检查是在源代码进入版本控制系统的存储库后执行的。因此，攻击者可能会访问存储中所有未加密的敏感数据，例如，如果存储库的内容泄露。
此外，实施秘密检测检查的过程可能不是从头开始，而是在一个不断发展的项目中进行。在这种情况下，可能会在旧提交和不同的存储库分支中找到未加密的秘密。
为了解决这些问题，我们需要做很多不同的事情。例如，我们必须清理未加密秘密的存储库或实施各种秘密管理工具，例如Hashicorp Vault 。
秘密检测工具
秘密检测可以使用配置
预构建 SAST 检查
静态应用程序安全测试 (SAST) 是一种测试，分析器不仅检查语法正确性，还借助独特指标来衡量代码质量。先科扫描仪的主要任务是安全测试。
特别是，SAST 分析器包含常见漏洞的源代码，例如，一些
SAST 分析称为白盒测试，因为分析器可以访问应用程序的内部结构。需要注意的是，分析器会在不运行源代码的情况下检查源代码，因此可能会产生误报并且无法检测到某些漏洞。
因此，您不应仅限于 SAST 分析。最好全面地处理该问题并使用不同类型的分析：SCA、DAST、IAST 和 OAST。
先科工具
专有解决方案：
免费的解决方案是 GitLab SAST。
预构建源 SCA 检查
软件成分分析 (SCA) 是一种通过分析应用程序的开源组件来保护应用程序安全的方法。
SCA 扫描器会查找包含已知漏洞和漏洞的过时依赖项。此外，一些SCA工具可以确定组件的许可证兼容性以及许可证侵权的风险。
源 SCA 分析源代码，更具体地说，分析源代码中定义的应用程序依赖项。这种分析通常称为依赖关系扫描。
SCA 允许您检测一个组件中的漏洞可能导致所有应用程序出现安全问题的问题。
一个很好的例子是
SCA工具
具有免费定价计划的商业解决方案：
作为 GitLab 的一部分（仅在 Ultimate 版本中可用），您可以使用
构建后检查：二进制 SCA
构建后阶段是在从 CI 管道中的源代码构建工件之后进行的：Docker 映像、RPM 包或 JAR 存档。通过构建后检查，您可以分析这些二进制工件中的依赖关系。
二进制 SCA 分析涉及检查二进制工件，例如 Docker 映像、RPM 包和 JAR/WAR/EAR 存档。它通常也称为容器扫描。在构建二进制工件时运行它是有意义的，即，而不是在构建后阶段之前。
使用 Docker 镜像时有一些令人兴奋的功能。二进制 SCA 分析器检查 Docker 镜像层，并在公共漏洞数据库（例如
一些分析器不仅可以找到易受攻击的组件，还可以提出修复建议，例如，通过指定已修复漏洞的组件所需的最低版本。
流行的二进制 SCA 分析器示例
免费的解决方案是
开源解决方案：
具有内置分析器的 Docker 注册表 -
测试时检查：DAST、IAST 和 OAST
在此阶段，进行动态灰盒测试和黑盒测试。当应用程序的内部结构部分或完全未知时，这些安全检查是通过模拟攻击者的行为来执行的，攻击者发现漏洞并尝试利用它们来“破坏”应用程序。让我们简要讨论一下它们：DAST、IAST 和 OAST。
测试时 DAST 检查
DAST 扫描仪通过模拟各种漏洞的外部攻击来自动测试应用程序。该应用程序是分析仪的黑匣子；对此一无所知。
对于 DAST 检查，需要有一个可用于扫描仪的正在运行的应用程序实例。此外，应用程序测试实例的参数越接近生产安装，误报就越少。
例如，假设您部署了一个只能通过 HTTP 协议访问的测试应用程序实例，但在生产中，该应用程序只能通过 HTTP 协议访问。
在这种情况下，DAST 扫描器将生成一些与客户端（分析器）和服务器（应用程序实例）之间缺乏流量加密相关的错误。
DAST 工具示例
值得您关注的工具：
亚搏体育appDAST — 仅适用于终极版本OWASP Zed 攻击代理 (ZAP) — 一个开源解决方案，也用于 GitLab DAST- 阿库内蒂克斯
- 强化 WebInspect
- HCL 安全 AppScan
- Synopsys 托管 DAST
Tenable.io （网络应用程序扫描）- Veracode动态分析
太好了，继续前进。
测试时 IAST 检查
IAST（交互式应用程序安全测试）是一种灰盒测试，结合了白盒测试SAST和黑盒测试DAST的优点和长处。
为了收集 SAST 和 DAST 方法的所有优点并消除其缺点，开发人员发明了 IAST - 一种结合这些方法的混合机制。它提高了动态测试的准确性，因为它通过代码分析提供了有关应用程序操作的更多信息。
值得记住的是，除了优点之外，IAST 也有局限性。最基本的一个是对编写被测应用程序的语言的依赖。 IAST 解决方案在应用程序级别工作，需要访问可执行代码来分析其行为。
这意味着 IAST 解决方案必须能够理解编写应用程序所用的编程语言。应该注意的是，对于某些语言来说，对特定 IAST 解决方案的支持可能比其他语言更好。
IAST分析也需要很长时间。它取决于许多因素，例如应用程序的大小和复杂性、外部依赖项的数量以及所使用的 IAST 工具的性能。
此外，分析过程并不扫描代码本身，而是仅检查那些直接执行的片段。因此，当您可以测试尽可能多的应用场景时，IAST 分析最好与功能测试结合起来。
IAST 工具示例
这里有一些非常适合您的工具：
太好了，继续前进。
测试时 OAST 检查
OAST（带外应用程序安全测试）是由
OAST 工具示例
我推荐你：
继续前行。
部署后检查
这是确保应用程序安全性和可操作性的重要阶段。与在开发阶段执行的预提交检查不同，部署后检查允许您在自然环境中的应用程序操作期间识别可能存在的问题。
监控文物的安全
为了及时检测新漏洞，有必要定期执行工件检查，包括在部署应用程序之后。
这可以使用特殊的存储库或工具来完成，例如
应用安全监控
确保安全性的另一种方法是监视应用程序本身。有多种技术可用于此目的：
- Web应用防火墙（WAF）是一种流量过滤工具。它工作在应用层，通过分析 HTTP/HTTPS 流量来保护 Web 应用程序。
- RASP（运行时应用程序自我保护）是一种实时检测并阻止对应用程序的攻击的技术。它为运行环境添加了防御功能，让应用程序能够自动进行自我保护。
RASP 相对于 WAF 的主要优点是它了解应用程序的工作原理并检测攻击和非法流量。 RASP 不仅可以发现使用签名匹配的典型攻击，还可以通过对异常做出反应来尝试利用零日漏洞。
与 WAF 不同，RASP 在应用程序内部并与应用程序一起工作。 WAF 可能会被愚弄。如果攻击者更改了应用程序代码，WAF 无法检测到它，因为它不了解执行上下文。
RASP 可以访问有关应用程序的诊断信息，可以对其进行分析、检测异常并阻止攻击。
RASP 技术的特点是默认情况下专注于防止攻击。该系统不需要访问源代码。
粗鲁的傻瓜
我推荐你：
太好了，继续前进。
DevSecOps管道结果和漏洞管理的可视化
在管道的不同阶段，我使用了许多应用程序安全测试/DevSecOps 分析器。它们每个都以自己的格式生成报告，其中一些会生成所谓的误报。因此，分析整个应用程序的安全性并不容易。
为了有效分析漏洞并管理修复过程，需要使用专门的漏洞管理工具（通常简称为安全仪表板）。
安全仪表板通过以统一且易于分析的形式提供 DevSecOps 分析结果来解决问题。通过这种方式，安全工程师可以了解存在哪些问题、哪些问题最关键以及哪些问题需要首先解决。
开发安全运营工具
通常使用多种工具作为安全仪表板：例如，经典的 SOAR/SIEM 系统和 Swordfish Security 的专用 DevSecOps 协调器 AppSec.Hub 或开源漏洞管理工具包 DefectDojo。
DefectDojo 是一种广泛使用的工具。即使在企业公司中也被广泛使用。然而，尽管它很受欢迎并且历史悠久，但当贡献者破坏提交中的基本功能时，该工具偶尔会出现一些初始级别的缺陷。
然而，令人高兴的是 DefectDojo 开发人员和维护人员可以帮助解决复杂性。 DefectDojo 开发人员反应非常灵敏 - 我们建议通过 GitHub 上的问题直接与他们联系。
左移概念：让我们总结一下
再次，这里是对本文内容的快速回顾。
我解释了左移概念是什么以及它如何帮助减少错误修复成本和开发时间：在开发过程中越早开始安全检查越好。
然后，我解构了 DevSecOps Pipeline 结构，并查看了 Pipeline 的每个阶段执行了哪些安全检查：
- 预提交。它意味着在源代码进入版本控制系统之前检查源代码的安全性。
- 预构建。它是版本控制系统（秘密检测、SAST、SCA）中源代码安全性的检查。
- 构建后。它是对从源代码（源 SCA、二进制 SCA）构建的工件的安全检查。
- 测试时间。它意味着测试从收集的工件（DAST、IAST 和 OAST）运行的应用程序的安全性。
- 部署后。这意味着在生产环境（WAF、RASP）中部署后检查应用程序的安全性。
现在，您了解了 DevSecOps Pipeline 的工作原理。现在，您可以评估 DevSecOps 管道的成熟度，为其开发制定路线图，并为每项任务选择正确的工具。
L O A D I N G
. . . comments & more!
. . . comments & more!
About Author
標籤
LANGUAGES
相關故事
看不见的层面：为什么用户访谈是不可替代的资产
#startup
创建以用户为中心的加密产品：客户反馈的重要性 #crypto-user-experience
Jan 01, 1970
