Patch2QL：开源供应链漏洞挖掘和检测的新方向

背景

开源生态的上下游中，漏洞可能存在多种成因有渊源的其它缺陷，统称为“同源漏洞”，典型如：

• 上游代码复用缺陷。开源贡献者在实现功能相似的模块时，常复用已有模块代码或逻辑；当其中某个模块发现漏洞后，该漏洞可能随复用也出现在相似模块中。
• 接口或代码误用。某些接口，特别是欠缺充分文档的项目内部接口，可能误导开发者以相同错误方式调用；而某些不完备的代码，例如示例代码或开源代码片段，也常被开发者直接使用。
• 版本分支与碎片化中的残留漏洞。上游的多分支，与下游二次开发者的定制化，使碎片版本与主线差异扩大，以致难以分析上游代码漏洞是否（可能以不同形态）存在于下游。
• 其它开发实践风险。例如，松散的开发协作中，可能存在开发者在开发分支回滚时将他人的缺陷修复一并覆盖；同时也存在恶意开发者仿照历史漏洞植入可利用缺陷的投毒可能。

同源漏洞的威胁，在真实世界中缺少足够的研究，却影响深重。例如，上游开源项目的漏洞与补丁完全公开，使得黑客人工分析与历史高危漏洞相似的缺陷并利用，成本更低。而下游项目开发者常常不会主动跟踪其使用的开源代码的安全漏洞，导致很多关键系统可能带着多年漏洞运转，更是为黑灰产无感知地渗透进去提供了方便。

作为软件供应链研究重点，腾讯安全云鼎实验室通过对开源上下游的典型实践的长期分析和漏洞挖掘，论证了供应链的典型威胁，特别是“同源漏洞”的风险模型。基于此，我们提出一种区别于传统静态分析和成分分析的方法，统一解决两个问题：开源软件有哪些与历史漏洞相似的缺陷？自研代码中引入了哪些开源代码的漏洞？

现有技术缺陷

开源漏洞挖掘检测，现有技术手段包括SAST与SCA/SBOM，但二者均难以有效解决同源漏洞问题。

狭义的SAST即源代码分析，可依据典型缺陷模式构建规则库，分析项目中语法、数据流匹配的片段。但此类规则，一方面依照通用缺陷类型编写，却无法检测包含复杂或项目特定逻辑的漏洞；另一方面受制于过程间分析等限定，难以在没有人工定制前提下适配每个项目的接口规约。这导致真实世界漏洞可被这些SAST工具检出比例很低。

SCA/SBOM的核心是源代码成分判定，依照显式的依赖配置、版本号、特征文本或模糊的代码指纹，以从不同粒度确定代码组成的最相似开源来源，进而判断是否存在陈旧成分带有漏洞。但对于C/C++这种没有统一包管理机制的生态，SCA只能通过指纹相似性匹配来实现，又面临三个问题：基于文本相似性的指纹匹配方法，无法保证对基于开源二次开发项目的抵抗，导致无法对应到来源；基于代码骨架、数据流等构建特征向量的匹配方法，应用范围和实际效果难以保证；而代码片段级或复杂的指纹库对真实项目扫描，运算开销又很难降低到可行范围。

一个简单的实验可以说明如上问题。选取8款漏洞较多的开源基础软件，将其代码置为2020年1月的版本，统计其截止到2023年10月的已知CVE数量；之后使用三款工具对这8个代码库进行扫描，统计其总报告漏洞数量（Positives）以及命中的CVE数量（TP