1、背景

       我在闲谈自动化应用安全测试工具中提到这么句话“如果能将安全融到DevOps里，又不影响现有的状态，那当然是最好不过了”，这个时候你可能就有疑问了，现有的安全测试模式是怎样的，为啥要做改变呢？为啥非要融到DevOps里面呢？我们来盘盘安全测试几大经典痛点。

       DevOps的终极目标：提升软件交付的质量內建以加速流程。那么问题来了，这里的质量侧重点在功能，在于功能能用，好用。那么交付物的安全要如何保证呢？以前基本都是在程序/软件上线后，对其进行渗透、漏扫等待工作，来排除一部分安全风险。在快速持续交付的DevOps下，以下几个问题就凸显出来了。

  1. 代码中使用的组件本身安全性无法得到保障；
  2. 开发周期短，版本迭代频繁，难以实现每个版本都完成安全测试；
  3. 目前以代码审计为基地的安全审计误报和漏报率过高，需要人工复合，人力资源耗费较大；
  4. 开发人员和测试人员安全相关知识体系薄弱，安全人员开发知识体系薄弱，三方沟通有一定屏障；
  5. 多数公司安全测试主流为渗透测试，对于代码和功能本身逻辑缺陷无法在研发过程中发现，后期改动对整体架构可能影响很大；

       说完上面几个痛点，这个时候就希望能有那么一个或几个工具，能在应用上线前实现以下几点：1、在提交代码阶段就能自动检测代码组件安全性、代码的逻辑漏洞；2、在提测阶段功能测试进行的同时进行安全测试，且不增加测试人员工作量；3、预发布环境模拟黑客的攻击手段，对应用进行安全测试。于是乎，就有了今天我要讲的三板斧：SAST、IAST、DAST。

（当然，安全测试左移更合适的是从产品立项开始就介入，此方向后续有空再更新，本文着重从代码开发到上线前夕的安全测试。）

2、DAST

2.1、DAST简介

       DAST全称是动态应用程序安全测试（Dynamic Application Security Testing），是一种黑盒测试，也是目前业界用的最多的，使用相对而言最简单的一种安全测试方法。在程序运行阶段进行分析，模拟黑客攻击，并捕获程序反应，从而确定该应用是否会受到攻击。就像在上了锁的房子外看屋内，通过各种方法，一次次的去试探，看有没有可以利用的漏洞，

2.2、DAST原理

  1. 通过爬虫爬取web应用结构；
  2. 根据爬虫结果分析，对发现的页面使用准备好的poc进行攻击尝试；
  3. 对返回的结果进行分析，确认是否存在漏洞；

2.3、DAST优势

       安全测试人员无需具备开发能力，无需了解程序内部架构，对程序语言、框架无限制，能发现大部分高分析问题。

2.4、DAST劣势

1、对于爬虫无法发现的url束手无策；

2、随着技术的发展和新漏洞的披露，厂商需要不断的更新漏洞扫描插件；

3、针对需要需要提交某些特殊参数的场景，DAST同样显得捉襟见肘；

4、主战场在web应用程序，来到app战场上也有点力不从心；

5、发现漏洞定位层级在url止步，无法更深层次的探索漏洞原因，需要花费大量时间进行定位和分析，这对于持续交付理念的DevOps就显得很不友好了。

3、SAST

3.1、SAST简介

       SAST全称是静态应用程序安全测试（Static Application Security Testing），顾名思义对没有跑起来的静态代码进行安全测试。目前而言，多数开发人员对于代码开发的侧重点在业务功能的实现，对于安全开发的意识不够甚至可以说薄弱， 于是乎，在代码开发这个阶段积累了大量的安全风险。SAST就提供了对源代码进行安全测试分析安全漏洞的能力。

3.2、SAST原理

闲谈安全测试左移三板斧_安全测试

  1. 首先通过调用语言的编译器或者解释器把前端的语言代码（如JAVA，C/C++源代码）转换成一种中间代码，将其源代码之间的调用关系、执行环境、上下文等分析清楚。
  2. 语义分析：分析程序中不安全的函数，方法的使用的安全问题。
  3. 数据流分析：跟踪，记录并分析程序中的数据传递过程所产生的安全问题。
  4. 控制流分析：分析程序特定时间，状态下执行操作指令的安全问题。
  5. 配置分析：分析项目配置文件中的敏感信息和配置缺失的安全问题。
  6. 结构分析：分析程序上下文环境，结构中的安全问题。
  7. 结合2）-6）的结果，匹配所有规则库中的漏洞特征，一旦发现漏洞就抓取出来。
  8. 最后形成包含详细漏洞信息的漏洞检测报告，包括漏洞的具体代码行数以及漏洞修复的建议。

3.3、SAST优势

       SAST从语义、依赖关系、配置文件进行分析，从代码源头发现问题，比从被锁的房子外去发现问题的DAST的检测对象要丰富的多，甚至不需要代码跑起来就能发现问题。

从效率上而言，在代码开发阶段就能发现问题，能及时的进行修正调整，避免后续出现问题需要修改框架的可能性，修复成本更低。

3.4、SAST劣势

       看了上面的过程，是不是感觉从源码下手的SAST就能彻底解决安全问题了呢？人无完人，更何况它只是一个工具呢。

       支持的语言方面，SAST对于需要进行测试的语言和框架是有一定限制的，如果遇到不适配的语言，就只有无可奈何了。

       扫描时间方面，对于源码的分析并没有我们想象的那么快速，扫描一次需要数小时或者更久。

       关于误报，目前商业级别的工具误报率至少是30%，误报会导致我们对工具的实用性产生怀疑，同样需要时间来进行漏洞真实性的判断。

4、IAST

4.1、IAST简介

       IAST全称是交互式应用程序安全测试（Interactive Application Security Testing），综合了DAST和SAST的优势，曾被Gartner咨询公司列为网络安全领域的Top 10技术之一，具有误报率极低、可以定位漏洞所属api及代码片段等优势。

4.2、IAST原理

       目前IAST实现的原理有代理、VPN、流量镜像、插桩四种模式，本文着重介绍插桩模式。

       插桩模式：一般是在代码运行的中间件上进行插入探针，常见的有tomcat、spring boot等，通过探针获取程序运行时的请求、代码数据流、代码控制流等，结合请求、代码、数据流、控制流综合分析进行漏洞的判断。插桩模式又分为主动模式和被动模式。（由于此处篇幅过大，简略带过，后面将针对IAST单独出文，敬请期待......）

4.3、IAST优势

       插桩模式的IAST所处的地理位置优势，漏洞测试准确性高，误报率极低。发现的安全漏洞既可定位到代码行，还可以得到完整的请求和响应信息，完整的数据流和堆栈信息，便于定位、修复和验证安全漏洞。支持测试AJAX页面、CSRF Token页面、验证码页面、API孤链、POST表单请求等环境。能发现代码中使用的第三方组件的版本和包含的公开漏洞。

       插桩模式还可以在完成功能测试的同时完成安全测试，无需额外投入时间完成安全测试，不会影响破坏开发流程，适合持续交付理念的DevOps模式。

4.4、IAST劣势

       不支持C、C++、Golang等无需虚拟环境运行的语言，插桩模式是agent-server模式，agent的每次更新都需要重启sever端，部署工作量大。在业务逻辑面前，IAST同样无能为力。

5、总结

       总的看来，在开发阶段适合使用SAST，提测阶段适合使用IAST，在预发布/线上适合使用DAST。三个技术各有各的好，也同样有各自的毛病，使用得当，就能在各自所在的阶段能扬长避短的发现更多的安全风险，将安全问题扼杀在摇篮之中。