Loading

DevSecOps之应用安全测试工具及选型

上篇文章，有同学私信想了解有哪些DevSecOps工具，这里整理出来，供大家参考（PS: 非专业安全人士，仅从DevOps建设角度，给出自己见解）

软件中的漏洞和弱点很常见：84%的软件漏洞都是利用应用层的漏洞。软件相关问题的普遍性是使用应用安全测试（AST）工具的主要动机。通过使用AST工具，企业可以在软件开发生命周期中快速地检测潜在的安全问题，提高应用程序的可靠性和安全性，降低安全风险。
image.png
随着越来越多的应用安全测试工具的出现，信息技术（IT）领导、开发人员和工程师可能会感到困惑——不知道哪些工具可以解决哪些问题。


如上图所示，从下往上，成熟度和实现难度依次增大。

静态应用程序安全测试

Static Application Security Testing (SAST)，仅通过分析或者检查应用软件源代码或字节码以发现应用程序的安全性漏洞，侧重检查代码安全，如C/C++缓冲区溢出、身份认证与授权等, 避免产生可利用的弱点。
SAST 工具主要用于 SDLC 的编码、构建和开发阶段。

动态应用程序安全测试

Dynamic Application Security Testing (DAST)，通过运行程序来检查应用软件的安全性问题，侧重从系统外部接口来进行针对性的测试，暴露应用程序接口的安全性漏洞。
DAST 是一种自动黑盒测试技术，测试这主要从外部进行测试, 它模仿黑客与您的 Web 应用或 API 交互的方式。它通过网络连接和检查应用的客户端渲染来测试应用，就像渗透测试工具一样。 DAST 工具不需要访问您的源代码或自定义来扫描堆栈。它们与您的网站交互，从而以较低的误报率发现漏洞。

交互式应用程序安全性测试

Interactive Application Security Testing (IAST)，整合了SAST和DAST这两种方法，可以发挥各自的优势、降低误报率，发现更多安全漏洞，从而提高安全性测试效率。
交互式应用安全测试就是通过把安全工具的代理嵌入到应用程序里面，从而在测试应用程序的时候，这个安全代码能够监控到应用系统的网络内容，堆栈等信息，从而嗅探出系统在动态行为下的安全漏洞, 内容具体到发生漏洞的代码行。

软件构成分析

Software Composition Analysis (SCA)，专门用于分析开发人员使用的各种源码、模块、框架和库，以识别和清点应用系统（OSS）的组件及其构成和依赖关系，并识别已知的安全漏洞或者潜在的许可证授权问题，把这些风险排查在应用系统投产之前，以加快确定优先级和开展补救工作。
此外，它们还可无缝集成到 CI/CD 流程中，从构建集成直至生产前的发布，持续检测新的开源漏洞。大白话，找出软件里面的“科技与狠活”

应用程序安全测试编排

Application Security Testing Orchestration (ASTO)，随着数据中心规模的不断增大，网络以及安全服务数量也随之不断的增长，安全运维更是难上加难。面对越来越复杂的网络和安全场景，安全编排(Orchestration)工具应运而生，能够安全自动化和服务编排，如可以连接诸如Splunk、QRadar等安全数据分析工具，利用其提供的大量安全事件数据，通过自动化的脚本，采取一系列的方法进行安全事件的响应。

应用程序漏洞关联

ASTO 将软件开发生命周期内的安全工具进行整合，尤其在 DevSecOps中发挥举足轻重的作用，而AVC（Application Vulnerability Correlation，应用程序漏洞关联）工具是指工作流与流程管理工具，让软件开发应用漏洞测试和修复实现流线化。
这些工具将各种安全测试数据源（SAST、DAST、IAST、SCA 、渗透测试与代码审核）融入到一个中央化的工具中，AVC 工具能够将安全缺陷形成中心化数据，进行分析，对补救方案进行优先级排序，实现应用安全活动的协作。

**上面5、6点，属于比较综合的方案，大白话，从“安全”的视角，去看看研发活动的产出 （代码，制品，环境等等资产）有没有安全漏洞风险，并且归类融合去重统一，实现思路上，有点像DevOps流水线，剑走偏锋。**目前，国外类似的解决方案有一些，国内很少，我也在持续跟踪研究中。

安全测试工具适用阶段

如下图所示
devsecops-pipeline.png

  • SAST适用于应用程序开发早期或集成/构建阶段，提供代码级别的反馈；
  • IAST可以在应用程序的运行时进行安全测试，并提高漏洞的发现率；
  • DAST适用于应用程序发布前进行黑盒测试；
  • SCA可以检测应用程序依赖的第三方软件组件中的漏洞。

综合使用这些工具，可以在应用程序的开发、测试和部署阶段及时发现和纠正潜在的安全漏洞。

如何选择适合自己企业的安全工具

如下图所示，根据研发活动的过程，我对相关的安全工作做了领域和业务的划分，部分工具可能会贯穿多个阶段。

选型原则

  1. 你需要解决什么问题？哪些阶段是你关注的？
  2. 工具的成本，是否有资金支持采购商业软件？虽然开源的安全工具很多，不过“安全”是个严肃且专业的领域，商业软件还是有很多“硬核”实力
  3. 发现安全问题了，你是否能解决修复？这决定了，你是否会使用这些工具，更重要的是背后的运营流程，否则工具只是工具
  4. 你所在的行业的要求是什么？政府和机构的要求是什么？
  5. 选择的安全工具是否能融入DevOps流水线？是否周边生态插件丰富？是否支持二次开发？
  6. 是否有专业的安全人士，能够使用选中的工具，并驾驭？

个人看法

  • 从实践难易程度和成本最低来看， “ 编码阶段“ 应该是成本最低，工具最多（比如sonarqube 估计是下面图中，你最熟悉的，烂大街的），离开发人员最近的阶段。
  • 从”安全“左移的角度，在”编码阶段“进行实施安全活动，从DevOps角度，浪费也是相对较少的。唯一不足，就是代码阶段的扫描，误报率稍微高，见仁见智。
  • ”容器安全“，也是一个值得关注的，由于云原生普及，周边生态丰富，可以选择的余地会多些，对于”中小企业“来说，成本最低。
  • 如果你的组织不差钱，直接商业工具，这个不用质疑，你的甲方爸爸也不会差钱，他要的是放心。

最后，安全工具仅仅是个开始，如何把工具融于流程，并且落地得到切实的执行才是难点。”安全“是个即”严肃“，又”专业“，同时又容易”被忽略“的活动，任重而道远。

PS: 下面图目前是V1.0版本，后续会持续更新 （图中标记的工具，可以做些尝试，开源的；不差钱的，请直接商业工具，专业的人做专业的事情）

DevSecOps工具.jpg

参考：

posted @ 2023-09-08 00:33  DevOps在路上  阅读(702)  评论(0)  编辑  收藏  举报