论文来源：https://arxiv.org/abs/2402.11151 A Landscape Study of Open Source and Proprietary Tools for Software Bill of Materials (SBOM)

以下论文总结由豆包生成：

一、研究背景

现代软件应用依赖众多第三方组件，软件供应链安全面临挑战。软件物料清单（SBOM）作为解决方案，可记录应用中的第三方组件及依赖关系，提高软件透明度。近期供应链攻击事件凸显了软件安全的重要性，SBOM 在其中发挥关键作用，其相关概念受重视，多种工具应运而生，但工具范围广泛且不标准。

二、研究方法

1. 定义分析范围：确定与 SBOM 相关的开源和专有工具，涵盖软件成分分析及软件供应链安全工具。
2. 文献分析与访谈：研究相关文献，与网络安全公司进行技术讨论，以深入了解 SBOM 相关情况。
3. 工具识别：通过多种渠道，如开源仓库、网络资源、论坛、博客、行业外联及参与工作组等，利用关键词搜索工具。
4. 工具评估标准：对识别的工具进行评估，包括文档、功能审查、代码审查（开源工具），在目标项目上执行工具，考虑核心功能、可用性、互操作性和可定制性等标准。
5. SBOM Plugfest 和基准测试：对部分工具在样本软件项目上执行，进行基准测试和比较。
6. SBOM 工具现状描述：整合分析收集的信息，总结当前工具的异同和差距。

三、SBOM 工具现状

（一）新兴用例

1. SBOM 生成：54 个工具支持，部分工具使用 SPDX 和 CycloneDX 等标准格式，少数有自己的格式，部分工具从项目源生成，部分为用户提供创建接口。
2. SBOM 使用
   • 漏洞管理（VEX）：通过查询漏洞数据库识别软件中的漏洞。
   • 依赖滥用检测：检测依赖关系中的不当使用。
   • 许可证合规性：检查软件组件的许可证问题。
3. SBOM 互操作性：解决不同格式 SBOM 的聚合问题，包括转换、合并和比较工具。
4. SBOM 质量保证：验证 SBOM 的有效性和质量，包括模式检查、内容验证和评分。
5. SBOM 服务
   • 存储和管理：提供集中存储 SBOM 数据的位置。
   • 共享：促进 SBOM 在供应链中的共享。
   • 事件响应：自动化漏洞通知和管理。
   • 签名：对 SBOM 进行签名和验证。

（二）SBOM 生成

1. 支持的输入和开发环境
   • 源 SBOM：63% 的工具支持，多数通过清单文件（如 pom.xml 或 package.json）生成，部分通过源代码分析。
   • 部署 SBOM：26% 的工具支持，通过包管理器获取已安装软件的信息。
   • 分析 SBOM：17% 的工具支持，对构建后的工件进行分析生成。
   • 设计 SBOM：9% 的工具支持，用于规划软件项目。
   • 构建 SBOM：9% 的工具支持，作为构建过程的一部分生成，便于集成到 CI/CD 管道。
   • 运行时 SBOM：仅 1 个工具支持，实时捕获运行时的依赖关系。
2. 支持的生态系统：OSS 非设计 SBOM 生成器支持多种编程语言和包管理或构建系统，部分工具支持特定操作系统的包管理器和图像二进制文件。
3. 支持的模式：CycloneDX 和 SPDX 是主要格式，多数生成工具至少支持一种，第三方工具更倾向于支持 CycloneDX。

（三）SBOM 使用和利用

1. 许可证管理：部分工具用于管理软件组件的许可证。
2. 漏洞管理和 VEX：漏洞扫描工具使用 SBOM 检测和修复漏洞，部分工具利用 VEX 生成或更新漏洞报告。
3. 其他用例：一些工具提供可视化和访问管理等功能，方便使用 SBOM。

（四）SBOM 互操作性

15% 的工具解决不同格式 SBOM 的互操作性问题，但由于缺乏统一标准，主流格式之间也无法直接映射，导致中间 SBOM 的出现，其格式不一致。

（五）SBOM 质量保证

17% 的工具提供验证 SBOM 质量的方法，多数仅进行模式验证，部分提供其他指标，如 NTIA 合规性、许可证验证、UID 验证、哈希存在和依赖关系信息，但缺乏标准化和深入的质量指标。

（六）SBOM 服务

15% 的工具提供 SBOM 服务，包括存储库服务器、CI/CD 插件和签名及证明工具，有助于促进 SBOM 的采用。

四、SBOM Plugfest 实验

（一）实验设置

1. 工具选择：选择支持语言和生态系统最多的五个开源 SBOM 生成工具。
2. SBOM 类型：生成源 SBOM。
3. 基准项目和测试用例：使用 Maven 构建的 Java 项目，包括正常使用依赖、未使用的依赖导入和仅清单文件包含依赖三种场景。
4. 实验执行和方法：使用标准化 Docker 镜像，在不同场景下运行工具，分析生成的 SBOM 是否包含 NTIA 定义的最小元素。

（二）实验结果

1. 源代码对 SBOM 输出无影响：工具生成的 SBOM 相同，引发对依赖清单文件而不参考源代码的担忧。
2. PURL 和 CPE 使用差异大：组件的 PURL 更常见，Syft 是唯一提供 CPE 和 PURL 信息的工具。
3. Maven 和清单文件对依赖关系的影响：Maven 和清单文件影响工具的依赖关系报告能力，缺失时确定依赖关系困难。
4. 构建系统移除导致数据丢失：构建系统移除后，SBOM 中的数据丢失严重，尤其是依赖关系信息，影响依赖和漏洞管理。

（三）总体分析

实验揭示了现有 SBOM 生成工具存在的问题，包括缺乏大规模准确的基准数据、依赖次级系统导致不准确、生成结果不一致、成分标准化不足、对包管理系统支持有限和软件识别挑战等。

五、研究结论

1. 研究收集 84 个 SBOM 相关工具数据，分类并评估市场情况，虽工具多样表明社区对 SBOM 概念接受度高，但筛选工具困难。
2. 不同工具功能多样，OSS 工具多需手动生成 SBOM，部分专有工具可自动集成，软件供应链安全受关注，当前 SBOM 市场有差距需改进，以提高 SBOM 采用率和易用性，未来需更多研究和开发将 SBOM 工具集成到软件获取过程中。