“遥遥领先”！安势打响国内漏洞可达第一枪，对误报说NO！

根据相关数据显示，对于众多SCA工具安全相关使用者而言，修复漏洞往往不是最耗费时间与精力的，但是确认漏洞、定位漏洞，并且将漏洞的传播链路清晰明确的标注出来却会花费掉他们90%的精力。所以SCA工具的误报率和漏报率太高，将是让使用者非常崩溃的一件事，长此以往，会大大打击他们对于SCA工具的使用热情，降低对SCA工具的信任度。 

另一方面来看，漏洞数据库给到研发人员的漏洞数据是比较粗糙的，即只知道A组件里有某个A漏洞，但是在A组件的什么位置不知道，并且如果是由于各种依赖关系而“引入”的漏洞，漏洞库并不会显示。再从Java的常用工具maven而言，它虽然会报出由于依赖关系而带来的漏洞，但是并不够准确，即只要是因为依赖而存在的漏洞，它都会显示，但实际上，尽管依赖关系存在，但是漏洞函数的调用却并不是100%的，这就会让一些“清白”的函数也蒙上了“漏洞函数”的污名。

总之，对于SCA工具而言，减少误报率是必要的，因为这直接关系到企业源代码的安全问题。从使用者角度看，低误报是SCA工具使用者的刚需，而漏洞可达能力，就是解决这一刚需的必要手段；从开发难度上来看，要实现漏洞可达并不简单，基础数据量庞大会直接导致定位漏洞函数到代码行级的难度陡然提高；与此同时对于上千万的组件量，上亿级的依赖关系而导致的传播路径复杂也是技术算法的一大门槛，以及勾勒函数调用路径时需要开发团队能够有SAST（静态代码分析）的能力，例如抽象语法树、数据流、控制流等一系列对源代码进行分析的手段。

在SAST方面我们也有业内的技术大牛”保驾护航“，安势的首席程序分析科学家卢博发表的技术论文更是在业内顶会得到认可。（PS：具体内容见下方链接）

【重磅】卢静波博士的论文在国际顶级ASE会议发表，为软件工程界带来新思考！ (qq.com)

所以在SCA工具业内而言，其刚需的性质以及其技术难点的存在，我们有理由相信“漏洞可达”这一能力，说是SCA工具中的“C位”能力也不为过。

漏洞可达严格来说是一个复合能力，其中包含了几项能力和阶段，接下来，我们将用深入浅出的文字+图片形式带大家进一步理解漏洞可达。

要实现漏洞可达，需要先确定漏洞是否存在，我们可以称呼其为【漏洞存在性】。漏洞存在性就是为了避免两种情况：“该报的没报”和“报了但是报的是错误的”。它是漏洞可达的前提，如果漏洞存在，那么漏洞与组件之间的对应性是否能够与NVD匹配，亦或者NVD中的组件与漏洞尽管没有对应关系，但是却因为函数的调用而导致漏洞实现了传递而无法匹配，这是业内众多SCA工具都面临的严峻考验。所以我们要能确定某个漏洞存在并且知道它所在位置。即：

输入：组件名称-版本

输出：漏洞编号（直接漏洞or依赖漏洞）

假设有甲乙丙三个组件，ABC三种漏洞，那我们就可以：

输入：甲

输出：CVE-2023-1195（直接漏洞或依赖漏洞）

或

输入：乙

输出：空值 （即无漏洞）

需要注意的是，目前还有一种情况，一些开发者会直接实行“拿来主义”，即不通过dependency来引入函数或组件，而是直接放入到另一个组件，这种情况不论是NVD还是maven，都不会报出漏洞。这也是有时候漏洞容易被遗漏而没报出来的原因。

当我们确定了直接漏洞或依赖漏洞存在的位置以后，才算是为漏洞可达奠定了基础，因为这是为后续勾勒出漏洞引入链路图谱的重要指导。

在我们了解了漏洞存在性以后，漏洞可达才能真正落地。

但是要实现漏洞可达，仍需了解一个概念，漏洞与漏洞之间的传递性。而这个传递性，不仅仅是能够在组件内传递，也可以在组件间进行传递。

所以实现漏洞可达，需要分为以下四个阶段：

1.漏洞定位

2.组件内漏洞传递

3.组件间漏洞传递

4.漏洞可达

当我们实现了漏洞定位以后，那么现在需要分析和识别出组件内漏洞传递的路径。

正常情况下，一个组件由若干个函数构成，而函数作为代码的主要体现方式，就是漏洞藏匿的好地方。所以，对漏洞函数的挖掘就显得尤为重要。

我们对5000个左右的java漏洞进行了一定处理，最终计算出每个java漏洞通过可传递影响的组件和函数。挖掘漏洞函数的精度越高越好，因为漏洞函数的挖掘直接决定了漏洞在组件内传递的路径是否清晰可见以及漏洞可达信息是否可用，所以我们有时候甚至花费大量人力达到满意的漏洞函数细粒度。

在这一阶段主要的难点在于需要有很高的漏洞传递的分析能力，即在组件内部的不同函数间的关系的分析，是否引用，对于相关的函数调用分析除了需要工程化的开发和部署，也需要基于海量的开发经验。

以CVE-2022-25845这个漏洞为例，我们在目前在组件“fastjson”中发现了它，该组件中共有46142个函数，其中漏洞函数（疑似）有两个，通过我们的计算及函数调用分析，我们发现基于这两个漏洞函数的可达有风险函数为463个！

在进行函数调用分析时，计算性能、数据更新的形式和频率都是不小的挑战。

组件间的漏洞传递，对于SCA工具来说主要是需要厘清大量组件之间的“血缘关系”，这种“血缘关系”大多是组件间的依赖关系，我们也称其为组件血缘关系挖掘，它主要从两方面展开：

组件间的依赖关系是组件间漏洞传递的重要途径。

以下图为例，一个文件中的组件依赖关系是复杂的，这导致漏洞传递的路径也是复杂的，B组件是有原始漏洞的函数，C组件依赖于B，且漏洞函数被调用，所以C组件也成了有漏洞的组件，同样的B-C-D-E-Q这样的依赖路径导致了CDEQ四个组件都成为了漏洞组件，但前提是因为依赖关系存在并且组件中调用了漏洞函数才使漏洞完成了传递，但不同的是，由于漏洞函数的调用与依赖关系并不是必然相关，所以同样有依赖关系的A、Z、F却并没有成为漏洞函数，即A、Z、F是有依赖关系但【清白】的组件。

图1：漏洞传递缩影图

值得注意的是，上图只是文件内组件依赖关系的一个小小的缩影，在实际情况下，一个文件或者项目里包含的组件量是巨大的(见图2)，其依赖关系更是”盘根错节“，很难理清。如下图所示，其中的小红点都是某个文件里的组件，放大了仔细看会发现里面一簇一簇的小红点有着复杂的依赖关系（见图3）。所以准确的解析组件间依赖关系是我们安势进行漏洞可达技术攻坚中的重难点之一。但庆幸的是，我们做到了！

图2：某项目包含组件图

图3：组件依赖关系图

代码引用分析是漏洞在组件间传递的小颗粒度方式，其本质原理其实和组件间的依赖关系相同。我们对于代码引用分析的主要追溯方式采用了组件ID的方式进行。

通过上述的两部分我们可以基本实现组件间血缘关系的挖掘从而达到组件间的漏洞可达。

同样以漏洞CVE-2022-25845为例，上文我们已经了解到它在组件“fastjson”中，而通过对组件间依赖关系的分析，我们发现该组件被组件“alipay-sdk-java”引用（依赖）了，所以漏洞实现了传递，最终我们人工核验后发现，“alipay-sdk-java”组件中有374846个函数，而通过组件的依赖关系，导致了“alipay-sdk-java”组件内的可达有风险函数达到了253个。

纵观业界而言，漏洞可达虽然不算是全新的一项技术，但也只是处于初步发展和技术积累的阶段。目前来看，漏洞可达性分析仅java实现在了工业级的落地，而Python的可达性分析，目前仍是一个探索方向。国内厂商目前多数是对某些典型漏洞做到可达性分析，但全面性还不够。国外的相关技术虽然也有取得了不错进展的，但也仅限于java。

在组件血缘关系挖掘方面，安势目前已解析全部一千两百万个maven带版本组件，过亿的依赖关系。而在漏洞函数挖掘方面，我们已实现了近5000个漏洞在组件中代码行的定位（或函数级定位），而且实现了重要漏洞优先覆盖。

截止到目前，我们对于组件的漏洞存在性问题已经达到准确率90%，同时已经覆盖了所有Linux的文件级漏洞，并且近期也将实现45000的文件级漏洞覆盖量，对Java类组件的漏洞文件实现全覆盖。

而在明年年初，安势也将在漏洞可达方面持续发力，坚持以客户需求为核心，努力让清源SCA成为用户的SCA第一选择！