原创 chengable 2020-11-23 16:10
企业开发安全落地过程中，往往面对SAST、IAST、DAST、SCA等工具优先选择落地哪个的问题，本篇文章详细对比SAST、IAST、DAST，为企业安全工具选型提供参考意见
1.工具概述
SAST特点
基于源代码进行检测，可支持多种语言，检出率高，但误报率也高
DAST特点
基于流量进行检测，不分语言，不分平台，检出率中，误报率低
分为主动式和被动式，被动式一般来说效果会好一些
IAST特点
基于字节码进行检测，对语言和平台要求高
检出率高，误报率极低
2.功能对比
2.1 功能对比详情
红色为三种检测方式对比中的最差
绿色为三种检测方式对比中的最佳
对比项 | SAST | DAST | IAST |
开发流程集成 | 研发阶段集成 | 测试阶段集成 | 测试阶段集成 |
误报率 | 高 | 低 | 极低（利用自定义规则可以控制到0） |
测试覆盖度 | 高 | 较高，受功能测试覆盖度影响，同时有爬虫覆盖 | 中，受功能测试覆盖度影响 |
检测速度 | 随代码量呈指数增长 | 随测试用例数量稳定增加 | 实时检测，基本不用耗时 |
逻辑漏洞检测 | 不支持 | 支持部分 | 可以支持（使用较复杂） |
漏洞检出率 | 高 | 中 | 较高 |
漏洞检出率因素 | 与检测策略相关，企业可在当前数据流基础上制定策略 | 与测试payload覆盖度相关，企业自身可轻易优化和扩展 | 与检测策略相关，企业可在当前数据流基础上制定策略 |
第三方组件漏洞检测 | 支持 | 支持，基于web的指纹识别，效果比较差 | 支持 |
使用成本 | 较高，需要人工排除误报 | 低，漏洞基本无需人工验证 | 中，漏洞基本是正确的，但复现比较困难 |
部署成本 | 低 | 低 | 较高，需要与webserver底层结合 |
支持语言 | 多种，不同工具支持的语言不同 | 不分语言 | 严格区分语言 |
支持框架 | 部分框架，不同工具支持的框架不同 | 不分框架 | 严格区分框架 |
入侵性 | 无 | 较高，脏数据 | 中，需要与webserver结合 |
风险程度 | 低 | 较高，扫挂/脏数据 | 中，取决于agent的稳定性 |
漏洞详细度 | 较高，数据流+代码行数 | 中，请求 | 高，请求+数据流+代码行数 |
2.2 功能对比总结
2.2.1 SAST 功能优劣总结
通过上述表格对比分析
SAST的优势：
漏洞检测：检出率，覆盖度高
部署使用：侵入性小，风险程度低
SAST的劣势：
漏洞检测：误报高，耗时久
部署使用：人工成本高
2.2.2 DAST 功能优劣总结
通过上述表格对比分析
DAST的优势
漏洞检测：可进行逻辑漏洞检测
部署使用：不分语言和框架，漏洞好复现
DAST的劣势
漏洞检测：检出率和第三方框架检测效果较差，漏洞详细度较低
部署使用：入侵性较高，风险程度高
2.2.3 IAST 功能优劣总结
通过上述表格对比分析
IAST的优势
漏洞检测：误报率低，检测速度快，漏洞详细度高
部署使用：人工成本低
IAST的劣势：
漏洞检测：覆盖度较难以保证
部署使用：支持的语言和框架被严格限制
3.效果对比
3.1 效果对比依据
效果对比采用OWASP的benchmark为标准，是比较权威的安全效果评分
列举常见漏洞效果对比，重点需要关注TPR（漏洞检出率），FPR（漏洞误报率）
OWASP benchmark将当前最好的6款商业SAST做了评估，但未具体说明每个工具的评分，匿名评价，结果如下
未将IAST工具纳入对比，黑盒工具中只采用的ZED这款传统扫描器，该扫描器在黑盒工具中属于检测效果中等的，不及AWVS和APPSCAN
3.2 效果对比详情
SAST与DAST
XSS
SQL注入
命令执行
关注TPR（漏洞检出率），FPR（漏洞误报率）
我们可以发现SAST（白盒工具），普遍TRP漏洞检出率较高，但是FPR漏洞误报率，也非常高，在XSS,SQL注入，命令执行，三种漏洞的评估中，白盒审计工具误报率基本都超过了50%，最高的甚至达到102%，误报高于检出，这意味着白盒工具的落地，一定需要有经验的代码审计人员，针对扫描结果排除误报，再将漏洞报告交付给研发，漏洞流程才可以比较好的落地。
我们看到ZED这款黑盒工具的，误报率极低，基本无误报，误报最高也仅仅1.29%，但是在检出率上，仅仅只有40%左右，也符合我们在功能对比时候的结果，由于ZED这款工具是基于爬虫的黑盒工具，而且漏洞检测效果在商业级产品中，属于中等偏下，不及APPSCAN和AWVS，更不及被动式DAST，所以实际灰盒工具的检测分数，应该远高于ZED的检测分数，按照分数评分，应该是高于白盒工具的。
再来看市面上的IAST工具在benchmark中的检测结果
Hdiv detection
在IAST公司对外宣传上来看，基本都是误报率0，检出率100%，不过这个是对着benchmark这个靶场测试的，覆盖度可以保证100%，但是正常情况下，覆盖度会低一些
3.3 效果对比总结
单从测试综合效果上来说，IAST>DAST>SAST
分开来看
覆盖度：SAST>DAST>IAST
检出率：SAST>=IAST>DAST
正确率：IAST>=DAST>SAST
4 总结
如果单从效果来看，IAST效果最佳，误报率几乎为0，检出率较高，漏洞信息多，但是受限于支持的语言和框架，目前java的技术IAST技术比较成熟，被动式IAST还可检测加密和防重放的接口的安全问题，这是一个很重要的优势，在支付等重点场景基本只能靠IAST做工具覆盖或者人工手动渗透，同时测试覆盖度也跟人工测试的覆盖度有极大关系，由于agent与真实webserver集成，稳定性额外重要。
目前成熟的SAST产品支持的语言和框架都比较丰富了，已经不受限于语言和框架，SAST的部署，维护，侵入性，风险度都非常优秀，部署成本最小，维护成本最小，检测效果上由于是扫描源码，覆盖度和检出率可达到最好，但是SAST产品最大的痛点就在于误报问题，误报多导致SAST产品难以落地，太需要人工成本。如果解决了误报问题，SAST产品可完全取代IAST和DAST产品。
被动式DAST产品从本质上来说还是属于DAST，只是使用方式采用交互式，漏洞检出率，误报率，部署成本都属于中等级别，第三方组件检测效果较差，由于脏数据和扫挂服务的问题，导致维护成本较大，用户容易产生抵触心理，并且无法检测加密、签名和做了防重放的请求。
SAST属于编码阶段，IAST和DAST都属于测试阶段，IAST的出现，冲击最大的是同属于测试阶段的DAST类产品，但仅限于通用漏洞。不过大家慢慢应该也感觉到一个趋势，通用漏洞越来越少，框架越来越成熟，在框架中就帮助解决了大部分通用漏洞，业务逻辑漏洞慢慢成为主流，DAST类产品要不被IAST类产品取代，可以发力在业务逻辑漏洞上。
同时，DAST类产品的最大作用，第一是在很多场景下企业拿不到项目源码（比如第三方软件集成或者购买），此时安全问题的自动化发现方案还是DAST最佳，第二是在对大量目标扫描的时候，不分语言不分框架，无需在业务上部署东西，直接接入流量或者开启爬虫，开始扫描即可发现漏洞。
PS：后面两篇文章讲容器安全，一篇讲容器安全领域，一篇讲容器安全天花板级别的产品Twistlock
