DevSecOps: CI/CD流水线中增加安全

阅读本文需要7分钟 文末有惊喜 哈哈 

此文章来源于：https://medium.com/swlh/enable-security-into-ci-cd-pipeline-with-devsecops-9370c93d87a1

DevOps的兴起改变了软件开发的前景。但是，尽管大多数参与软件构建过程的团队已经在利用这些方法，但是软件安全性仍然落后。

在本文中，我们将介绍DevSecOps，这是一种针对敏捷团队的安全性新方法。我们将讨论在实施时可能会遇到的一些挑战，提供一个简单的起点的示例，并举例说明可以在旅途中提供帮助的工具。

1.问题：安全性的瀑布模型

通常，漏洞检查是在开发过程结束时执行的。它们会产生大量文档，并可能迫使大部分代码被重写。这种方法还会在团队之间造成摩擦：当开发人员试图快速发布并交付价值时，瀑布式安全措施最终会拖慢该过程。测试大部分是手动的，可能需要很长时间才能完成。大多数时候，开发人员首先没有必要的工具来避免出现问题。

2.DevOps的好处

在查看DevOps时，我们可以看到针对大多数这些问题的解决方案。在其出现之前，开发人员曾经将运营团队视为障碍，从而减慢了发布速度并停止了创新。操作人员认为开发人员不在乎环境的成本，安全性或可靠性。

通过使用自动化并专注于协作，DevOps范例极大地改变了这种看法。现在，运营成为推动者：它不仅可以预防问题，而且还可以积极提供价值，从而加快开发速度。

单元测试和集成测试在每个构建中都执行，并且仅在提交后构建未中断的情况下，代码才发送到主分支。此外，DevOps将发布转换为正常和频繁发生的事件。结合测试自动化，这可以缩短反馈周期：整体上，使用DevOps的组织已变得更快。

在某些情况下，这些原则被推到了极致。该代码以完全自动化的方式编写，测试并发送到生产环境。在这里，瀑布式安全措施不仅效果不佳，甚至不可能。

3.转移管道中的安全性

如前所述，漏洞检查通常在开发过程结束时执行，这可能会导致后期且昂贵的调整被推迟到产品积压，延迟功能，甚至推迟产品发布。通常，这种情况会影响业务目标，降低团队满意度并在团队之间产生冲突（Dev与InfoSec）。

幸运的是，DevOps实践已经存在了一段时间，它致力于最大化软件开发价值流的性能，引入了一些关键概念，这些概念对于使Security成为开发管道中嵌入的另一个主题极为有价值，这就是术语DevSecOps。

尽管实现持续集成和持续交付（CI / CD）概念的自动化管道为传统的安全方法（开发团队发展得太快）提出了新的挑战，但它也为愿意接受它的团队提供了机会。DevSecOps的本质是在整个管道中嵌入安全性流程，并将DevOps原理和理念应用于与安全性相关的计划。使用这种方法，安全性分析可以在软件开发生命周期的早期进行（左移），从而限制了其发现的影响。

4.但是……我们到底可以投入什么呢？

实际上，这取决于特定解决方案或产品的要求和约束，因为InfoSec团队每天都会使用许多工具和策略来完成他们的工作。列举其中一些：静态应用程序安全性测试（SAST）；动态应用程序安全测试（DAST），交互式应用程序安全测试（IAST）；和软件组成分析工具。每个组件都处理一组特定的安全风险，并且可以按照DevOps原则构成敏捷开发生命周期。

在管道中同时使用SAST和DAST可以涵盖代码库和运行时漏洞，并且虽然OWASP Find Sec Bug之类的SAST解决方案可以在较早阶段使用，甚至可以集成到开发人员的IDE中，但Arachni或ZAP等DAST工具可以在构建步骤中自动部署。

可以在管道中插入其他安全技术：

• 使用OWASP Dependency-Check或Retire.js之类的软件组成分析工具检查导入的库将检测开发人员使用的开源库上的许可风险和已知漏洞；

• 通过使用例如Inspec，Nmap或基于云的工具来分析和强化基础结构；

• 使用git-secret或类似的解决方案公开检查秘密；

• 针对与SQLMap，SSLyze等有关的特定问题。

  

此外，诸如OWASP Glue或Gauntlt之类的包装器可以提供一个通用的界面来自动化许多开源工具，包括已经提到的大多数解决方案。

尽管上面所有示例工具都是开放源代码产品，但也存在商业解决方案，并且通常需要付费才能提供附加功能和更完整的报告，但仍然能够插入CI / CD管道。一个例子就是BlackDuck软件，它是一种软件组成分析解决方案，它不仅能够验证依赖项的漏洞和许可信息，还可以提供补救指南。

但是，将整个安全工具链部署到任何现有管道中都可能会面临挑战，因为可能会有大量的推后推，并且必须注意不要扭曲项目的日常活动。当然，最好一次集中精力在一个方面，避免造成干扰，并逐步推广。在每次迭代中，在集成更简单的安全工具和实践时获得的反馈和经验将成为解决更复杂的解决方案的实现并确保计划得到适当处理的宝贵资产。

确保管道中每个新增加的步骤都能够带来价值并被所有相关团队和更高利益相关者正确接受是至关重要的。请记住，每次检测到漏洞都会中断构建，这也会给开发人员带来麻烦和沮丧，他们期望快速的管道构建时间以及一组工具和流程定义可以帮助InfoSec快速解决安全问题并进行跟踪。

因此，为了顺利使用DevSecOps，最好采用一种简约的方法，对测试进行微调，并针对代码库中特定的高风险部分。快速的构建过程对于开发管道至关重要，应保持在控制之下，因此仅应添加必要的新步骤。为了处理繁重的工作，请创建新的策略以启用较慢的测试，这些测试可以在夜间执行，也可以通过并行，无阻塞的构建执行。

够用了，让我们举例说明如何通过融入DevSecOps实践的开源技术来实现真实的安全验证方案。

5.练习DevSecOps：起点

开始时，检查机密（即密码，API密钥和其他凭据）是否被公开是最简单的安全验证之一。除了目标简单之外，它还解决了代码开发中的真正安全问题。

为了展示这一点，我们将描述如何使用诸如Jenkins和git-secrets之类的开源工具来验证git存储库中敏感信息的存在，这些信息可以很容易地实现为DevSecOps CI / CD管道自动化。

第一步包括在Linux上安装git-secrets，这是通过Makefile执行的（更多信息可以在此处找到）。完成后，我们很清楚地添加了代码库中不应该存在的模式列表，然后扫描项目存储库。

下面的示例显示了安装过程以及AWS IAM密钥的常见验证模式，其中包括“ git secrets-register-aws”命令。

使用此解决方案时，“扫描”命令将查找保存到存储库中的机密，“扫描历史”将提供更深的外观，并包括由新提交修改的代码。如果找不到任何匹配的模式（如下所示），工具执行将返回“ 0”，否则将返回“ 1”。

这简化了与Jenkins之类的工具的集成，并允许返回值充当停止构建过程的标志。本文中提到的其他工具的工作方式类似，有助于与CI管道集成。

在下图中，显示了Jenkins和git-secret的组合。

如我们所见，git-secrets还会打印存储库中找到的密钥以及这些密钥的位置。除了使用此信息解决问题外，它还可用于检查密钥是否仍处于活动状态，上次使用时间以及其他相关数据。

当找到密钥本身上的模式匹配密钥时，将通过变量名称检测秘密。虽然将阻止名为“ aws_secret_key”的变量，但不会阻止名为“ secret”的变量。还值得注意的是，如果该解决方案直接挂接到每个开发人员的本地存储库，则即使在推送此代码之前，它也会阻止违反规则的提交。

6.渗透整个管道

当然，仅对构建步骤进行检查不足以创建安全的管道。在部署阶段，我们需要跟踪将什么代码发送到生产环境，谁在代码上签字，并确保该代码不会被篡改。

我们还应该关心生产环境。检测常见的攻击类型和加强基础架构的重要性与以往一样重要，AWS等云平台已经提供了用于此目的的工具（AWS Config，Cloud Trail，Inspector GuardDuty…），但仍然存在开源解决方案。与InStatsD和Kibana之类的工具结合使用时，Chef Inspec和ModSecurity可以提供巨大的价值。

此外，还存在特定于体系结构的问题。即使所有安全测试都表明系统提供了高度的安全性，我们也不能保证进程是否会暴露威胁。例如，销售点系统上的弱认证可能会导致社会工程攻击。解决此类问题需要在设计阶段彻底考虑安全性。

7.与审计师打交道

在自动化安全测试堆栈时，我们可能会遇到的一个问题是审核员的退缩。

对于他们来说这是一个新领域，首先，他们可能会对这种方法的可行性或有效性持怀疑态度。将它们包括在旅途中，解释自动化可以为流程带来的优势非常重要。演示如何减轻风险，并讨论自动化管道的更高可靠性。可能值得创建一个文档，列出与您的应用程序相关的风险，并说明将这些风险最小化的步骤。

8.结论

DevSecOps是一个复杂的主题，可能导致团队内部以及与审核员之间的摩擦。因此，应将其部署分解为较小的部分，使我们充分关注每一步，一次完成。尽管如此，我们还必须记住，检测漏洞只是工作的一半，而赋予开发人员权力可以帮助他们快速解决检测到的问题。

自动化和DevOps原理的应用将帮助安全团队在敏捷环境中保持正常运转。这是一种新的安全方法，专门针对它的工具才刚刚开始被广泛采用。

在本文中，我们列出了一些可用的工具，以及一个简单的示例来开始使用该概念。

---