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

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

● TPL 识别方法的影响分析. 如图 11 所示, 在 3 种特征库设置下, 单阈值检测的精确率均较低. 这是因为基于
函数数量的单阈值只能判断目标代码与外部组件部分函数的重合, 难以准确评估整个库的复用情况. 相比之下, 多
重阈值不仅关注函数级别的相似度, 还结合文件级别的相似度, 综合考虑目标代码与组件的重合比例, 更全面地反
映组件的复用情况. 因此, 多重阈值在所有特征库设置下的精确率普遍较高 (50.00%–90.63%). 然而, 静态阈值的限
制可能导致一些真实复用案例被排除, 从而损失部分召回率.

1.0
0.8
Values 0.6

0.4

表 6 不同特征库的函数规模
0.2

函数规模 DataBase DataBase-I DataBase-II Detection Detection-I
标志函数数量 18 593 657 20 690 362 23 854 290 Conditions
公共函数数量 11 453 633 5 373 301 2 209 373 Precision DataBase Precision DataBase-I Precision DataBase-II
公共函数占比 (%) 38 21 8 Recall DataBase Recall DataBase-I Recall DataBase-II
函数总数 30 047 290 26 063 663 26 063 663 图 11 不同成分识别算法下精确率和召回率趋势

● 实验结论 (RQ3). 由于噪声干扰, 无预处理的特征库精确率较低 (16.66%–50.00%). 而预处理可以有效清理
公共函数, 提高检测精确率. 使用多重阈值来匹配 TPL 能提升精确率, 但会损失部分召回率. 结合高质量特征库和
多重阈值检测, 可最大程度减少假阳性和假阴性, 显著提升 SCA 准确性.
4.6 依赖检测评估实验
为了探究 RQ4, 我们设计了针对文件集 (由同一 TPL 所属文件构成) 之间依赖检测的实验, 以验证 CAnalyzer
在聚合到 TPL 粒度后能否准确构建 TPL 之间的依赖关系. 实验数据来源于 OpenHarmony 4.0 的 BUILD.gn 文件,
该文件详细定义了项目的构建规则和配置信息. 其中, “source”字段指定了构建模块所需的源文件, 而“deps”字段
则列出了当前模块所依赖的其他模块或源文件, 从而形成了“source”文件集与“deps”文件集之间的依赖关系.
如表 3 所示, 我们解析了 14 873 个 BUILD.gn 文件, 从中提取了 12 277 个构建模块, 并筛选出同时包含非空
“source”和“deps”字段的模块, 构建了 6 999 对模块依赖关系. 通过解析“source”字段获取模块的源文件集, 并根据
“deps”字段识别直接依赖的文件集, 同时构造间接依赖关系. 例如, 若模块 A 的“deps”指向模块 B, 模块 B 的“deps”
指向模块 C, 则 A 的“source”与 C 的“source”之间存在间接依赖. 由于路径变量解析失败或文件缺失, 最终保留
1 609 对直接依赖和 175 对间接依赖模块, 共形成 1 784 对模块依赖关系, 用于评估工具的依赖检测能力.
如表 7 所示, CAnalyzer 在检测文件集依赖关系时表现优异, 其精确率为 94.79%, 召回率为 98.99%. 在 1 784 对
依赖关系中, 工具通过#include、extern、struct、class 和 enum 等多种方式准确检测了直接依赖中的 1 591 对, 以
及全部间接依赖, 误报 97 对, 漏报 18 对. 在所有正确识别出的直接依赖中, 69.26% 的直接依赖由#include 建立, 其
余 30.74% 的直接依赖是由 extern 语句建立起来的, 体现了 CAnalyzer 在依赖检测的全面性和准确性.

表 7 文件集间依赖关系检测实验结果

TP (直接依赖) TP (间接依赖)
FP FN Precision (%) Recall (%)
由#include建立 由extern建立 由struct建立 由class建立 由enum建立
1 102 489 7 167 1 97 18 94.79 98.99

● 假阳性 (FP) 分析. 在 97 个假阳性中, 问题源于间接依赖检测的偏差. 由于采用字符串解析的方法, 系统会
误将某些相似的字符串当作依赖关系. 例如, 假设 A 文件集中的某个函数 logInfo() 输出了一个字符串“UserData is