编辑推荐：
软件物料清单（software bill of materials，SBOM）在Log4Shell和SolarWinds等高关注度攻击之后，已成为软件供应链透明度的重要机制。然而，SBOM的实际价值完全取决于其准确性和完整性，而这两者又受SBOM生成工具能力与
软件物料清单（software bill of materials，SBOM）在Log4Shell和SolarWinds等高关注度攻击之后，已成为软件供应链透明度的重要机制。然而，SBOM的实际价值完全取决于其准确性和完整性，而这两者又受SBOM生成工具能力与局限的影响。本系统性文献综述（systematic literature review，SLR）综合了当前SBOM生成方法学和工具现状，识别实现高保真SBOM的关键挑战，并提出未来研究方向。研究人员遵循PRISMA（Preferred Reporting Items for Systematic Reviews and Meta-Analyses）框架，从IEEE Xplore、Scopus和参考文献滚雪球中识别146条记录。在去除重复文献并应用纳入标准后，保留27篇同行评审研究和5篇精选预印本，均发表于2022年至2025年9月，用于最终综合。应用主题分析（thematic analysis）对生成方法进行分类，评估工具在软件生态系统中的性能，并识别持续存在的挑战。本综述综合并扩展了对SBOM生成方法（静态分析（static analysis）、构建时内省（build-time introspection）、二进制分析（binary analysis）和混合分析（hybrid analysis））的既有分类，提供工具性能的跨生态系统分析，并阐明面向高保真SBOM的循证研究议程。综合结果得出四项关键洞见。第一，生成方法之间存在根本权衡——静态分析提供速度和可扩展性，但高度依赖元数据质量，而构建时内省和二进制分析提供更高保真度，却增加复杂性。第二，由于依赖管理约定和元数据标准差异，工具有效性在生态系统（Java、Python、JavaScript和容器化环境）间显著变化。第三，结合多种编程语言的多语言系统（polyglot systems）加剧可见性缺口，并暴露单一生态系统工具的局限。第四，文献汇聚于一个新兴研究议程，优先考虑混合分析技术、人工智能（AI）驱动的二进制分析、运行时上下文集成以及改进的开发者可用性。尽管SBOM工具生态系统发展迅速，但在交付准确和完整输出方面的碎片化和不一致仍是重大挑战。通过混合和生态感知方法应对这些挑战，对于可信SBOM的广泛采用和软件供应链安全（software supply chain security）的强化至关重要。
1 Introduction：Log4Shell和SolarWinds等高关注度事件暴露了现代软件供应链风险，现代软件由开源库和第三方依赖构成，攻击面扩大。SBOM成为软件透明度和安全基石，Executive Order 14028推动其从最佳实践转向美国政府相关合规要求。理论上，SBOM是减少软件生产者与消费者信息不对称的透明度构件，但其有效性取决于数据保真度，即准确性和完整性。既有研究显示，从静态文件分析到动态二进制分析和构建时内省均存在权衡，实践中工具输出仍不一致。该综述区别于已有SoK、灰文献综述和景观研究，聚焦生成方法与经验准确性/完整性结果、跨生态系统综合及多语言系统复杂性，并提出总研究问题及四个子问题。
2 Methodology
2.1 Overview：该研究采用系统性文献综述（SLR），遵循PRISMA框架，以保证检索、筛选、提取和综合过程透明并减少偏差。
2.2 Database Selection：选择IEEE Xplore和Scopus，因其覆盖软件工程和网络安全研究。未直接检索ACM Digital Library和Web of Science，理由是Scopus已索引主要ACM会议，且通过滚雪球补充；但承认可能存在覆盖偏差。
2.3 Search Strategy：检索2022年1月至2025年9月文献，关键词涉及SBOM、生成、工具、生态系统、准确性、完整性、SPDX、CycloneDX和SWID。Scopus返回77条，IEEE Xplore返回57条，滚雪球补充12条；去重后136条。2022年前基础文献未引入改变分类的新生成方法。
2.4 Inclusion and Exclusion Criteria：纳入同行评审会议和期刊论文，以及无同行评审版本且提供实质经验的预印本；内容须聚焦SBOM方法、工具、挑战和局限；语言为英文；时间2022—2025年。排除书章、综述、博客、社论等。最终纳入5篇预印本。
2.5 Screening and Study Selection：2.5.1 Stage 1—Title and Abstract Screening：主作者筛选136条，第二作者随机独立筛选30条，Cohen's kappa为κ = 0.86，排除90条，剩余46条。2.5.2 Stage 2—Full-Text Review：主作者全文审查46篇，第二作者随机审查12篇，一致率100%，排除14篇，最终纳入32篇。
2.6 Quality Assessment：采用Dyb?和Dings?yr质量评估框架，包含C1相关性、C2严谨性、C3可信度和C4报告，每项0—2分，总分8分。平均分6.3，SD = 1.1，26篇高置信，6篇中等置信；评分者间ICC = 0.92（95% CI [0.78, 0.97]）。
2.7 Data Extraction and Synthesis：使用结构化数据提取表，并采用Braun和Clarke六阶段主题分析，将主题映射至四个研究子问题。
3 Results
3.1 Article Selection：从146条记录开始，去重10条后筛选136条，排除90条，全文审查46篇，再排除14篇，最终纳入32篇。
3.2 Article Classifications：32篇研究显示2024年发表量增长，CAGR = (5/1)
(1/3) ? 1 ≈ 0.71，约71%，但为描述性统计。领域处于形成至早期成熟阶段。分类为工具评估9篇、新方法7篇、生态挑战6篇、开发者/利益相关者视角4篇、景观/综述6篇。实证评估最多而新框架较少；无单一方法在所有环境中实现高保真，文献趋向混合与集成方法。
3.3 A Taxonomy of SBOM Generation Methodologies：基于既有分类，研究定义四类方法：静态分析、构建时内省、构建后/二进制分析和混合分析。静态分析速度快、易集成，但依赖元数据，漏检传递或动态依赖；构建时内省对编译和链接组件保真度高，但难覆盖构建后或解释型依赖；二进制分析可处理无源码系统，但版本识别困难且假阳性/假阴性较高；混合分析可交叉验证并提高保真度，但实现复杂且尚未成熟。比较上，静态分析准确性中、完整性低、可扩展性和自动化高；构建时准确性高、完整性中、可扩展性和自动化中；二进制准确性低—中、完整性中、可扩展性低、自动化中；混合准确性高、完整性高、可扩展性和自动化低。
3.3.1 Static Analysis：静态分析解析requirements.txt、pom.xml和package.json等清单文件，速度快，但元数据质量是主要误差来源。非标准或畸形元数据可导致解析器混淆（parser confusion），Python生态缺乏统一强制元数据标准，GitHub Dependency Graph与清单和锁文件之间也存在不一致。
3.3.2 Build-Time Introspection：构建时内省监控编译器、链接器等构建过程。ABOM将输入源文件哈希注入二进制，OmniBOR构建Artifact Dependency Graph，另有增量构建方法。该方法可验证性较强，但可能漏掉动态加载或构建后引入组件。
3.3.3 Post-Build/Binary Analysis：构建后/二进制分析扫描最终二进制或容器，用于遗留系统、COTS和容器化应用。GrizzlyBay使用局部敏感哈希，AI和语义相似方法可识别二进制及JavaScript包中的代码克隆。Syft和Trivy可识别通过包管理器安装的OS包，但难发现手动安装组件。
3.3.4 Hybrid Analysis：混合分析整合多种证据源。CovSBOM使用动态代码覆盖率枚举组件，表明混合方法可提高SBOM精度，但现成混合工具仍少。
3.4 The Tooling Landscape Across Software Ecosystems：SBOM效用不仅取决于生成方法，也取决于目标生态的架构和依赖管理约定。研究分析Java/Maven、Python/PyPI、JavaScript/npm和Containers/Docker四类生态。
3.4.1 Java/Maven：Maven依赖调解采用“nearest-wins”策略，工具难以准确复现，导致组件版本错误；Maven Central中SBOM发布仍有限，许多项目依赖事后生成。
3.4.2 Python/PyPI：主要问题是缺乏统一强制元数据标准，setup.py、requirements.txt和Pipfile.lock等格式不一致，工具需做假设，导致依赖图不完整和版本信息不准，并影响漏洞报告。
3.4.3 JavaScript/npm：npm依赖树极深且复杂，不同工具对传递依赖检测差异大；Webpack、Rollup等打包和压缩会移除元数据，使后构建工具难以还原原始组件，文献提出Chain-of-Experts等AI驱动方法。
3.4.4 Containers/Docker：容器镜像多层结构带来挑战。工具擅长检测OS包，但对通过curl或wget手动安装的包存在盲点，导致SBOM不完整和虚假安全感。
3.4.5 Cross-Ecosystem Comparative Analysis：3.4.5.1 Shared Challenges：元数据质量是跨生态SBOM保真的普遍决定因素。3.4.5.2 Ecosystem-Specific Divergences：Java问题是正确但复杂的元数据，Python是碎片化元数据，JavaScript是深层依赖，容器是OS层与应用层分裂。3.4.5.3 Tool Coverage Patterns：Syft和Trivy偏文件系统级OS包检测，ORT和cdxgen偏语言生态，无工具同时在四类生态实现高保真。3.4.5.4 Practical Implication：组织应采用多工具策略，将生态专用工具输出合并为统一SBOM。3.4.5.5 Conflicting Findings Across Studies：不同研究结果差异可能源于研究范围、评价指标和ground truth质量不同，不能简单视为矛盾。
3.5 The Polyglot Problem：多语言系统整合多种语言和生态，当前工具高度专业化，无法完整生成跨语言依赖图。多语言环境中的覆盖缺口使供应链风险被低估。3.5.1 Tool Orchestration and Pipelines：部署生态专用生成器管线，并利用SPDX和CycloneDX支持多生态组件合并。3.5.2 Unified Build-System Instrumentation：OmniBOR和ABOM等在构建层嵌入标识，生成语言无关依赖图。3.5.3 Schema-Level Integration：标准层支持跨引用和顶层关系声明，但工具实现不均。3.5.4 Verification and Validation：差分分析可交叉验证多工具输出，未来可探索多数投票或置信加权聚合。
3.6 A Research Agenda for High-Fidelity SBOMs：12项研究报告不完整依赖检测或不一致输出，8项关注开发者可用性，6项关注二进制和遗留系统，11项指出缺乏运行时上下文。3.6.1 Research Direction 1：发展混合分析框架，整合静态、构建时和二进制方法进行交叉验证。3.6.2 Research Direction 2：改进可用性和开发者体验，包括上下文感知工具推荐、可操作输出和DevSecOps集成。3.6.3 Research Direction 3：推进AI/ML驱动的二进制和遗留代码分析，用于组件检测、代码克隆搜索和指纹识别，并建立共享基准。3.6.4 Research Direction 4：整合运行时上下文，将静态SBOM与代码覆盖率、动态调用图等执行画像连接，CovSBOM、Osmy和运行时监控体现该方向。
4 Discussion：研究普遍认为SBOM重要，但对最佳方法无共识。混合方法有提高准确性和完整性的潜力，但需标准化数据集和评价协议验证。当前工具生态碎片化，影响DevSecOps中的持续漏洞扫描。该研究提出概念框架，认为生成方法、生态系统复杂性和工具成熟度共同影响SBOM保真度。实践上，工具开发者应优先模块化、可插拔架构；组织应采用多工具和差分验证；标准机构应推动元数据标准化和组合式SBOM；政策制定者应将SBOM要求与最低质量、认证和可复现基准结合，避免制度化虚假安全感。理论上，不完整或不准确SBOM会维持生产者与消费者之间的信息不对称。工具性能差异源于项目规模、生态约定、工具版本、SBOM格式、ground truth构建和评价指标不同。
4.1 Threats to Validity：4.1.1 Study Selection Bias：仅检索IEEE Xplore和Scopus，未直接检索ACM Digital Library和Web of Science，滚雪球部分缓解。4.1.2 Publication Bias：阳性或新颖结果更易发表，且仅限英文。4.1.3 Reviewer Bias：虽双人评审，但全文阶段无第三评审，kappa和ICC较高。4.1.4 Data Extraction Bias：提取和综合由作者完成，采用随机子集双审缓解。4.1.5 Synthesis and Metric Heterogeneity：研究指标和数据集异质，评级为定性综合。4.1.6 Quality Assessment Subjectivity：质量评分仍有主观性。4.1.7 Preprint Studies：纳入5篇预印本，证据权重较低。4.1.8 Temporal Coverage：检索截至2025年9月。4.1.9 Single-Reviewer Full-Text Assessment：全文审查主要由主作者完成，第二作者审查26%样本。
5 Conclusion：该SLR综合27篇同行评审研究和5篇预印本，表明实现准确完整SBOM仍具挑战。贡献包括组织生成方法、展示跨生态性能差异、提出未来研究方向。最高优先方向为混合分析框架和运行时上下文集成，其次是开发者可用性和AI驱动的遗留/二进制分析。实践上，组织不应依赖单一工具，而应结合多工具或混合方法，并按软件生态选择方案，同时关注动态加载和手动安装组件检测限制，将SBOM生成与运行时监控整合进DevSecOps和合规实践。
