《Gartner 2017研究报告：DevSecOps应当做好的十件事》和《Gartner 2019研究报告：DevSecOps应当做好的十二件事》两篇研究报告中都对成功实施DevSecOps进行了研究。两篇报告一致认为实施DevSecOps的关键挑战和第一要素是：“安全测试工具和安全控制过程能够很好的适应开发人员，而不是背道而驰”。安全团队想要将安全测试或安全控制成功的融入在DevOps中的前提是：
否则你将破坏DevOps的协作性和敏捷性，注定会成为众矢之的，最终无法落地。由于破坏DevOps的协作性和敏捷性而失败的惨痛案例笔者身边就有好几个。
应用安全测试在CI/CD软件开发周期中的集成点
WEB应用安全测试目前在市场上有众多的解决方案，其中最老牌、应用最为广泛的应属SAST和DAST这两类的测试工具，通过在源代码 (SAST) 或公开对外接口 (DAST) 上运行安全扫描，可以在应用上线之前识别并纠正许多漏洞。
然而随着 DevSecOps 被广泛接纳，Gartner 在 2017 年的研究报告中明确提倡用 Interactive Application Security Testing (IAST) 替换 SAST 和 DAST，原文如下：
接下来笔者分析一下 Gartner 为何如此推崇在 DevSecOps 中采用 IAST 来替换 SAST 和 DAST。
1、SAST 因效率差、误报率高无法敏捷的融入到 DevOps 中
首先我们对 SAST 实现原理进行简单分析，SAST 一般实现都是在不运行代码的情况下通过词法分析、语法分析、控制流、数据流分析等技术对源代码进行扫描，并利用复杂的检查规则匹配发现与定位缺陷，最后生成结果。
虽然 SAST 目前可以集成到开发者IDE环境并融入到 DevOps 中，但 SAST 往往需要比较长的扫描分析时间，实时性比较差，同时误报率也比较高，需要投入大量的安全团队的资源来去除这些误报。
除此之外，SAST 针对应用程序引用的第三方开源组件、开源框架也无法有效识别已知存在安全风险。
总之，SAST 实际应用在 DevSecOps 环境中并不轻松，除非你拥有非常充裕并且经验丰富的安全团队对其进行不断的优化、开发与维护。
2、DAST因适应场景有限及严重影响正常业务功能测试而无法融入到DevOps中
DAST 是目前应用最为广泛的 WEB 应用安全测试工具，市面上有些厂商把 DAST 经过改造偷换概念自称 IAST。IAST 产品鱼龙混杂，笔者身边就有因为选用了此类产品导致无法无缝融入 DevOps 的情况，为大家避免再次踩坑本文会花较大篇幅用于讨论 DAST 相关技术。
DAST 的原理相对比较简单，一般分为以下几个阶段：首先 DAST 利用爬虫技术获取尽可能全的应用URL后进行去重，然后分析和提取外部可能的输入点；其次针对每个URL中的输入点替换成不同漏洞类型的 Payload，实质上是篡改原始数据报文轮番地毯式向WEB应用重放 HTTP/HTTPS 报文，最终 DAST 收到WEB应用的响应报文对其分析来判断漏洞是否存在。
由于爬虫技术的天生缺陷，DAST 面临着诸多的挑战。首当其冲的是爬虫无法爬取应用完整 URL 的问题。如：当应用具有 AJAX、Token、验证码、独立 API 等情况，或者应用执行必须依赖上步执行结果逻辑的场景，比如在面对密码重置、交易支付等场景应用时均无法进行有效的覆盖。为了解决 DAST 爬虫技术的缺陷开始对其进行改造，通常将 WEB/APP 客户端访问应用时的流量进行代理，方法有通过浏览器配置代理、*** 流量代理等方式。对于非加密环境还可以通过交换机流量镜像、应用访问日志导入、在应用服务器上部署客户端获取流量等几种弥补方案，通过以上补救方案后 DAST 就可以规避一些爬虫技术的缺陷。
分析完 DAST 爬虫缺陷我们再来分析查找输入点和 Payload 替换阶段的缺陷。
根本原因在于 DAST 无法得知其测试应用所采用的加密算法与密钥，不能还原成明文，只看到一堆乱码密文无从获取有效的输入点，替换 Payload 就更无从谈起了。对于应用只有加签的场景对于 DAST 来说即使获取了有效的输入点，篡改原始报文替换 Payload 重放数据报文也不会被应用接受或处理。
