Page 141 - 《软件学报》2026年第7期

2826 软件学报 2026 年第 37 卷第 7 期

局限性. (1) 阈值设定对检测性能的影响. 在软件库粒度的复用检测场景中, 阈值的选取直接影响精确率与召回率
之间的权衡. 较为严格的阈值设置有助于提升检测结果的准确性, 但可能导致部分复用实例漏检, 从而降低召回
率. 鉴于本文聚焦于软件库粒度的复用分析, 未采用较低阈值以避免引入过多误报. 未来工作中, 可根据实际应用
需求, 灵活调整阈值组合, 以实现精确率与召回率的平衡. (2) 模块划分的模糊性问题. 当前版本的 CAnalyzer 采用
经验性规则对模块进行划分, 在大多数情况下能够取得合理结果, 但对于部分结构复杂或交叉复用的代码文件, 可
能出现划分边界不清的问题, 进而影响依赖关系的识别精度. 后续工作将探索更精细的模块划分方法, 例如基于函
数调用图的分析手段, 以提升成分划分的准确性, 降低由划分误差引起的干扰. (3) 依赖关系检测的局限性. CAnalyzer
当前通过扫描“#include”“extern”等语句及标识符匹配方式进行依赖关系识别, 能够有效覆盖大部分源码级依赖.
然而, 该方法无法识别运行时可能触发的动态依赖; 同时, 在具有相同标识符名称的模块之间, 基于字符串的匹配
机制可能引入误报. 为提升依赖分析的准确性, 后续研究将考虑引入控制流图或函数调用图等更具语义信息的分
析手段.
● 有效性威胁. 本研究在评估 CAnalyzer 的过程中仍面临以下潜在有效性威胁: 首先, 为了验证 CAnalyzer 的
准确性, 我们对数据集中项目的复用情况进行了人工核查. 然而, 由于部分项目缺乏正式的软件物料清单 (software
bill of materials, SBOM), 且无法获得完整的开源依赖库列表, 可能存在未纳入标准集的真实复用实例. 这类隐性复
用的遗漏可能导致 CAnalyzer 及对比工具的精确率评估出现偏差. 其次, 我们将 CAnalyzer 与 CENTRIS、TPLite
和 OSSFP 这 3 种代表性工具进行对比分析, 旨在评估在多源托管仓库构建的 C/C++ TPL 特征库场景下, 舍弃函
数诞生时间、结合特征库预处理与多重阈值策略的方法, 在软件库粒度复用检测中的有效性表现. 需要指出的是,
本研究并不否定上述工具的整体性能, 而是希望通过对比说明 CAnalyzer 在特定检测场景下具备更优的检测效果.

6 相关工作

6.1 软件成分分析
软件成分分析 (SCA) 技术用于识别开源软件及商业软件中涉及的源代码、模块和框架等组成成分, 分析其构
成与依赖关系, 并检测是否存在已知的安全漏洞和潜在的许可证合规问题, 确保软件供应链中组件的安全. 随着现
代软件开发对第三方库依赖程度的不断提升, SCA 在软件开发生命周期中发挥着日益关键的作用.
根据软件成分分析的输入形式和分析目标的不同, SCA 技术可分为源到源 (source-to-source, S2S) 分析和二进
制到源 (binary-to-source, B2S) 分析两类. B2S 分析指从已编译的二进制文件中识别其使用的外部组件, 主要应用
[5]
于逆向工程、安全审计和漏洞分析等场景. 典型工具包括 OSSPolice 、BinPro [42] 、BinaryAI [43] 等. 相比之下, S2S
分析通过直接解析源代码, 识别项目中的依赖关系、导入的库文件和头文件等, 从而识别引用的外部组件和第三
方库, 广泛应用于开源治理、许可证合规检测等领域. 本研究聚焦于 C/C++语言项目的 S2S 成分分析方法, 旨在提
升软件组件的可见性和可管理性. 因此, 本文将重点回顾与 S2S 相关的研究工作.
近年来, 针对不同应用场景, S2S 领域发展出多种 SCA 工具. 部分商业工具, 如 OWASP [44] 和 Sonatype [45] 依赖
SBOM 识别项目中使用的第三方库, 但由于开源 C/C++代码库普遍缺乏标准化的 SBOM 文件, 这类工具在源代码
检测中的适用性有限. 另一些工具侧重于识别代码中易受攻击的脆弱部分 [4,46−53] , 如漏洞函数匹配等方法, 虽能有
效定位潜在漏洞, 但仅针对特定易受攻击的 TPL, 无法提供完整的成分分析, 覆盖范围有限. 此外, 基于代码克隆检
[9]
测的工具 (如 BlackDuck ) 通过对比目标代码与 TPL 函数的相似性判断是否存在复用. 然而, 并非所有函数都具
有唯一性, 一些公共函数可能被多个 TPL 共享, 易导致复用分析中的误判, 引发假阳性. 为提升 SCA 技术的准确
性, 亟需在特征库构建阶段提取具有唯一性判别能力的 TPL 特征, 以降低公共函数干扰.
为解决公共函数干扰问题, CENTRIS [13] 基于“被复用的 TPL 通常具有较早函数诞生时间”的假设, 通过分析函
数的诞生时间推导 TPL 间的依赖关系, 以区分外部引入函数与自身函数, 并剔除冗余外部函数. TPLite [14] 在此基础
上引入基于 PageRank 算法 [35] 的中心性过滤器, 用于识别并过滤无效依赖, 从而弥补函数诞生时间方法的局限.
OSSFP [15] 将 TPL 函数划分为克隆函数、支持函数、通用函数和核心函数, 并通过设定阈值和函数诞生时间过滤