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

徐美秋 等: CAnalyzer: 面向 C/C++源代码的软件成分分析技术 2809

a multi-threshold matching strategy. Additionally, CAnalyzer analyzes dependency directives in the source code to automatically construct
dependencies among TPLs. Experimental results show that CAnalyzer achieves a precision of 90.63% and a recall of 86.57% in TPL
detection, outperforming CENTRIS, TPLite, and OSSFP in both metrics. In TPL dependency detection, CAnalyzer achieves a recall of
94.79% and a precision of 98.99%. Currently, CAnalyzer has been adopted by the OpenHarmony community and has identified 166
external components across 689 code repositories, demonstrating its practical value in open-source community management.
Key words: open-source software reuse; software composition analysis (SCA); third-party library (TPL) dependency

1 引 言

随着开源生态的蓬勃发展, 第三方库 (third-party library, TPL) 被广泛应用于软件开发, 极大地提高了开发效
率 [1,2] . 然而, 被复用的第三方库可能引入安全漏洞, 从而带来潜在的安全隐患 [3−7] . 为应对这一问题, 软件成分分析
(software composition analysis, SCA) 技术应运而生. SCA 技术通过分析开源软件和商业软件中的源码、模块和框
架, 识别并枚举被复用的第三方库, 检测已知的安全漏洞、未修补的漏洞及许可证合规性风险等问题, 从而确保软
件供应链中第三方库的安全性与合规性. 本研究聚焦于针对 C/C++语言软件的源到源 (source-to-source, S2S) 的
SCA 技术, 该技术基于源代码构建特征库, 匹配目标代码特征与已知 TPL 代码特征的相似性来识别 TPL. 已提出
多种基于 S2S 的 SCA 技术 [5,8−15] , 然而, 随着软件开发复杂性的增加以及 C/C++语言生态中长期存在的 TPL 管理
碎片化问题, 现有的 SCA 技术仍面临以下限制.
(1) 基于单一 C/C++ TPL 托管仓库构建特征库导致漏报 TPL. 在 C/C++语言生态系统中, TPL 资源分布于多
个托管仓库 (如 Debian、Conan、GitLab 等), 本研究调查显示, 目前有超过 15 个活跃的托管仓库包含 C/C++ TPL.
然而, 现有的 SCA 技术 [13−15] 仅依赖单一托管仓库 (如 GitHub) 收集 TPL 资源, 由于无法全面覆盖所有 C/C++ TPL,
从而导致对实际项目成分分析时出现漏检. 近期对 CENTRIS 的大规模实际项目评估 [14] 结果显示, 当复用 TPL 的
阈值设置为 1% 时 (精确率仅为 17.7%), CENTRIS 仍漏报 30.7% 的 C/C++ TPL. 因此, 基于单一托管仓库构建的特
征库不足以实现全面覆盖 C/C++ TPL.
(2) 相似性计算粒度与成分报告粒度不匹配造成误报 TPL. 现有 SCA 技术 [13−15] 通过逐一对比目标代码与已
知 TPL 中的函数相似性 (函数粒度计算相似性), 并基于相似函数的数量和占比 (相对于 TPL 总函数数) 判断是否
报告复用 TPL. 然而, 基于整个 TPL 函数数量计算阈值未能考虑函数在 TPL 文件中的分布, 如果与目标代码匹配
的函数实际上来自 TPL 不同文件的常用函数, 会被误判为有效成分, 引发 SCA 误报 TPL.
(3) 缺乏 TPL 之间依赖关系的分析限制安全性和合规性检测的准确性. 现有的 SCA 技术 [13−15] 主要关注 TPL
成分的识别, 但未深入分析 TPL 之间的依赖关系, 导致以下两个主要问题: (a) 难以全面了解漏洞在各个 TPL 之间
的传播路径和影响范围, 限制了安全团队根据漏洞传播路径优先处理关键问题的能力 [16−19] ; (b) 无法准确识别实际
依赖路径中的许可证冲突、许可证兼容性等合规性问题, 进而增加了软件合规性风险.
然而, 为了克服这些限制, 在构建全面覆盖 C/C++ TPL 的特征库、优化 TPL 检测和增强依赖关系分析的过程
中, 也伴随着新的技术挑战.
(1) 融合多个托管仓库构建 C/C++ TPL 特征库和不准确的函数诞生时间, 加剧了公共函数对 TPL 检测造成的
干扰. 构建全面的 C/C++ TPL 特征库的直接方法是收集并整合所有 C/C++ TPL 托管仓库中的 TPL. 然而, 若未经
处理将所有特征直接保存至特征库, 公共函数的干扰性将加剧. 本文所指的公共函数包括: TPL 间复用引入的克隆
函数 [13] , 以及实现常见算法 (如排序、查找算法等) 的相似函数. 如果这些公共函数与目标代码匹配, SCA 技术可
能错误地将包含这些函数的 TPL 判定为目标代码的有效成分. 为了减少公共函数引起的干扰, 已有研究引入了函
数诞生时间 (function birth time) [13,14] 帮助确定函数最早出现的库, 进而明确其原始 TPL 并排除误报 TPL. 然而, 在
融合多个托管仓库构建的特征库中, 函数诞生时间的准确性受到挑战: (a) 非 Git 管理的托管仓库 (如通过 FTP
Server 发布源代码的 C/C++ TPL) 难以获取函数诞生时间; (b) Git 管理的托管仓库中约 20.0% 的 C/C++ TPL 缺乏
Release/Tag, 导致获取不准确的函数诞生时间; (c) C/C++ TPL 迁移至其他托管仓库时, 丢失历史版本的函数诞生
时间. 因此, 融合特征库中公共函数归属原始 TPL 的确认问题仍然是一个亟待解决的挑战.