代码在计算机上运行,但用途并不限于此,同样是用来阅读和理解的。不易理解的代码不能轻易地维护或改进,代码库的复杂性与其缺陷率之间存在着相关性。理解大型的代码库是困难的,因此需要各种工具和技术来协助。
静态代码分析(简称静态分析)工具,是由程序或算法组成的,从一个程序的源代码中提取事实,而不需要执行有问题的程序,通常作为日常软件开发过程中的一个特定阶段。通过使用工具进行静态分析,有机会使用分析中产生的事实来进一步理解、评估和修改相关的代码。可以从源码中提取的数据目标可以分为很多类,例如,安全漏洞的分析会提取程序中的函数和库信息,而代码布局的分析则会关注语法结构的位置。常见的目标还包括无用代码检测,是否使用了不安全的 api,识别和监视可能被恶意数据污染的值, 竞争条件检测,确保对数组或内存位置的访问在预期的范围之内,等等。
静态分析和动态分析常常同时使用。动态分析从程序的运行时提取事实数据,检查并验证程序的正确性。静态分析的一个好处是,通常可以操作程序中所有可能的执行分支,而动态分析只能访问当前正在执行的代码路径。然而,动态分析有关于数据在运行程序内存中的布局和位置的具体信息,而静态分析则必须猜测给定的语言、编译器、操作系统和计算机体系结构将如何表示特定的数据。另外,二者有一定程度的重叠,例如动态分析和静态分析都可以检测 c 语言中未初始化变量的使用。
静态分析在软件工程中的使用非常普遍,例如 scan-build 是 LLVM 项目提供的一种分析工具,目标是 C、 Objective-C、 C + + 和 Swift; Python 的 black或 Go 的 gofmt 是代码格式化的工具; Rust-analyzer是Rust 的模块化编译器。
静态分析也是其他几个领域的核心。例如,编译器设计,大多数编译器在生成代码之前和之后运行许多单独的静态分析。实际上,可以将编译器大体上看作一个静态分析工具,这个工具生成的数据包括可执行程序以及调试信息。然而,静态分析一般指的是可以与编译器或构建系统一起使用的外部工具。
静态分析有着基本的限制,其局限性意味着静态分析常常局限于逼近程序的真实行为。尽管如此,一个近似值在实践中是非常有用的。
静态分析工具是一个程序,通常独立于程序执行机制(如解释器或编译器) ,在独立工具出现之前,静态分析是作为现有程序的一部分出现的。
类型推断算法的第一次发展出现在1958年,这些算法既可以检查程序中声明的值类型,也可以在没有明确声明的情况下推断值的类型。接下来,大量关于分析的研究聚焦于编译器的优化。今天的静态分析工具是在20世纪70年代发展起来的。最早的分析工具是Lint,写于1978年,1979年伴随着 Unix 而发布,用于检查 c 程序的错误。那时的 C编译器执行的正确性检查远远低于现在的编译器,lint 引入了一些流行的分析方式,例如关于可疑类型转换的告警、不可移植的结构、未使用或未初始化的变量等等,这些告警现在通常已经是 c 编译器本身的一部分了。Lint 的影响力巨大,它的名字已经成为许多编程语言静态分析工具的一部分。
随着时间的推移,静态分析已经成为了许多软件开发方法的基本部分。
因为语言之间在语法和语义上有很大的差异,大多数静态分析工具都是针对单一语言的。语言的特性对相关分析工具的行为和需求都有着巨大的影响,例如,面向支持字符串运行时代码求值(eval ())的语言如 JavaScript 和 Python,必须要考虑到这些特性。在没有 eval ()的语言中,就不需要考虑这一点。另外,针对高级语言的分析不需要考虑低级内存访问的风险。
如今,有许多方法可以在代码库中引入静态分析。许多版本控制软件服务,无论是免费的还是商业的,都提供了一个集成的静态分析工具平台,当新代码被推送到仓库时,就可以按需执行分析。静态分析工具还与持续集成服务协助,如果分析工具报告有意外结果,则构建过程就会失败。使用现有的分析框架扩展,我们可以编写自己的静态分析工具,例如,scan-build 提供了一个 API,使最终应用能够挂接到 LLVM 的内部进程,并利用 LLVM 的工具链来遍历和分析程序的语法树。
静态分析及其相关语言之间的影响是双向的,静态分析的发展推动了编译器和相关工具的发展,例如Swift语音的出现。Objective-C 内存管理最初是手动引用计数,与 C 编译器相关联的静态分析可以检查是否正确保留和释放内容。ARC的引入,使Objective-C 成为了具有正式内存管理策略的语言,为Swift 的诞生铺平了道路。类似地,类型推理分析促进了 ML 语言家族的发展,并将类型推理引入到缺乏类型推理的语言中,例如C ++ 。
静态分析在应用中有几种方式,最直接的分析方法是在其本地的机器上运行分析。许多流行的文本编辑器和 IDE自动集成了静态分析工具,在我们开发软件时直接向提供分析反馈。静态分析一般集成到开发和构建过程中。然而,许多静态分析是看不见的,例如一个编译器本身就是一个静态分析,数十个单独的静态分析联接在一起,生成一个可由计算机执行的程序。甚至,文本编辑器也执行自己的分析,几乎所有的编辑器都使用了语法高亮,这也是一种静态分析,可以产生关于程序中使用的标识符和关键字的语义信息。此外,在开发过程中使用的大部分软件都是静态分析的,包括操作系统乃至 CPU 的微代码。
并非所有的分析在实践中都是可行的。代码库越大,解析和遍历所需的时间就越长。因此,静态分析和被分析的代码库之间是一种军备竞赛。随着代码库变得越来越大,程序员需要更加复杂且高效的分析。
采用静态分析工具的一个障碍是要求人们改变自己的行为,以解释发现的问题和出现的告警。自从 lint 出现以来,工程师一直在努力消除与误报结果相关的告警,通常是在代码中插入”魔法注释”。然而,手工插入这些指令很乏味,工程师通常会选择不使用会产生太多误报的静态分析工具。工程师通过仔细配置给定工具来避免假阳性,而假阴性更难发现,一般通过同时使用多个静态分析工具来降低风险。
现代的静态分析工具为代码库提供了强大的洞察力。例如,Linux 内核团队开发了Coccinelle,用于搜索、分析和重写 C的源代码,由于 Linux 内核包含2700多万行代码,因此静态分析工具对于发现 bug 以及对其许多库和模块进行自动更改都至关重要。针对 C语言家族的另一个工具是 Clang scan-build,它提供了许多有用的分析,并为程序员编写自己的分析提供了一个 API。
基于云的工具集成了现有的构建和发布过程,并且可以跨多种编程语言工作。与静态分析有关的高级协议也出现了,语言服务器协议(Language Server Protocol)是一套通用的定义,标准化了分析工具与文本编辑器(如 Emacs 和 VS Code)的接口,确保了分析工具可以与工作流集成。同样,SARIF (Static Analysis Results Interchange Format)为静态分析工具生成的输出提供了一个标准,而以检测安全漏洞为目标的静态分析持续吸引着大家的关注。
随着新的平台、操作系统和编程语言的出现,软件生产的机制变得更加复杂。事实上,软件的复杂性增长速度通常快于工程师管理这种复杂性的能力,这是软件工程和计算机科学面临的主要挑战,而静态分析是最有效的武器之一,产生我们这些从业者应得的知识和洞察力。
联系客服