我是SAST工具的新手。运行这些工具并找出有时显而易见的错误，但我们只是没有注意到，真是太神奇了。
虽然我知道如何运行这些工具，但是我仍然要记住许多问题，这些不可思议的工具如何在后台运行。
例如，在使用SonarQube或Coverity扫描C / C ++源代码时，我们必须使用build-wrapper，以便该工具可以监视构建过程。但是，对于其他解释语言，这些工具仅需看一下代码，仍然可以很好地发挥作用。
我可以想象这些工具正在建立源代码（函数调用/变量/内存分配或释放）之间的关系，对于编译语言而言，该工具必须介入构建过程的原因是什么？
静态分析工具需要知道代码的含义。对于已编译的语言，代码的含义通常取决于编译器的调用方式。对于C / C ++，其中包括-D（宏定义）和-I（包含路径）选项之类的内容，因为前者通常控制#ifdef的行为，而后者则用于查找第三方库的标头（以及其他）。对于Java，编译命令包括-classpath选项，这也是查找第三方依赖项的方式。其他编译语言类似。
定位正确的依赖关系很重要，因为这可能会影响代码的解析方式和行为。作为前者的一个示例，请考虑一下，在Java中，表达式a.b.c.d.e.f可能有很多含义，因为.运算符既用于在包层次结构中导航，又用于取消引用对象以访问字段。如果a来自类路径，则该工具如果不检查该类路径中的类就无法知道这意味着什么。作为后者的示例，请考虑第三方库中接受对象引用的函数。该函数是否允许传递null引用？除非它是该工具已经知道的众所周知的功能，否则唯一的告诉方法是让分析器检查该功能的字节码。
现在，调用分析仪时，工具可以要求用户直接提供编译信息。例如，这就是clang-tidy所采用的方法。从概念上讲这很简单，但是要维护它可能是一个挑战。在一个大型项目中，可能会有许多使用不同选项编译的文件集，这使得设置起来很麻烦。而且可能更糟的是，没有简单，通用的方法来确保传递给分析器的选项和要分析的文件集与真实版本保持同步。
因此，某些工具提供了一个“构建监视器”，可以包装常规构建，检查其执行的所有编译以及收集要分析的源文件集和编译它们所需的选项。完成后，可以开始主要分析。使用这种方法，正常构建中的任何内容都无需随着时间的推移进行修改或维护。但是，这并非完全没有潜在问题。例如，可能需要告知该工具您的编译器可执行文件的名称（在交叉编译方案中可能会有很大不同），并且您必须确保正常构建从“干净”状态执行完整构建，否则可能会丢失某些文件。
解释的语言通常不同，因为它们通常具有分析器可以看到的环境变量所指定的依赖性。如果不是这种情况，分析仪通常会接受其他配置选项。例如，如果clang-tidy上的python可执行文件不是用于运行正在分析的Python脚本的文件，则通常可以告知分析器模拟其他脚本。
Tangent：在问题的最后，您开玩笑地将此过程称为“干预”。实际上，这些工具都非常努力地尝试对常规构建产生任何可观察到的影响。论文PATH（我是其中的作者之一）中有一些有趣的轶事，使失败变得透明。