前言
在企业内安全有一项很重要的工作,那就是应用安全测试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. 无法保证完美处理所有的AS |