浅谈企业 DevSecOps 实践: 构建安全工具链

系列文章（1）：浅谈企业 DevSecOps 实践：基本原则

系列文章（2）：浅谈企业 DevSecOps 实践：安全如何与研发协同工作

系列文章（3）：浅谈企业 DevSecOps 实践: 安全测试集成

在本文中，我们将向 你展示如何在 你的 DevOps 自动化框架中集成安全性。 我们将要解决的问题是“我们希望将安全测试集成到开发管道中，并将从静态分析开始。 我们该怎么做? ” 、“我们理解“左移” ，但这些工具有效吗? ” 以及“ 你建议我们从哪些工具开始，以及如何集成这些工具? ” . 由于 DevOps 鼓励在开发和部署的所有阶段进行测试，我们将讨论构建的管道会是什么样，以及适合不同阶段的工具。 安全测试通常与质量保证团队可能已经部署的功能测试和回归测试并列。 除了这些典型的在构建之后的测试点之外， 你还可以在构建之前在开发人员的桌面上进行测试，在构建之前和之后的代码库中进行测试，以及在预部署阶段进行测试。

构建安全工具链

静态分析

静态应用程序安全测试(SAST)检查所有代码或运行时二进制文件，以支持对常见漏洞的彻底搜索。 这些工具在发现缺陷方面非常有效，即使是已经经过人工审计后的代码也是如此。 你的选择标准可能归结为扫描的速度，易于集成，结果的可读性和较少的误报。 这些平台中的大多数已经在提供对开发人员有用的分析结果方面做得很不错了，而不仅仅是安全极客。 许多产品正在升级，通过 API 或构建脚本提供完整的功能。 如果可以选择，可以选择带有 API 的工具集成到 DevOps 流程中，这些工具不需要“代码完成”。 我们已经看到这些测试的使用略有减少，因为它们通常需要几个小时或几天才能运行——在 DevOps 环境中可以防止它们作为认证或部署的通道而内联运行。 正如我们在上面的“其他”部分所提到的，大多数团队正在调整以支持带外(或者我们称之为“并行化”)的静态分析测试。 如果可能的话，我们强烈建议尽可能内联SAST测试，并且关注新增的代码部分以减少运行时间。

动态分析

动态应用程序安全测试(Dynamic Application Security Testing，DAST)不是扫描代码或二进制程序(如 SAST) ，而是动态地“爬行”应用程序的接口，测试它对各种输入的反应。 这些扫描器不能看到幕后发生了什么，但是它们提供了对代码行为的有价值的洞察力，并且可以清除其他测试在动态代码路径中可能看不到的错误。 好消息是他们的误报率很低。 这些测试通常是针对完全构建的应用程序运行的，并且具有破坏性，因此这些工具为了能够在测试环境中更积极地运行，通常需要提供一些设置。 就像 SAST 可能需要一些时间来完全扫描代码，，因此在测试中，一个版本通常只针对新代码运行，而整个应用程序扫描是“并行”运行的。成分和脆弱性分析

成分分析工具检查开放源码库的版本，以评估开放源码的风险，包括安全漏洞和潜在的许可问题。 像 Heartbleed、配置错误的数据库和 Struts 漏洞可能根本不是应用程序测试的一部分，但它们都是关键的应用程序栈漏洞。 有些人将漏洞测试等同于 DAST，但是还有其他方法来识别漏洞。 事实上，漏洞扫描有几种类型; 一些看起来像平台配置、补丁级别或应用程序组合等设置来检测已知的漏洞。 确保扩大扫描范围，以包括应用程序、应用程序堆栈和支持它的开源平台。

人工代码审计

一些组织发现完全实现自动化部署有点吓人，因此他们希望在新代码上线之前有人来审计变更——我们理解这一点。 但也有很好的安全理由进行审计。 在一个像 DevOps 这样以自动化为中心的环境中，使用或认可人工代码审计或安全检查可能看起来是与之相对立的，但是人工代码审计仍然是非常可取的。 某些类型的漏洞不是扫描工具可以识别的。 人工代码审计经常捕捉到测试遗漏的明显内容，而开发人员在第一次(唯一一次)通过时可能会遗漏。 开发人员编写安全单元测试的能力各不相同。 无论是由于开发人员的错误还是审计人员的技能，编写测试用例的人员都可能会遗漏人工审计所捕获的内容。 你的工具应该包括人工代码审计——至少对新代码进行定期抽查，或者像 Dockerfile 之类的扫描中经常省略的东西。

运行时保护

许多公司仍在利用 Web 应用程序防火墙，但 Web 防火墙的使用正在下降。 我们看到越来越多地公司在生产环境中使用运行时应用程序自我保护来加强日志记录和保护工作。 这些平台提供工具代码，提供运行时保护，并在某些情况下识别应用程序里了哪些代码行是易受攻击的。

DevOps 要求你进行更好的监控，以便收集指标，从而可以根据操作数据进行调整。 为了验证新的应用程序部署是否正常运行，通常内置监视和检测。 在某些情况下，这些是使用自定义包和 ELK 堆栈实现的，在另一些情况下，则只需在生产环境中打开日志记录和“调试”风格的语句(通常在开发阶段使用)。 这在公有云 IaaS 中更为突出，在本地日志不能提供充分可见性的情况下， 你完全负责数据和应用程序安全。

安全单元测试

单元测试是检查应用程序中较小的子组件或片段(“单元”)。 这些测试由程序员在开发新功能时编写，通常由开发人员在代码提交到仓库之前运行，但也可能在构建管道中运行。 这些测试应该是长期的，与新代码一起存入代码存储库，并由每个后续的开发人员运行，这些开发人员为代码模块做出了贡献。 对于安全性来说，这些攻击可能很简单(比如针对 web 表单的 SQL 注入) ，也可能是针对被测功能的更复杂的攻击(比如业务逻辑攻击) ，所有这些都是为了确保每一段新代码都能正确反映开发人员的意图。 每个单元测试都侧重于特定的代码片段，而不是系统或事务。 单元测试试图在过程的早期捕捉错误，按照Deming的说法，越早识别出缺陷，修复它们的成本就越低。 在构建单元测试时， 你将需要支持开发人员和基础设施来体现你的测试，并且还要鼓励团队足够认真地对待测试以构建良好的测试。 让多个团队成员编写相同的代码并编写单元测试，有助于识别出单个程序员可能没有考虑到的弱点。

安全回归测试

回归测试验证最近更改的代码是否仍然按预期的方式运行。 在安全方面，这对于确保漏洞得到修复尤为重要。 Devops 回归测试通常与功能测试并行运行ーー在构建了代码堆栈之后。 在某些情况下，这可能需要在一个专用的环境中进行，在这种环境中， 安全测试可能具有破坏性，并在具有真实客户数据的生产服务器上产生一些不可接受的副作用。 利用虚拟化和云基础设施可以加快新测试环境的实例化。 测试工作本身通常就是通过自己构建的测试用例利用以前发现的漏洞，无论是作为单元测试还是系统测试都是如此。 测试用例的编写人员使用这类测试来确保像密码和证书这样的凭据不包含在文件中，并且基础架构不允许访问端口22或3389。

混沌工程

混沌工程通常在生产环境中引入随机故障，以了解应用程序环境如何处理不利条件。 像 Netflix 这样的公司已经率先在这个领域做出努力，以迫使他们的开发团队理解常见的故障类型，并在他们的代码中构建优雅的故障和恢复。 从安全性的角度来看，如果攻击者可以强制应用程序进入坏的状态，那么他们通常可以强制应用程序执行不打算执行的任务。 将坚固性构建到代码中可以提高可靠性和安全性。

模糊测试

最简单的模糊测试实质上是向应用程序丢弃大量随机的垃圾，看看是否有任何特定(类型)的垃圾会导致错误。 许多动态扫描供应商会告诉你他们提供了模糊测试。 实际上并非这样。 去参加任何安全会议，比如Black Hat、 DefCon、 RSA 或 B-Sides 后你都会发现，大多数安全研究人员更喜欢通过模糊测试查找易受攻击的代码。 这种方式已成为识别可能被攻击者利用的存在缺陷的代码的关键。 在过去的10年里，随着敏捷开发过程，甚至是 DevOps 的出现，开发团队和 QA 团队对模糊测试的使用逐渐减少。 这是因为它很慢; 执行一个大型恶意输入测试任务运行需要大量的时间。 这对于 web 应用程序来说不是什么大问题，因为攻击者不可能把所有东西都扔进代码里，但是对于交付给用户的应用程序(包括移动应用程序、桌面应用程序和汽车系统)来说，问题就很大。 我们几乎排除了这一部分，因为在使用中很少看到真正的模糊测试，但是对于关键系统，定期和带外模糊测试应该是 你的安全测试工作的一部分。

风险及暴露分析

将来自应用程序扫描中发现的安全问题集成到 bug 跟踪系统中，在技术实现上并不困难。 大多数产品都将其作为一个内置的特性提供。 困难的部分是弄清楚一旦获得数据后该如何处理。 被发现的安全漏洞真的是一个问题吗？ 如果不是误报，是否可以利用漏洞？ 相对于其他一切，它的临界性和优先性是什么？ 如果我们选择解决这个漏洞，我们又该如何从一系列选项(单元测试，补丁，RASP) 中选择一种方式来进行处理？

另一个需要考虑的方面是，这种信息的分布不会使利益相关者超负荷。 使用 DevOps， 你需要关闭基础设施、安全测试以及代码等问题的循环。 Dev 和 Ops 为大多数漏洞提供了不同的可能有效的解决方案，因此管理安全的人员里面也需要包括运营团队。 修补、代码变更、阻断和功能性白名单都是关闭安全漏洞的选项; 所以你需要 Dev 和 Ops 来权衡利弊。