如何选择合适的SAST工具

随着敏捷开发的流行，安全左移的重要性也越来越重要，实现安全的自动化，也就需要大量工具的支持，SAST工具是其中非常重要的一个工具。如何选择一个合适的SAST工具就非常重要。本文集合自己几年的SAST的开发经验和多年的SAST的使用经验，介绍一些选择SAST工具的几个需要关注的重要的方面。

1. 支持的语言与框架

这一点不言而喻，工具支持的语言是最重要的，如果使用的语言工具都不支持或者支持的不足够好，这种工具再好，也没有用。

当然，语言支持了，只是第一步，因为一个工程的开发，不可能在原生语言基础上来开发的，都会需要使用各种各样的框架，而代码扫描时，又不会扫描这些框架的代码。SAST如果要想有一个很好的扫描结果，就必须针对各种框架结构进行定制支持。所以，在选择SAST工具时，不仅关注支持的语言，也需要关注支持的语言的框架。例如：针对Java语言，Spring框架的支持基本上都是标配，但是，当你使用的不是Spring的framework时，他是否依然支持。 一般每种SAST都会网页的帮助手册来说明有支持的语言以及语言相关的框架，将自己公司内部的框架整理一个列表，和这些支持的框架列表进行比较，查看是否能够真正地满足公司的需求。

2. 误报率

除了支持的语言之外，误报率是我觉得最最重要的一个指标了，曾经和一些朋友聊过，发现有的公司买SAST就是摆设，因为误报率太高，根本没法推行下去。想用起来，就必须做到两点：一是增加安全团队人员，对扫描结果进行初次筛查，然后再让开发人员进一步确认；二是把每一个开发人员都培养成安全专家，让他们有能力识别误报。无论是哪一项，都需要投入很大的人力和物力。

然而，误报是难免的。在关注误报的同时，还要看SAST是否提供一些误报的快速处理方法，例如：增加过滤器，可以统一处理所有类似的误报；是否支持自定义规则或者在原来的规则的基础上进行定制与改进。如果能够支持这些，安全团队就可以根据公司内部的公共的库或者框架进行统一定制。当然，如果厂家能够支持定制，那是最好的了。一般针对公共的框架结构厂家都会提供支持，所以，如果针对开源的框架结构需要支持而又不在厂家的支持列表时，是可以联系厂家让他们提供支持的。但是，针对公司内部的二方库，由于厂家不知道这些库的内部实现逻辑，就很难提供有效地支持。

3. 工具的集成

随着DevOps的推广，在开发过程中各种工具有效地集成在一起，才使得流程更加高效地运转起来，有效的工具支持，也会使得流程的推广更加简单。如果要想将SAST工具有效地利用起来，SAST工具就要有效地融入到开发流程当中，与使用的其他工具集成就是必备的一个功能，例如：与构建工具Jenkins集成、与IDE集成、与Bug管理系统集成等。如果SAST工具能够与构建系统集成，自动发起扫描，控制构建的结果的安全质量，同时能够将新发现的问题自动报Bug系统，这就使得工具的使用，让开发没有直接感觉到，也就不会抵触SAST工具的推广。当然，在对扫描结果进行审计之后，也需要自动地将误报处理好，这一点非常关键。

一般的SAST都会提供：命令行工具、SDK、插件以及API等多种集成方式，需要根据公司内部的工具使用哪一种集成方式比较方便。

4. 扫描速度

无论SAST使用的是什么技术路线，随着SAST融入到DevOps流程中，扫描的速度就不能阻碍流程的推进速度。首先，扫描速度就非常重要，当研发提交提交代码发起构建请求时，等待的时间不能太长，一个扫描达到小时级别的话，是难易接受的。其次，SAST是否支持增量扫描，因为增量扫描只扫改动的代码，可以有效地减少扫描时间。最后，就是SAST是否支持多引擎部署，因为，无论单引擎多快，当开发人员的扫描数量增加时，总是会出现排队的情况，而且排队的时间可能会很长。此时，多引擎部署就会很重要。当扫描需求增加时，就可以通过部署更多的引擎和负载均衡满足扫描的需求。

5. 是否需要编译源代码

很多SAST工具使用的技术是基于编译过程的中间结果进行建模与分析，这就需要代码是可编译的，如果不可编译，会导致没有编译通过的源代码是不会被分析到的，编译失败的源代码也可能会导致其他编译的源代码的分析结果误报很高。而且，编译也是很耗时间的，编译需要的很多依赖，也需要扫描的服务器能够访问。如果一个SAST部署在内网，不能访问Internet，公司内部又没有构建自己的代码仓库服务器，可能就会遇到问题。

目前的SAST有扫描源代码的，也有扫描二进制包的。扫描二进制代码的优势就是在构建服务器构建之后，将构建的结果发给SAST进行扫描，SAST不需要考虑编译和依赖等等问题，扫描速度也很快，但是，由于没有源代码，可能导致界面显示结果时，不是很容易看清某个问题到底是否是误报。扫描二进制代码的缺点就是：没有办法通过扫描结果控制构建的结果，因为扫描二进制代码必须在构建完成之后，才能扫描；而扫描源代码工具，可以在构建之前进行扫描，并且通过设置扫描结果的Quality Gate来控制此次构建是否继续进行下去。

无论使用哪一种技术，都需要在界面上有调用栈和源代码互动的界面才比较容易检查漏洞是否误报，如果有的工具没有提供这个功能，将会导致在代码审计时，非常痛苦，需要再对着源代码再一个一个调用栈查看，相当花费时间。

6. 客户支持

一个SAST工具从选型，试用，到最后的购买，以及在购买之后的顺利试用，这一系列的过程中，SAST的技术支持很重要。一个工具再好，也很难完全很顺利地符合一个公司各个方面的扫描需求。当遇到问题时，如何有效及时地解决问题是很重要的。例如：一个SAST工具支持自定义规则，让一个公司的安全工作人员或者开发能够掌握规则定制，是自学并制定规则要花时间的，如果客户支持很到位，可以提供相关培训让负责人更快地掌握如何定制规则，提高扫描效果，降低误报，就会让工具的使用效率大大提高，也更容易推广。

有的单位或者公司使用者可能对SAST工具不是很熟悉，只是负责扫描与检测的工作，他们在使用过程中，就会遇到各种问题；另外，没有些公司的研发工程师可能对一些漏洞的原理与预防也不是了解的很彻底，也难以提供完全正确的解决方案。这时，和工具相关的配套解决方案需要跟上，无论是培训，还是现场沟通与交流，都要跟得上，否则，客户自己也很难真正将工具用起来，也就难易体现他们购买工具的价值。

7. 报表功能

丰富的报表功能也是一个非常重要的功能，因为管理层想要了解工具的扫描效果时，就需要了解扫描结果的数据。如果一个SAST提供丰富的报表功能，而且，又能根据需求进行定制，就可以很好地收集相关数据和图形化显示结果共管理层做决策参考。

随着安全左移以及供应链安全的重视，SAST工具会更加有效地发挥其效力，但是，在选择的过程中也需要谨慎，需要根据公司的人员与流程的需求，列出几个重点关注的功能特点，并且在选型过程中，去验证这些功能特点是否满足需求。这样才能在SAST部署之后，能够充分发挥它的作用。

最后，关于工具的选型所关注的几个方面，简单总结如下表格：

选型项目	说明
支持的语言与框架	是否支持需要的语言？ 是否支持使用的框架？
误报率	是否达到预期设置的目标？ 是否有误报的有效处理方法？
工具的集成	是否支持使用的CI工具的集成？ 是否支持与Bug系统集成？ 是否支持与IDE工具集成？
扫描速度	是否影响CI/CD工具的构建？ 是否影响开发的开发效率？
是否需要编译源代码	是否有扫描项目的源代码？ 是否容易搭建项目的编译环境？
客户支持	是否能够提供及时的技术支持？ 是否提供工具相关的使用与集成培训与支持？
报表功能	是否提供公司需要的各种维度的报表？ 是否可以自己定制报表的内容？