Oxymoron：动态语言的静态分析

我们需要适当表示程序，以便进行静态分析。当我们希望进行流量敏感分析时，我们的表示形式也必须反映说明的顺序。程序的源代码然后表示为一组图形，代码中的每个功能一个。由于存在更高阶的函数，因此我们无法静态地知道在给定的调用位置调用了哪些函数，因此过程间边缘的插入留给了分析。图中的节点是基本块。

当分析由多个功能组成的程序时，可以进行过程间或过程内分析。在进行过程内分析时，流程不会跨功能边界传播，并且可以提取的所有信息都将位于当前功能的本地。

跨函数调用传播信息是过程间分析。如上所述，在JavaScript中，控制和数据流是相互依赖的，因此在一般情况下，我们不知道在分析之前给定调用将调用哪个函数。发现数据流事实时，在分析过程中会添加特殊的过程间边缘。对于每个发现的函数，将添加一个调用边和一个返回边。天真地增加过程间边缘会导致无法接受的精度损失。

为了应对不可行的流程和不精确性，需要添加上下文敏感性。启用上下文敏感性后，分析中将存在有限数量的上下文。现在在上下文中分析每个功能，并且将不同上下文中的不同流程分开。JavaScript提供了许多可能的上下文选择。作为一种面向对象的语言，许多功能通常与对象，字符串等相关联。如上所述，JavaScript缺乏形式语义。这意味着设计合理的分析将永远是尽力而为的工作，无法给出正确性的证明。

传统的密集分析沿控制流图的边缘传播数据流事实。前向分析将数据流事实从控制流图节点传播到其后继者，而后向分析将数据流事实传播到其前任者。由控制流图节点表示的每个程序点都维护整个抽象状态。不变的数据结构和聪明的算法可以减少密集数据流分析的一些内存开销，但是这些技术并不总是适用也不足够，特别是在处理动态语言时。

该代码特性曲线是基于一个简单的观察一个概念：有很多代码不同的图形表示，在代码模式通常可以表示为这些图的图案。尽管这些图形表示均表示相同的代码，但某些属性可能更易于用一种表示形式表示。因此，为什么不合并表示以获取它们的联合能力，并在我们使用它的同时将结果表示表示为属性图，即图数据库的本机存储格式，从而使我们能够通过图数据库查询来表达模式。

最初的想法由Nico Golde，Daniel Arp，Konrad Rieck和Fabian Yamaguchi在2014年的《安全和隐私》上发表，并于一年后扩展到跨过程分析。代码属性图的定义非常宽松，只要求合并某些结构，而图模式保持打开状态。它表示概念，数据结构以及用于查询以发现程序缺陷的基本算法。假定有人以某种方式为目标编程语言创建了该图。因此，代码属性图的具体实现方式大不相同。

该代码图表属性使我们能够内和程序间数据之间有效地切换流分析，该分析给出精确上下文敏感的结果。这些结果改善了调用图，进而改善了数据流跟踪。此外，代码属性图使我们能够创建一个即席近似类型的系统，该系统大大减少了各个呼叫站点的分辨率，因此对于在合理的时间内分析ECMASCRIPT投诉代码至关重要。