SAST静态应用安全测试工具的分析引擎小析

SAST工具最难的技术在于底层引擎的开发，根据引擎采用的技术可以分成三类：

1. 针对源代码进行检测。主要是指对于C、C++、Java、C#编译型开发语言，不需要编译，而是直接对于源代码本身进行检测。虽然不需要编译，但是往往采用先行编译的方法，这样在编译时，能够得到缺少的文件，在分析中可以进行代码补齐技术。Checkmarx最早是编译后进行检测的技术引擎，但是最近也是调整为针对源代码本身进行检测。至于为什么这么做？我想面向嵌入式领域销售的销售、售前都理解这个问题，就是大多数软件由于缺少文件而无法编译，从而导致无法检测。北大软件的Cobot也采用非编译型的引擎，直接针对源代码进行检测。
2. 编译检测一起的技术引擎。像Klocwork主要是调用工具本身的编译器进行编译，编译为.o、.bc、.obj等工具可以分析的中间文件后进行扫描分析。只有编译成功后才能进行检测，所以对被检测项目的要求必须编译通过。这对于测试中心、测试机构来说往往比较困难，原因是他们拿到的客户代码往往是不完整的。国内Wukong、Pinpoint都是该类技术引擎。
3. 编译和检测分离的技术引擎。像Fortify、Coverity则采用该种技术。编译环境和扫描检测引擎可以分别在两台服务器上。Fortify在C/C++编译上支持的类型比较少，而Coverity提供了几十种编译器，这也是为什么Coverity工具强大之处。但是对于安全漏洞检测上，Coverity不及Fortify等支持的漏洞类型更多。国内奇安信的C/C++采用该种技术引擎。

所以上通过上述分析可以看到，一种是对源代码本身进行分析的检测引擎，另一种就是对中间码进行分析的检测引擎。有的朋友可能会问，那种检测引擎效率高，精度高呢？其实要看引擎实现是否考虑全面，针对一类缺陷，其在代码中表现形式可能有数十种情况，这些情况是否在设计引擎时是否都考虑到，直接影响检测精度。根据作者使用两种引擎来看，基本上不分伯仲。读者可能会想，如果一款工具既能对源代码本身进行分析，又能对中间码进行分析，是否兼容性更好，检测精度更高呢？的确国内有工具厂商考虑到并做到了这一点，中科天齐Wukong的检测引擎能够对C/C++语言编译后的.bc文件进行检测分析，也能对源代码本身进行检测。而开源网安的工具能够对Java语言源代码本身进行检测，也能对Java语言编译后的字节码.class文件进行检测。国外工具Fortify、Checkmarx、Klocwork和Coverity等都无法做到这一点。另外，我需要补充一点，国内工具厂商能够支持对安全代码规范/标准的支持，对语义、运行时缺陷的检测分析，对安全漏洞的检测分析，而国外工具往往只支持其中的1-2个方面。

    

      作者：manok