前言
在企业内安全有一项很重要的工作，那就是应用安全测试AST（Application Security Test）。AST根据所用技术和场景的不同，一般分为SAST，DAST和IAST。
SAST：静态应用程序安全测试（Static Application Security Testing），对应用程序源代码执行直接的白盒分析。也就是我们常说的代码审计。分析是在代码的静态视图上运行的，这意味着代码在审查时没有运行。如今，SAST已经完全成为主流，并且在整个软件行业中被广泛采用。
DAST：DAST（Dynamic Application Security Testing，动态应用程序安全测试）对应用程序进行黑盒分析，这意味着它们不能访问代码或实现细节。DAST只检查系统对潜在漏洞测试的请求和响应。如我们最常使用的AWVS，Appscan等工具
IAST：IAST（Interactive Application Security Testing，交互式应用程序安全测试）结合了SAST和DAST的优点。IAST可以像SAST一样看到源代码，也可以像DAST一样看到应用程序运行时的执行流。如开源的洞态，以及其它的商业产品。
本篇文章主要来看看SAST技术的发展过程，以及在企业实践过程中遇到的问题。
SAST技术的发展
SAST的技术发展大概经历了下面的四个阶段，从最初的基于关键字匹配，到最后的基于语法树，IR/CFG的检测方式，后面还有codeql这种方式。
每种新的技术的出现都是为了提高工具的使用效率。
|
技术发展阶段 |
代表工具 |
优点 |
缺点 |
备注 |
|
基于正则-关键字匹配的方案 |
Seay：高覆盖，通过简单的关键字匹配更多的目标，后续通过人工审计进行确认；
Rips免费版：高可用性，通过更多的正则约束、更多的规则覆盖多种情况。 |
方案简单，实现起来难度不大 |
1. 无法保证开发人员的开发习惯及代码编写，误报率及漏报率非常高；
2. 无法保证高覆盖及高可用性；3. 维护成本太大。 |
|
|
基于AST(抽象语法树)的方案 |
Cobra：侧重甲方的静态自动化代码扫描，侧重低漏报率；
Kunlun-M：侧重于白帽子自用，只有准确的流才会认可，否则标记为疑似漏洞，侧重低误报率。 |
在编译处分析代码，无需关注开发人员的开发习惯（编译器是相同）。 |
1. 无法保证完美处理所有的AST结构；
2. 基于单向流的分析方式，无法覆盖100%的场景；3. 忽略了大多数的分支、跳转、循环这类影响执行过程顺序的条件。 |
常见的语义分析库：
PHP-Parser、phply、javalang、javaparser、pyjsparser、spoon |
|
基于IR/CFG这类统一数据结构的方案 |
fortify、Checkmarx、Coverity及最新版的Rips：都使用了自己构造的语言的某一个中间部分。 |
较于AST，该方法带有控制流，只需要专注于从Source到Sink的过程即可。 |
||
|
基于QL的方案 |
CodeQL：可以将自动化代码分析简化约束为我们需要用怎么样的规则来找到满足某个漏洞的特征。 |
把流的每一个环节具象化，把每个节点的操作具像成状态的变化，并且储存到数据库中。这样一来，通过构造QL语言，我们就能找到满足条件的节点，并构造成流。 |
SAST的优缺点
SAST的优点：
- 广泛的编程语言支持：SAST工具通常支持多种编程语言，使得开发者可以更容易地在其工具中使用自己熟悉的编程语言进行测试。
- 检出率较高：SAST工具能够检查出代码中的潜在错误和漏洞，因此具有较高的检出率。
- 可以定位到代码行：SAST工具通常可以提供详细的报告，包括发现的问题所在的代码行号，使得开发者可以更方便地找到并修复问题。
SAST的缺点：
- 准确性差：虽然优秀的SAST产品的误报率在53%以上，这可能会对开发者造成困扰，需要花费额外的时间去过滤和修复误报的问题。
- 无法看到执行流：SAST工具只能在代码静态分析的层面上发现问题，而无法像动态分析工具那样看到执行流中的问题。
- 通常需要一些定制或调参：不同的代码库和应用程序可能需要不同的设置和参数来进行有效的测试，这可能需要开发者花费一些时间去调整和定制工具的设置。
- 不适用于生产阶段的系统：由于SAST工具的运行可能会对应用程序的性能产生较大的影响，因此通常不适用于生产阶段的系统。
- 通常运行很慢：由于SAST工具需要进行全面的代码分析，因此通常运行速度较慢，可能需要较长时间才能完成测试。
漏报率与误报率
SAST最重要的两个指标就是漏报率和误报率了。
漏报率： 没有发现的漏洞/Bug
误报率：发现了错误的漏洞/Bug
在甲方的安全体系中，高漏报是无法接受的，所以大部分软件会采用高误报的解决方案，并逐步优化误报问题。但是有时高误报率也会导致项目的终止。安全工程师在面对“警告疲劳”时，那么业务人员处理报警的积极性就会大大下降。
漏报率与误报率的结果往往呈现负相关。规则设置宽泛的时候，漏报率自然降低，相应的误报率就会上升，反之亦然，因此我们必须在漏报率与误报率之间做一个平衡。
如何平衡漏报率与误报率
1）对于绝对不能接受的高危漏洞，规则可以设置的宽泛一些，对于那些危险比较小的，可以将规则尽量的进行优化
2）降低误报率和漏报率的一个关键就是需要不断的优化规则，要把每次扫描出来的误报进行复盘，分析误报/漏报的原因，以及是否可以在不漏报的情况下进行规则的优化
3）针对公司内部的使用框架定制特别的规则
4）使用新的技术，如语法树分析，AI识别：静态扫描必须存在高的误报率，是否可以通过语法树去分析，降低误报
5）设置相应的过滤的函数
6）结合黑盒/灰盒扫描的方式来降低误报
7）多种方式/工具共同验证的方式
SAST落地实践
在我们企业内部目前也已经实际落地了SAST检测，落地过程中大概分为下面的几步：
1）工具的选择
SAST很关键的一步就是工具的选择，这一步工作很可能决定了后面工作的难易程度以及项目是否可以顺利实施下去。
SAST工具一般有三种途径来获取：商业版本，自研，开源版本或者根据开源版本进行二开。这三种途径各有各的好处，根据企业的实际情况去选择就好了，适合企业的才是做好的。
商业软件使用方便，有专门的技术人员指导，但是商业软件技术壁垒比较严重，定制化开发比较困难，而且对于企业来说，花费也比较大。
自研可以开发出适合自己企业内部的工具，可开发流程比较长，需要专门的开发人员来进行维护
开源版本或者根据开源版本二开，该方式可能是最具有性价比的一种方式了。
工具选择可以从下面的方面去考虑：
- 是否可以覆盖公司内部的开发语言
- 规则定制化是否方便
- 规则库对漏洞的覆盖率
- 工具的误报率和漏报率
- 是否可以接入到现有的开发流程中
- 工具使用的便利性
- SAST的合规性，是否符合相关法规和标准
- 工具的结果输出是否详细以及规范
最后比较了几款工具以后，我们还是选择了通过开源工具进行二开的方式来构建SAST检测。
选择了Cobra进行定制开发，同时对于java语言，结合codeql进行组合使用。
2）对工具进行定制化
选择了工具以后，要对工具的一些规则进行定制化设置，对一些误报率较高的规则进行优化，以及结合企业内部使用的框架进行一些定制化的规则。
3）接入CI/CD流水线
白盒扫描最好是能接入到你们的开发流程中，这样开发提交代码以后就能自动进行扫描。我们是在jenkins的流水线中进行了配置，当测试环境进行jenkins部署时，会触发自动化的检测脚本。
4）测试结果分析
刚开始接入白盒扫描，你会发现存在大量的误报，这时就需要人工介入，对扫描结果进行分析并确认漏洞，将漏洞提交相关的项目组进行修复。
同时要关注工具的误报率以及漏报率，为优化规则提供实例。
5）持续改进
这个也是使用过程中最重要的一点，那就是要持续改进工具的效率。在甲方的安全体系中，高漏报是无法接受的。因此在发现了出现漏报的情况后，一定要分析其出现的原因，然后去优化规则或者改进工具。
同时，另外一个指标就是误报率，技术人员如果面对高的误报率，可能就没有精力一个个去排查，因此对于高误报率也一定要进行优化。
总结
SAST扫描在企业安全中是很重要的一环，但是要做好却并不容易，关键是要花费精力去优化规则。这方面做好了以后得收益是巨大的。要将SAST融入到现有的开发体系中，如SDL，devops等，将工具的利用发挥到最大。关于SAST的实践有什么好的想法，欢迎来交流。
参考链接
https://zhuanlan.zhihu.com/p/411319368
https://cloud.tencent.com/developer/article/1708172
原文始发于微信公众号（信安路漫漫）：SAST白盒扫描实践
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论