赖建新：关于静态代码分析的问与答

作者：赖建新，鉴释静态代码分析工具爱科识（Xcalscan）的研发主管。

你现在的工作内容是什么？

我现在的工作是带领鉴释核心开发团队开发下一代的程序静态分析工具（SAST），这个分析引擎是鉴释静态分析工具工具产品的核心组件。分析引擎将用户输入的源代码转换为编译器中间表示；基于中间表示进行流敏感分析，过程间分析，上下文敏感分析和对象敏感分析；在各种分析的基础上结合符号执行和形式化验证等手段，检测用户输入程序是否存在各类缺陷或者安全漏洞，是否存在违反各类源代码安全编码规范或用户自定义规则的代码。

什么是静态代码分析？

静态代码分析是指在不实际执行程序的情况下，对代码语义和行为进行分析，由此找出程序中由于错误的编码导致异常的程序语义或未定义的行为。通俗的说，静态代码分析就是在代码编写的同时就能找出代码的编码错误。你不需要等待所有代码编写完毕，也不需要构建运行环境，编写测试用例。它能在软件开发流程早期就发现代码中的各种问题，从而提高开发效率和软件质量。

静态代码分析现在面临最大的难题是什么？

现代软件系统规模越来越大，代码行数从数万或数十万行规模增长到数千万行；系统复杂度也越来越高，从传统的单机系统变为分布式系统，同构系统变为异构系统；而且软件开发的编程语言也从使用单一的语言发展为多种语言协同开发。这些变化都对 SAST 工具带来了巨大挑战。SAST 工具首先必须要有能同时检测多种语言代码及其互操作的能力，例如要检测 Android 应用程序的漏洞，SAST 除了要能支持检测 C/C++和 Java 语言外，还必须支持 JNI，才能有效的检测 Byte Code 和 Native Code 互操作导致的各类问题。此外对静态程序分析工具还有这些维度的评价指标：一是漏报率和误报率；漏报率或误报率过高会导致 SAST 工具的实用性和有效性显著降低，无法有效提高软件开发效率和软件质量。二是检测规则是否容易扩展及按用户特定需求定制；除了支持常见的工业安全编码标准外，SAST 工具应该还能支持用户自定义的编码规范和业务逻辑规则。三是分析所需的时间和资源占用；如果 SAST 工具一次扫描所需的时间太长或者占用内存资源太大，将难以和程序员日常的开发工作和流程整合，进而无法起到提高开发效率和软件质量的目的。

在编译器技术领域，什么是抽象语法树 （AST）？

抽象语法树是程序源代码结构的树状表示。程序源代码经过词法分析器（Lexer）得到各种不同种类的单词（Token），再由语法分析器（Parser）分析和语法检查后得到抽象语法树(AST)。抽象语法树的根节点表示整个程序，内部节点是抽象语法结构或者单词。AST 的核心在于它能与输入源代码中的各个语法元素一一对应。对于 附图 1 的 C 语言源代码，它对应的 AST 如 附图 2 所示。

附图 1：while 循环的 C 代码

附图 2：while 循环的 AST

什么是中间表示（IR）？

IR 是编译系统或程序静态分析系统的核心，它是源程序在编译器或者静态分析器的内部表示，所有的代码分析，优化和转换工作都是基于中间表示进行的。IR 一般由 AST 经过类型检查和规范化后转换而来。对编译器来说，它在中间表示上做完分析和优化工作后，将中间表示转换为其他语言源代码或者汇编/目标语言。而静态分析工具则会在中间表示上进行语义或未定义的行为分析，然后结合各种预定义规则或者用户自定义规则检测源代码的各种漏洞或缺陷。在现代编译器和静态分析工具中，通常会使用控制流图（Control Flow Graph，CFG）来表示程序的控制流，使用静态单赋值（Static Single Assignment，SSA）来表示程序中数据的使用-定义链（Use-Def Chain），这两个关键数据结构都是 AST 中没有的。对于附图 1 的 C 语言源代码，它对应的 IR 如 附图 3 所示。

附图 3：while 循环的 IR

查找源代码缺陷时，为什么在 IR 级别上进行静态代码分析比在 AST 级别上准确性更高？

根据前面的描述，对 AST 进行类型检查和规范化，即可转换为 IR。AST 上适合做一些代码规范的检查，例如标识符命名规范检查或常见的编码惯用法检查，AST 上的检查一般使用图模式匹配的方法。而 IR 上能进行更深层次的流敏感分析，过程间分析，上下文敏感分析和对象敏感分析等等，从而实现各种更高难度的程序漏洞检查。相比 IR，AST 有这些明显的劣势：AST 不能很好的表示控制流和数据流，AST 做为输入源代码的树状表示，它本身就缺乏表示控制流和控制流的方式。AST 是非规范化的，相同语义的结构如果写法不同，它们在 AST 上的表示也会不同。例如 C 语言中使用 for、while 和 if/goto 表达的循环结构，它们的 AST 是不一样的；而转换为 IR 后产生的控制流图是一样的。规范化使得对程序语义的分析更容易，使得检测精确度更高。

IR 级别上的代码分析还能提供哪些其它好处？

一个最明显的好处是通常 AST 都是输入语言相关的，比如 C 程序有对应的 C AST，Java 程序有对应的 Java AST；而 IR 一般来说是输入语言无关的，不管是 C 源代码、Java 源代码或者其他语言的源代码，它们都能被转换到一个语言无关的 IR 上。我们将各种分析和检测引擎放置在 IR 上，那么相同的分析引擎和检测引擎，搭配不同语言的检测规则，就可以实现对不同语言编码缺陷的检测。使用 IR 的另一个好处是相对 AST，IR 会更稳定。例如现在 C++规范每 3 年就会出一个新标准，引入新的语法结构，意味着 AST 每 3 年就会出现新的节点需要处理。如果将分析引擎建立在 AST 基础上，那么分析引擎也需要每 3 年更新一次处理这些新节点；而如果将分析引擎建立在 IR 基础上，则仅需将新的 AST 节点转换为已有的 IR 结构或操作，从而保持分析引擎基本不受影响。

在这方面，爱科识（Xcalscan）如何与其他静态分析工具（SAST）区分开来？

综合来看，Xcalscan 的优势主要来自以下三方面：

一是，创新的可扩展的流敏感（Flow Sensitive）、对象敏感（Object Sensitive）、上下文敏感（Context Sensitive）的分析引擎。流敏感是指分析引擎会区分程序变量在不同执行路径下的定义和使用情况，并仅对会导致错误的执行路径报告警告；对象敏感是指分析引擎能区分不同的对象实例或同一个对象不同的成员，仅对会导致错误的对象或对象成员报告警告；上下文敏感是指分析引擎能区分相同函数在不同调用点的上下文，仅对会导致错误的调用点报告错误。Xcalscan 通过综合使用静态单赋值（SSA），虚拟变量（Virtual Symbol），基于 SSA 的别名分析（Alias Analysis）和过程间分析（Inter-Procedure Analysis）来实现了分析引擎的流敏感、对象敏感和上下文敏感。基于这个分析引擎，Xcalscan 能有效的报告出每个问题产生的源头在哪里，数据经过了什么样的路径和函数调用点到达了最终问题会显现的地方。Xcalscan 图形化的用户界面会以流图（Flow Graph）的方式，展示问题是如何从源头引入，一步步推进，并最终会在什么位置触发。

二是，综合了资源建模、数据流分析、符号执行和形式化验证等多种方式的漏洞检测引擎。在应用规则检测程序漏洞时，Xcalscan 会综合使用数据流分析，符号执行和形式化验证的方式检测程序中是否存在违反该规则的代码。

三是，可扩展的用户自定义规则引擎。Xcalscan 定义并开放了分析和规则检查 API 用于开发用户自定义规则。用户可以通过调用相关 API 指定用户代码或第三方库函数的属性及副作用，前置或后置条件，检查规则等。Xcalscan 规则引擎会自动读取用户规则并附加于代码的中间表示上，在完成程序静态分析后，规则引擎会判断用户规则中的前置或后置条件、检查规则等是否满足并给出警告。

综上所述，Xcalscan 作为新一代的 SAST 工具，它从设计之初就能支持多种语言及不同语言间的互操作，目前已经支持 C/C++，Java 和 JNI。后续版本将支持 Javascript 和 Python 等更多的程序设计语言。Xcalscan 扫描结果的漏报率和误报率都较低，扫描所需的处理器和内存资源少，且支持用户自定义规则。

作者：赖建新有着丰富的编译器优化和高级程序静态分析的经验。在 2006 年获得清华大学计算机科学硕士学位之后，他加入了惠普的编译器团队，先后担任编译器开发工程师，编译器后端架构师和项目经理等职位，参与了开源编译器 Open64，HP-UX 产品编译器 aCC 和 HP Non-Stop 编译器项目，并于 2018 年加入鉴释。

点击了解更多鉴释产品及资讯！