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

你可能感兴趣的:(软件安全,代码安全,代码安全)