作者
赖建新
来源
鉴释
封图
东方IC
什么是静态代码分析？
静态代码分析是指在不实际执行程序的情况下，对代码语义和行为进行分析，由此找出程序中由于错误的编码导致异常的程序语义或未定义的行为。通俗的说，静态代码分析就是在代码编写的同时就能找出代码的编码错误。你不需要等待所有代码编写完毕，也不需要构建运行环境，编写测试用例。它能在软件开发流程早期就发现代码中的各种问题，从而提高开发效率和软件质量。
静态代码分析现在面临最大的难题是什么？
现代软件系统规模越来越大，代码行数从数万或数十万行规模增长到数千万行；系统复杂度也越来越高，从传统的单机系统变为分布式系统，同构系统变为异构系统；而且软件开发的编程语言也从使用单一的语言发展为多种语言协同开发。这些变化都对SAST工具带来了巨大挑战。
SAST工具首先必须要有能同时检测多种语言代码及其互操作的能力，例如要检测Android应用程序的漏洞，SAST除了要能支持检测C/C++和Java语言外，还必须支持JNI，才能有效的检测ByteCode和NativeCode互操作导致的各类问题。
此外对静态程序分析工具还有这些维度的评价指标：
一是漏报率和误报率；漏报率或误报率过高会导致SAST工具的实用性和有效性显著降低，无法有效提高软件开发效率和软件质量。
二是检测规则是否容易扩展及按用户特定需求定制；除了支持常见的工业安全编码标准外，SAST工具应该还能支持用户自定义的编码规范和业务逻辑规则。
三是分析所需的时间和资源占用；如果SAST工具一次扫描所需的时间太长或者占用内存资源太大，将难以和程序员日常的开发工作和流程整合，进而无法起到提高开发效率和软件质量的目的。
在编译器技术领域，什么是抽象语法树（AST）？
抽象语法树是程序源代码结构的树状表示。程序源代码经过词法分析器（Lexer）得到各种不同种类的单词（Token），再由语法分析器（Parser）分析和语法检查后得到抽象语法树(AST)。抽象语法树的根节点表示整个程序，内部节点是抽象语法结构或者单词。AST的核心在于它能与输入源代码中的各个语法元素一一对应。对于附图1的C语言源代码，它对应的AST如附图2所示。
附图1：while循环的C代码
附图2：while循环的AST
什么是中间表示（IR）？
IR是编译系统或程序静态分析系统的核心，它是源程序在编译器或者静态分析器的内部表示，所有的代码分析，优化和转换工作都是基于中间表示进行的。IR一般由AST经过类型检查和规范化后转换而来。对编译器来说，它在中间表示上做完分析和优化工作后，将中间表示转换为其他语言源代码或者汇编/目标语言。
而静态分析工具则会在中间表示上进行语义或未定义的行为分析，然后结合各种预定义规则或者用户自定义规则检测源代码的各种漏洞或缺陷。
在现代编译器和静态分析工具中，通常会使用控制流图（ControlFlowGraph，CFG）来表示程序的控制流，使用静态单赋值（StaticSingleAssignment，SSA）来表示程序中数据的使用-定义链（Use-DefChain），这两个关键数据结构都是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程序有对应的CAST，Java程序有对应的JavaAST；而IR一般来说是输入语言无关的，不管是C源代码、Java源代码或者其他语言的源代码，它们都能被转换到一个语言无关的IR上。
我们将各种分析和检测引擎放置在IR上，那么相同的分析引擎和检测引擎，搭配不同语言的检测规则，就可以实现对不同语言编码缺陷的检测。使用IR的另一个好处是相对AST，IR会更稳定。
例如现在C++规范每3年就会出一个新标准，引入新的语法结构，意味着AST每3年就会出现新的节点需要处理。如果将分析引擎建立在AST基础上，那么分析引擎也需要每3年更新一次处理这些新节点；而如果将分析引擎建立在IR基础上，则仅需将新的AST节点转换为已有的IR结构或操作，从而保持分析引擎基本不受影响。
爱科识（Xcalscan）
综合来看，Xcalscan的优势主要来自以下三方面：
一是，创新的可扩展的流敏感（FlowSensitive）、对象敏感（ObjectSensitive）、上下文敏感（ContextSensitive）的分析引擎。流敏感是指分析引擎会区分程序变量在不同执行路径下的定义和使用情况，并仅对会导致错误的执行路径报告警告；对象敏感是指分析引擎能区分不同的对象实例或同一个对象不同的成员，仅对会导致错误的对象或对象成员报告警告；上下文敏感是指分析引擎能区分相同函数在不同调用点的上下文，仅对会导致错误的调用点报告错误。Xcalscan通过综合使用静态单赋值（SSA），虚拟变量（VirtualSymbol），基于SSA的别名分析（AliasAnalysis）和过程间分析（Inter-ProcedureAnalysis）来实现了分析引擎的流敏感、对象敏感和上下文敏感。
基于这个分析引擎，Xcalscan能有效的报告出每个问题产生的源头在哪里，数据经过了什么样的路径和函数调用点到达了最终问题会显现的地方。Xcalscan图形化的用户界面会以流图（FlowGraph）的方式，展示问题是如何从源头引入，一步步推进，并最终会在什么位置触发。
二是，综合了资源建模、数据流分析、符号执行和形式化验证等多种方式的漏洞检测引擎。在应用规则检测程序漏洞时，Xcalscan会综合使用数据流分析，符号执行和形式化验证的方式检测程序中是否存在违反该规则的代码。
三是，可扩展的用户自定义规则引擎。Xcalscan定义并开放了分析和规则检查API用于开发用户自定义规则。用户可以通过调用相关API指定用户代码或第三方库函数的属性及副作用，前置或后置条件，检查规则等。Xcalscan规则引擎会自动读取用户规则并附加于代码的中间表示上，在完成程序静态分析后，规则引擎会判断用户规则中的前置或后置条件、检查规则等是否满足并给出警告。
综上所述，Xcalscan作为新一代的SAST工具，它从设计之初就能支持多种语言及不同语言间的互操作，目前已经支持C/C++，Java和JNI。后续版本将支持Javascript和Python等更多的程序设计语言。Xcalscan扫描结果的漏报率和误报率都较低，扫描所需的处理器和内存资源少，且支持用户自定义规则。
本文作者是鉴释静态代码分析工具爱科识（Xcalscan）的研发主管，当前的工作是带领鉴释核心开发团队开发下一代的程序静态分析工具（SAST），这个分析引擎是鉴释静态分析工具工具产品的核心组件。分析引擎将用户输入的源代码转换为编译器中间表示；基于中间表示进行流敏感分析，过程间分析，上下文敏感分析和对象敏感分析；在各种分析的基础上结合符号执行和形式化验证等手段，检测用户输入程序是否存在各类缺陷或者安全漏洞，是否存在违反各类源代码安全编码规范或用户自定义规则的代码。
作者简介：赖建新有着丰富的编译器优化和高级程序静态分析的经验。在年获得清华大学计算机科学硕士学位之后，他加入了惠普的编译器团队，先后担任编译器开发工程师，编译器后端架构师和项目经理等职位，参与了开源编译器Open64，HP-UX产品编译器aCC和HPNon-Stop编译器项目，并于年加入鉴释。