• 论文链接：https://dl.acm.org/doi/10.1145/3766073

       开源软件在当前的软件开发中被广泛使用。不幸的是，这种集成带来了一系列挑战和潜在威胁。这些挑战是由于导入场景的多样性而出现的，这反过来可能会在客户端软件中引入恶意或易受攻击的代码，从而造成重大的安全风险。为了提高软件供应链的透明度，软件物料清单（SBOM）工具被提出来识别软件系统中的组件，但是它限制了对功能的研究（即，工具操作过程和数据字段）及其在各种进口场景中的SBOM工具的实际性能。我们进行了一项全面的实证研究，以调查不同的导入场景对SBOM工具的影响。2具体地说，我们关注三种不同的组件导入场景：构建工具导入，动态加载和源代码导入，跨越一个由152个项目组成的新基准。我们发现：（1）SBOM工具的检测能力表现出相当大的差异，特别是在识别依赖关系方面;（2）SBOM工具在动态加载和源代码导入场景中的有效性低于预期福尔斯。基于我们的研究结果，我们从不同的角度总结了经验教训，包括从业人员，工具供应商，我们的研究为软件组件使用的复杂景观提供了有价值的见解，有助于增强现代软件开发中的SBOM工具。       

随着开源软件（OSS）在现代软件开发中的深度渗透，软件供应链的复杂性与安全风险呈指数级增长，成为全球软件工程领域亟待解决的核心挑战。Linux 基金会报告显示，90% 的组织已在中度至广泛层面使用开源软件，而这种高度复用的开发模式，也使得漏洞传播路径更隐蔽、影响范围更深远 ，例如 Apache Log4j 漏洞（CVE-2021-44228）仅通过一个被广泛依赖的日志组件，便影响了超过 44% 的 Java 项目，凸显出开源组件安全管理的紧迫性。为应对这一危机，软件物料清单（SBOM）作为提升供应链透明度的关键工具应运而生：它通过记录软件组件的名称、版本、依赖关系及许可证等核心信息，为漏洞追踪、合规审计提供基础支撑。美国颁布的第 14028 号行政令与美国国家电信和信息管理局（NTIA）制定的 SBOM 最低元素标准（明确要求包含供应商名称、组件版本、依赖关系等），更将 SBOM 从 “推荐实践” 升级为 “合规刚需”，推动其在全球软件行业的落地。

然而，SBOM 的实际应用与政策要求之间存在显著断层：现有研究对 SBOM 工具的评估严重不足，既缺乏对工具核心功能的系统拆解，也未覆盖真实开发场景中多样化的组件导入方式，导致工具性能与实际需求脱节。一方面，过往研究的基准测试集存在局限性，例如 Balliu等人的研究仅依赖Maven CLI输出构建 ground truth，仅能覆盖“构建工具导入（BTI）” 场景，完全忽略了 Java 项目中常见的 “动态加载（DL，如通过 JVM 反射加载组件）” 与 “源代码导入（SCI，如直接集成第三方源码）” 两种关键方式，使得评估结果无法反映工具在复杂场景下的真实表现；另一方面，现有工具评估多聚焦于格式合规性（如是否符合 SPDX 或 CycloneDX 规范），却忽视了 “依赖关系识别准确性”“组件检测完整性” 等核心指标，部分工具甚至无法识别传递依赖或本地 JAR 文件，直接导致漏洞管理工具漏报高危风险或误判安全状态。

Java 生态系统的特殊性，进一步放大了这一评估缺口的影响。作为企业级应用的主流开发语言，Java 项目通过 Maven、Gradle 等构建工具形成了成熟的组件复用体系，但同时也面临更复杂的组件导入场景 ， 研究团队对 952 个 Maven 项目的初步分析显示，100% 的项目采用 BTI 方式，43 个项目使用 DL 实现运行时灵活加载，38 个项目通过 SCI 实现组件定制化，三种方式的并存使得 SBOM 工具需应对更复杂的检测需求。但当前 Java 生态中，SBOM 工具的性能表现呈 “黑盒” 状态：不同工具在组件检测的 F1 值上差异悬殊（最高 92.39%，最低 37.01%），在 DL 与 SCI 场景下的召回率普遍低于 40%，远不及 BTI 场景的 99%，且多数工具无法有效识别传递依赖。这种 “工具能力不均” 与 “场景覆盖不全” 的现状，导致企业即便生成 SBOM，也难以依托其实现有效的供应链安全管理。

更为关键的是，现有研究缺乏一个覆盖多导入场景的综合基准测试集，使得 SBOM 工具的评估缺乏统一标尺。过往研究的样本量小且场景单一，无法支撑对工具 “有效性（精确率、召回率）”“时间效率”“场景适配能力” 的三维评估。正是基于上述痛点，本研究旨在构建首个包含 152 个 Java 项目的综合基准测试集（覆盖 BTI、DL、SCI 三种场景），系统评估 6 款主流 SBOM 工具的性能，填补 “SBOM 工具在 Java 生态中多场景评估” 的知识空白，为工具优化、企业选型提供科学依据，最终推动软件供应链安全体系的完善。

本研究的初步研究围绕两个核心问题展开，分别是 PQ1 “SBOM 应包含哪些类型的组件” 与 PQ2 “Maven 项目中组件的导入方式有哪些”。这两个问题的解答旨在为后续基准测试集构建与评估框架设计提供关键依据，解决当前 SBOM 工具评估中 “组件范围不明确” 与 “导入场景覆盖不全” 的问题。

针对 PQ1，研究团队首先梳理现有文献，明确软件组件的定义为 “具有契约化接口与明确依赖、可独立部署且支持第三方组合的单元”。结合 Java 生态的实际开发情况，团队进一步确定 SBOM 需同时覆盖第三方库（TPLs）与内部开发组件，且这些组件需通过 JAR 文件或源码两种形式集成。这一结论的核心原因在于，Maven 等常见构建工具无法有效管理跨语言包，比如 Java 项目中可能用到的 C 库 jemalloc，而源码导入能有效解决此类跨语言兼容性问题。

针对 PQ2，研究团队下载了 GitHub Top 2000 中 952 个高星 Maven 项目，通过多种方式开展分析。团队利用 Maven CLI 解析项目 POM 文件以识别相关组件，手动检索项目中的 JAR 文件并分析其使用情况，同时探究源码集成模式，比如 git 子模块的应用。最终研究发现，Java 项目存在三种主流组件导入方式。第一种是构建工具导入，即通过 Maven、Gradle 等工具以 GAV 坐标从中央仓库获取组件，952 个项目全部采用这种方式。第二种是动态加载，通过 JVM 反射、ClassLoader 等机制在运行时加载组件，有 43 个项目采用该方式以提升运行灵活性。第三种是源代码导入，通过.gitmodules 文件集成子模块或直接导入源码，38 个项目采用此方式以实现组件定制化。这些结果不仅明确了 SBOM 工具需要覆盖的组件类型与实际场景，还直接为后续包含 152 个项目、覆盖三种导入方式的基准测试集构建提供了现实依据。

为解决现有 SBOM 工具评估在 Java 生态中 “场景覆盖不全”“基准缺失”“功能分析不系统” 的问题，本文设计并实现了一套多维度、可复现的 SBOM 工具分析体系，核心包含 “综合基准测试集构建”，“精准 Ground Truth 生成”，“SBOM 工具功能对比” 三大模块，通过标准化流程梳理 Java 生态下 SBOM 工具的功能边界与场景适配能力，为后续工具性能分析与优化方向提供基础支撑。

图1评估体系的架构

首先是综合基准测试集的设计与实现，该基准是工具分析的核心载体，旨在覆盖 Java 项目真实组件导入场景并保证数据代表性。团队以 GitHub Top 2000 高星 Java 项目为初始数据源，考虑到 Maven 是 Java 生态最主流的构建工具，能反映多数企业开发实践，最终筛选出 952 个采用 Maven 构建的项目。为平衡统计严谨性与数据处理可行性，团队采用 Cochran 样本量公式，设定 95% 置信水平与 5% 误差边际，从 952 个项目中随机抽取 274 个样本；再通过逐一执行项目 README 中的配置指令完成构建验证，最终确定 132 个可成功构建的项目组成数据集 D1，用于反映真实开发场景下工具对组件与依赖的识别情况。同时，针对 D1 中 “场景标签缺失”“导入方式分布不均” 的问题，团队单独构建数据集 D2 以针对性分析工具在特定导入场景下的表现：D2 包含 30 个项目，其中 10 个为仅采用构建工具导入的项目，10 个为手动开发的仅动态加载场景项目，10 个为仅源代码导入场景项目；三类项目均选用 Maven Central 中不同分类的热门组件确保场景代表性，最终 D1 与 D2 共覆盖 152 个独特 Java 项目，形成首个覆盖构建工具导入、动态加载、源代码导入三种核心导入场景的 SBOM 工具分析基准。

其次是 Ground Truth 的具体实现，针对不同导入场景，团队采用差异化方法提取信息：对于构建工具导入场景，通过执行 Maven CLI 命令获取项目完整依赖树，提取组件的 GAV 坐标（即 GroupId、ArtifactId、Version 的组合）及直接与传递依赖关系；对于动态加载场景，先通过关键词组筛选项目，第一组为 JAR 文件关联关键词，包括 “URLClassLoader & new URL”“JarURLConnection & new URL”“import java.util.jar.JarFile”，第二组为类加载关键词，包括 “loadClass & newInstance”“forName & newInstance & invoke”，通过组合关键词检索定位动态加载相关项目，再由两位研究者手动验证第三方组件是否通过动态加载导入，最终确定 10 个动态加载项目及 48 个对应组件；对于源代码导入场景，通过检查项目是否存在.gitmodules 文件识别子模块集成的组件，同时手动分析源码目录确认直接导入的第三方源码组件，共发现 2 个源代码导入项目及 3 个对应组件。最后团队整合三类场景的组件信息，补充每个组件的供应商、版本、依赖层级（直接或传递）等元数据，形成包含组件、导入场景、依赖关系三维信息的完整 Ground Truth，且所有信息均经过双人交叉验证以排除遗漏或错误。

为系统性量化 Java 生态中 6 款主流 SBOM 工具的实际性能，明确工具在不同场景下的适配能力与短板，本研究搭建了标准化实验框架。评估基于前期构建的双数据集（D1：132 个可成功构建的真实 Maven 项目，用于整体性能评估；D2：30 个单导入场景项目，含 10 个构建工具导入 / BTI、10 个动态加载 / DL、10 个源代码导入 / SCI 项目，用于场景适配性评估），以包含组件、导入场景、依赖关系三维信息的 Ground Truth。在有效性，时间效率和不同场景的表现三个维度进行评估。

有效性评估聚焦工具在组件检测与依赖检测两大核心能力，通过精确率、召回率、F1 值量化表现，所有指标先按单个项目计算再取平均值以降低项目差异影响。在组件检测方面，工具表现差异显著：SBOM Tool 因深度利用 Maven CLI 输出的依赖树，以 93.72% 的精确率、92.17% 的召回率实现 92.39% 的 F1 值，位列第一；Cdxgen 与 SPDXGen 紧随其后，F1 值分别为 83.06% 与 74.99%，二者均能结合 Maven 配置与项目文件解析组件；Dependency Track 与 Syft 表现最弱，F1 值仅 37.01% 与 41.11%，主要因二者依赖 JAR 文件扫描，无法识别 DL 与 SCI 场景的组件，导致漏检率高。在依赖检测方面，Cdxgen 优势突出，以 47.13% 的精确率、71.16% 的召回率达成 54.57% 的 F1 值，其支持解析 POM 文件与 Maven 依赖树，能有效识别传递依赖；其余工具 F1 值均低于 50%，其中 SBOM Tool、Syft、Dependency Track 因未支持传递依赖解析或仅依赖 JAR 文件扫描，依赖检测 F1 值为 0，无法满足完整依赖分析需求。

图2不同构件和依赖性分析工具的性能比较

时间效率评估以工具生成单个项目 SBOM 的平均耗时为核心指标，重点分析工具扫描策略与流程设计对效率的影响。结果显示，不同工具耗时差异极大：Syft 耗时最短，平均仅 5.09 秒，其优势在于直接扫描项目文件系统与二进制 artifacts（如 JAR 文件），无需调用 Maven 等构建工具执行依赖解析，大幅减少流程开销；SPDXGen 与 SBOM Tool 次之，平均耗时分别为 29.88 秒与 48.32 秒，二者虽需解析 POM 文件，但未涉及复杂的远程依赖查询；Cdxgen 耗时最长，平均达 315.19 秒，主要因其需调用 Maven Central 远程接口获取组件元数据，同时执行项目编译以生成完整依赖树，且需与 Dependency-Track 平台集成进行深度分析，导致时间成本显著增加。这一结果表明，工具效率与检测深度存在明显权衡 —— 避免构建流程与远程交互的工具更高效，但可能牺牲检测完整性；追求全面依赖解析的工具则需承担更高时间开销，需根据实际场景需求选择。

为评估聚焦工具在 BTI、DL、SCI 三种核心导入场景下的适配能力，通过各场景下的组件检测 F1 值量化表现。在 BTI 场景中，工具整体表现最优：SBOM Tool 与 Cdxgen 凭借对 Maven 配置文件（如 POM.xml）与依赖树的精准解析，F1 值分别达 99.33% 与 99.28%，精确率与召回率均接近 100%，能完整识别通过 Maven 获取的组件；SPDXGen 次之，F1 值 85.80%；Syft 与 Dependency Track 因存在较多误检（如将测试依赖判定为生产依赖），F1 值仅 52.93% 与 56.79%。在 DL 场景中，工具表现分化明显：Dependency Track 通过识别 JAR 文件中的运行时加载特征（如反射关键词），以 86.76% 的精确率、77.02% 的召回率实现 78.06% 的 F1 值；Syft 次之，F1 值 50.30%；SBOM Tool、Cdxgen、Trivy 虽精确率达 100%，但召回率仅 22.63%，无法识别多数动态加载的组件；SPDXGen 完全未检测到有效组件，F1 值为 0。在 SCI 场景中，工具整体表现最弱：Trivy、Cdxgen、SBOM Tool 并列第一，F1 值均为 48.08%，主要依赖识别编译后生成的 JAR 文件，而非直接解析源码；Syft 与 Dependency Track F1 值分别为 33.58% 与 43.61%；SPDXGen 不仅未检测到组件，还误报无关依赖，精确率为 0。这一结果证实，当前工具对 BTI 场景适配度最高，但在 DL 与 SCI 场景下普遍存在能力缺口，需针对性优化。

图3不同导入方式下检测工具的性能比较

信息来源：HUSTSCOPELab  李超凡