Source-linked AI summary
sbom-unifier: Integration Framework for Heterogeneous SBOMs
Yusuke Moriwaki, Tetsuya Kanda, Yuki Manabe, Shi Qiu, Shiyu Yang, Erina Makihara, Norihiro Yoshida, Katsuro Inoue
TL;DR
Existing SBOM generation tools often leave SPDX fields incomplete because their outputs have uneven coverage, limiting metadata availability for security and compliance workflows. sbom-unifier aligns components by PURL, complements fields with deterministic resolution, reconstructs references, and enriches file-level data. Across 90 open-source projects, it preserves high required-field completeness and improves coverage across 39 SPDX 2.3 fields relative to individual tools.
Problem
Existing SBOM tools produce heterogeneous outputs with missing or partially populated SPDX fields, affecting downstream vulnerability and license-compliance analysis.
Method
sbom-unifier integrates multiple SBOMs by aligning components with PURL, complementing fields deterministically, reconstructing references, and enriching file-level data.
Results
Across 90 open-source projects, sbom-unifier preserves high completeness for required fields and improves completeness across the evaluated SPDX fields over individual tools.
Takeaways & Limitations
SBOM quality can be treated as structured software metadata integration rather than mere document aggregation.
Takeaways & Limitations
The generated SBOMs still depend on underlying tool outputs because sbom-unifier does not verify or correct their field values.
Abstract
from arXiv · showhide
A Software Bill of Materials (SBOM) is a machine-readable inventory of software components, increasingly required for vulnerability management and license compliance. However, existing SBOM generation tools often leave many SPDX-defined fields missing or only partially populated, because different tools produce heterogeneous outputs with uneven field-level coverage. We present sbom-unifier, a framework that improves SBOM completeness through field-level integration and complementation of multiple tool outputs and file-level enrichment. Unlike existing tools that simply concatenate SBOMs without identifying records referring to the same component, sbom-unifier identifies components via Package URL (PURL), complements missing field values by a deterministic priority-based strategy, reconstructs cross-section references, and further enriches file-level fields. Across 90 open-source projects in 9 programming languages, sbom-unifier preserves high completeness for required fields and, over the 39 SPDX 2.3 required and optional fields, raises the fully covered rate by 8 percentage points and reduces the totally missing rate by 11 percentage points over the respective best-performing individual tools. sbom-unifier is available at https://github.com/MoriwakiYusuke/sbom-unifier.
I. INTRODUCTION
SBOM tools often leave SPDX metadata incomplete, motivating sbom-unifier, which integrates heterogeneous outputs and enriches missing fields to improve field-level completeness.
- Incomplete metadata from existing SBOM generation tools can hinder security-risk management and license-compliance workflows.SBOMs provide machine-readable software-component and dependency information, but tools may leave required and optional fields blank.
- sbom-unifier identifies corresponding components across heterogeneous SBOMs using PURL and complements missing metadata through field-level merging and file inspection.The framework is intended to integrate, inspect, and compare SBOMs generated by multiple tools.
- The framework includes quantitative field-level completeness evaluation for direct comparison with individual SBOM generation tools.
- Across 90 open-source projects, sbom-unifier improves field-level completeness compared with individual SBOM generation tools.
II. BACKGROUND AND RELATED WORK
Source SBOMs are widely used to describe software composition, but heterogeneous generation tools provide uneven SPDX field coverage. Existing merging approaches often concatenate records without identifying duplicate components or completing their metadata.
- Source SBOMs provide a fundamental view of software composition and are widely used in practice.SBOMs can correspond to design, source, build, or runtime lifecycle stages.
- Different SBOM tools pursue different analysis goals, producing substantially varying field sets and no single tool with comprehensive SPDX metadata completeness.
- Incomplete required and optional fields can negatively affect vulnerability detection and license-compliance analysis.Coverage becomes substantially lower when optional fields are included.
- SBOM merging: Concatenation-based merging creates duplicate component entries, leaves missing fields unfilled, and preserves references to premerge records.This approach concatenates sections without checking whether entries describe the same package or file.
- SBOM merging: FatBOM identifies packages by name and version but does not perform per-field complementation or preserve original cross-section references.Its limitations motivate the approach developed in sbom-unifier.
III. SBOM FIELDS AND EVALUATION SCOPE
The evaluation classifies SPDX fields by requirement status and excludes deprecated or uncommon fields. It evaluates 39 SPDX 2.3 fields across required and required-plus-optional scopes.
- SPDX fields are categorized as required, optional, deprecated, or omitted according to the specification and practical usage criteria.Omitted fields include uncommon sections and fields requiring manual input or external curation.
- 39 evaluated fields comprise 14 required and 25 optional fields, excluding deprecated and omitted fields.The complete field list is grouped by SPDX section and requirement status in Table I.
- The study evaluates two scopes: Required Scope and Required+Optional Scope.Required Scope contains fields categorized as required; Required+Optional Scope contains fields categorized as required or optional.
IV. DESIGN PRINCIPLES AND REQUIREMENTS
sbom-unifier is designed as a configurable, reproducible integration framework organized around component alignment, field complementarity, deterministic resolution, and measurable completeness.
- The framework aligns corresponding components across heterogeneous SBOMs with PURL and complements missing field values from peer records.This contrasts with concatenation-based merging, which performs only a structural union.
- sbom-unifier measures field-level completeness and compares individual tool outputs with the unified SBOM.
- Conflicting field values are resolved using a deterministic priority strategy for reproducible and configurable handling.
- Missing fields can be enriched through lightweight file inspection and external tools.
V. ARCHITECTURE OF SBOM-UNIFIER
sbom-unifier combines outputs from multiple SBOM generators, aligns components and files, complements missing values, enriches file metadata, and reports field-level completeness.
- Architecture: The workflow accepts a target repository, selected SBOM tools, and merge settings, then produces a unified SBOM and completeness summary.The interface supports repository selection, tool selection, and merge-priority configuration.
- Architecture: The Generation Engine collects SBOMs from Microsoft SBOM Tool, Syft, Trivy, GitHub Dependency Graph, and optional external inputs.Users configure repositories, tools, and merge priorities through the input interface.
- Architecture: The Merging Engine aligns packages by PURL and files by path, then complements missing or NOASSERTION values from peer records.Entries without PURLs are excluded from alignment, while unmatched entries remain distinct packages.
- Architecture: The Enrichment Engine recovers file-related metadata, including file types and licenses, through lightweight inspection and Ninka.This stage addresses fields not recovered through cross-tool complementation alone.
- Architecture: The Evaluation Engine summarizes completeness statistics and presents them with the unified SBOM through the result interface.The result interface displays the effects of integration and enrichment.
A. Evaluation Setup
The evaluation compares sbom-unifier with the same four individual SBOM tools across 90 projects in nine programming languages and two field scopes under fixed conditions.
- A. Evaluation Setup: The comparison uses Microsoft SBOM Tool, GitHub Dependency Graph, Syft, and Trivy under identical conditions.Field-level coverage is computed for each individual output and the unified SBOM.
- A. Evaluation Setup: The fixed merge order uses Microsoft SBOM Tool as the base, followed by Dependency Graph, Syft, Trivy, and the Enrichment Engine.Fixing the order supports reproducibility during evaluation.
- A. Evaluation Setup: The study evaluates 90 highly starred public GitHub projects, selecting 10 projects from each of nine programming languages with at least 95% language purity.The languages are C#, Go, Java, JavaScript, PHP, Python, Ruby, Rust, and Swift.
- A. Evaluation Setup: The evaluation covers the Required Scope and the Required+Optional Scope.The corresponding aggregate coverage results are presented in Fig. 4 and Fig. 5.
B. Evaluation Criteria
Field-level coverage classifies each evaluated SPDX field as full, part, or miss, enabling comparisons of how completely tools populate required and optional metadata.
- B. Evaluation Criteria: Coverage is measured as the proportion of evaluated fields in the full, part, and miss categories.Full means every target project populates a field; part means at least one but not all; miss means none.
- B. Evaluation Criteria: In the Required Scope, sbom-unifier, Microsoft SBOM Tool, and Syft each reach 93% full coverage, while Dependency Graph and Trivy retain a 21% miss rate.sbom-unifier matches the strongest individual full rate and converts some missing fields into partially populated fields.
- B. Evaluation Criteria: In the Required+Optional Scope, sbom-unifier reaches 50% full and 29% miss, compared with 42% full for Microsoft SBOM Tool and 40% miss for Syft.Trivy and Dependency Graph leave 59–61% of fields missing.
D. Discussion
sbom-unifier improves completeness across heterogeneous SBOM outputs, but some fields still require external metadata or manual curation, and value correctness remains dependent on underlying tools. Its current implementation is also limited to SPDX 2.3 and does not include deeper software analysis or external information sources.
- In the Required+Optional Scope, sbom-unifier reaches 50% full coverage versus 42% for the best individual tool.The result is attributed to complementation across heterogeneous tools and file-level enrichment.
- Some fields remain missing because they require external metadata or manual curation.Additional package registries or curated datasets would be needed to address them.
- Generated SBOM correctness largely depends on underlying tools because sbom-unifier does not verify or correct their values.The paper identifies correctness assessment and improvement as future work because incorrect values can be more harmful than missing ones downstream.
- Deeper source-code analysis and external information sources could further improve SBOM quality but remain beyond the current implementation.Examples include source-code inspection and web-based metadata.
- The current implementation supports only SPDX 2.3, while SPDX 3.0 and CycloneDX support remain future work.SPDX 2.3 was the only format common to all integrated generation tools when the system was developed.
VII. CONCLUSION
sbom-unifier integrates heterogeneous source SBOMs by identifying shared components, complementing metadata, enriching files, and preserving consistent references. Across 90 open-source projects, it improves field-level completeness compared with individual tools and frames SBOM quality as a structured metadata-integration problem.
- sbom-unifier identifies components by PURL, complements missing or NOASSERTION values, and reconstructs cross-section references.This distinguishes it from concatenation-based merging and preserves document consistency.
- Across 90 open-source projects, sbom-unifier improves field-level completeness compared with individual SBOM generation tools.
- sbom-unifier preserves high completeness for required fields while reducing missing values across optional fields.
- The work treats SBOM quality improvement as structured software metadata integration rather than merely document aggregation.Its architecture separates alignment and conflict-handling policies for future conflict-resolution strategies.
- sbom-unifier is available as open-source software under the MIT License with an associated replication package and Docker image.