SCA工具对安全分析真的有实际帮助吗？检测出CVE漏洞真的可能触发？

近年来，开源软件复用愈发普遍。据Gartner统计，软件平均开源代码（OSS）使用占比超过80%.大量OSS与其中的复杂依赖关系构成了大规模的生态系统。例如，以Maven为主的Java语言生态收录了超过950万个第三方库。但是，OSS中逐年增长的致命漏洞，也对整个软件生态系统造成了重大安全威胁。这些威胁会传递到使用OSS的下游项目，大约74.95%的含漏洞OSS被其下游库广泛使用。例如，最近在Apache Log4j2中发现的漏洞影响了超过35,000个下游Java库，占Maven生态系统的8%以上。

为了解决该问题，大多数SCA工具通过分析得到软件物料清单(SBOM)，然后参考现有漏洞数据库（例如NVD、CNVD和CNNVD）搜索含有漏洞的组件。一旦检测到含有已知漏洞的组件，就会向开发者发出警告，并建议采取修复措施，即将组件升级到修复后的版本。但据统计，大多数组件中的漏洞不能被自研程序触发。这也包含了两方面的含义：第一，含漏洞组件是否真正在运行时被调用，即组件可达性问题。第二，组件被调用，其中的漏洞是否可触发，即漏洞可达性问题。也就是说我们首先要判断组件可达性，在组件可达的情况下进一步判断漏洞是否可达。这样做的主要目的是可以节省开发人员修复第三方库漏洞的成本，因为据统计86%的SCA工具分析出的组件是不可达的，而14%可达组件中，漏洞可达的仅为3%.也就是说，SCA工具如果检测出100个含漏洞的第三方库，开发人员只需要修改其中3个组件，其它的组件要么可以直接删掉（因为组件未使用），要么可以不修改（因为漏洞不可触发）。

所以，我们的观点是，不做组件可达或者漏洞可达的SCA工具很难给真正的研发或者安全部门带来高效且实质性的帮助。在学术界，近两年有不少论文在论述漏洞可达性实现方式，但限于大多数SCA厂商并不具备代码分析的能力，导致了实用性不够强。本文将简述在SCA工具中可达性分析的基本实现方式。

01漏洞可达性的实例：为什么SCA会有误报

我们以开源组件commons-io中的已知漏洞CVE-2021-29425为例，来说明漏洞可达性的影响。该漏洞存在于commons-io <= 2.7的版本中。漏洞的原因是没有在函数getPrefixLength()中校验主机名的正确性，这很有可能引入路径遍历漏洞（Path Traversal），例如遍历路径‘../../../etc/..’。commons-io作为上游库，已被Maven中的23,974个下游项目使用，其中超过14,000个使用含有该漏洞的版本。

如上图所示，虽然四个项目都依赖commons-io，但并不是所有的项目都能触发该漏洞。其中pmd-core和openhub-core调用了漏洞函数getPrefixLength()，可能触发漏洞。反之，另外两个项目github-api和runtime-domain-sqlg则没有调用漏洞函数。但大多数SCA工具由于没有判断漏洞可达性，会报出所有4个项目，从而导致误报。

即使调用了发生漏洞的函数，漏洞触发的机率也不同。根据上图，两个项目调用了函数getPrefixLength。对于pmd-core项目，调用点到漏洞函数间有四个函数，而openhub-core项目仅有1个。调用路径上约束复杂性可以反映漏洞触发概率，这也是我们即将实现的基于概率的可触发漏洞检测技术，这样可以进一步降低工具发生的误报。

SCA可达性分析的意义在于，去掉那些引入但未使用的组件，降低无法触发漏洞的优先级，将注意力集中在实际影响代码的安全漏洞上，从而大幅节约修复时间，提高SCA工具的可用性。

02我们的解决方案：基于值依赖图的漏洞可达性分析

漏洞可达性分析流程如下图所示，首先构造被测项目与开源组件间的值依赖图，然后标注漏洞关键点，最后以标注点为起点对值依赖图进行切片，分析漏洞可达性。

• 构造值依赖图。首先基于被测项目到开源组件的数据流分析、调用关系分析，计算出敏感度较高的程序分析图——值依赖图。值依赖图综合了调用图、数据流分析、指向分析、多态分析、区间分析的结果，构建过程中对一些复杂度高的算法进行裁剪和优化。

• 漏洞关键点标注。基于代码级漏洞对齐结果，对包含CVE漏洞的组件代码自动化标注，包括漏洞root cause函数、变量、净化器（sanitizers）、bug语句等信息。

• 漏洞可达性分析。根据前一步SCA分析出自研代码和第三方库代码，以标注好的漏洞代码为起点，构建与自研代码的可达路径切片，并计算可达性概率。

在检测过程中，SCA工具首先要区分出自研代码和第三方库代码。其次，找到直接依赖的关系，即由自研代码直接调用第三方组件的调用点及被调用函数。然后，我们还需要分析第三方组件的间接依赖关系。对于上图，含有漏洞的组件并没有直接被自研代码调用，而是通过另一个第三方组件间接调用。最后，产生由自研代码到含有漏洞组件的函数调用链切片（①->②->③->④->⑤->⑥），以证明漏洞的可达性。

03总结

本质上说，漏洞可达性分析是对源代码静态分析技术的一次综合应用，需要利用词法分析技术、函数调用分析技术、跨语言分析技术、切片技术以及编译不通过分析技术等，再结合已知漏洞的代码级标注，产生调用关系切片。这里难点是如何保证源代码静态分析的效率，尤其是千万行代码的效率，这需要对传统的静态分析技术进行有效的平衡和裁剪，这也是大多数SCA厂商很难解决的技术难题。鸿渐科技结合自主领先的SAST技术，可以在该领域发挥自身优势，做到漏洞级可达性分析，排除漏洞不可达的组件，以降低SCA安全分析的成本。

关于我们