本文主要是介绍小议SCA漏洞可达性分析，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
开源治理中普遍采用SCA工具即软件成分分析工具进行开源组件及其漏洞分析，而随着SCA工具在供应链安全中的运用，越来越多的企业发现一个问题，就是SCA检测报告中大量的漏洞是否可以被验证、可以被利用。于是漏洞可达性便被提到了日程上，从衡量一款漏洞检测工具普遍采用假阳性（误报）率和假阴性率（漏报）来度量的话，不能简单的认为就是误报，更不是漏报，因为从包含关系上来讲，不管是直接依赖还是间接依赖的组件，这些组件被我们的系统存在关系，但是这些组件有的被调用，有的只是在构建配置文件中包括进来了，但是实际上并没有被真正调用。 或者更一步来说，某个漏洞只是存在某个开源组件的某个方法中，而这个方法是否被调用了呢？只有被调用才存在漏洞被利用的可能性。而对于组件粒度，还是方法/函数粒度，通过构建配置文件分析的检测引擎应该是很难实现可达性分析的，只有采用同源分析技术的检测引擎，或者采用两种引擎相结合的SCA工具，才具备了可达性分析的必要条件，因为要做可达性分析，必然要做某个方法是否被调用，那函数是否与含有漏洞的组件中函数一致或相似，就需要运用同源分析技术，且代码指纹要做到函数级。
采用同源分析只是一个条件，还做到可达性分析，必然要对整个项目做调用关系分析，也就是做一个逆向工程，如果绘制出整个被检测系统的函数调用图是否就意味着可以判断漏洞可以被触发呢？不尽然。因为存在调用关系但不意味着在数据流、控制流上一定可以执行到该存在某个漏洞的函数。因为如果这个函数是不可达代码呢，逻辑上是无法满足调用该函数的条件呢？所以需要静态分析中的图可达分析等相关的分析，才能真正判断出漏洞可达性。所以说，SCA工具要实现漏洞可达性分析，必然离不开SAST工具分析中产生的函数调用图，控制流图等。如果厂商SAST工具无法产生这些输出，那就算SCA工具和SAST工具结合，漏洞可达性分析实现上也是很难做到得的。
下面是库博SCA工具在实现中产生的函数调用图。
（结束）
这篇关于小议SCA漏洞可达性分析的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
