Ilmu Komputer & AI editorial
sbom-unifier: Integration Framework for Heterogeneous SBOMs
The core problem
A Software Bill of Materials (SBOM) is a machine-readable inventory of software components, increasingly required for vulnerability management and license compliance. Despite this growing demand, existing SBOM generation tools often leave many SPDX-defined fields missing or only partially populated. The root cause is heterogeneity: different tools produce outputs with uneven field-level coverage, so no single tool yields a complete SBOM for a given project.
Prior integration approaches simply concatenate SBOMs without identifying records that refer to the same component, which produces duplicated and inconsistent entries rather than a genuinely more complete document. The authors of this work address that gap with **sbom-unifier**, a framework that improves SBOM completeness through field-level integration and complementation of multiple tool outputs, plus file-level enrichment. The framework is evaluated across 90 open-source projects spanning 9 programming languages, and is released as open-source software.
Innovation
The evaluation spans **90 open-source projects** across **9 programming languages**, and completeness is measured over the **39 SPDX 2.3 required and optional fields**. Two headline metrics are reported:
- **Fully covered rate:** sbom-unifier raises the fully covered rate by **8 percentage points** over the best-performing individual tool.
- **Totally missing rate:** sbom-unifier reduces the totally missing rate by **11 percentage points** over the best-performing individual tool.
These gains are achieved while preserving high completeness for required fields, indicating that the integration does not trade required-field coverage for optional-field gains. The comparison baseline is the respective best-performing individual tool for each metric, making the reported improvements conservative relative to comparisons against average or weakest tools.
Why it matters
The results support the central claim that SBOM incompleteness is, to a meaningful degree, an integration problem rather than a generation problem. Because different tools populate different subsets of SPDX fields, merging their outputs at the field level recovers information that no single tool exposes on its own.
The design choices matter for the observed gains. PURL-based identification is what distinguishes sbom-unifier from concatenation-based approaches: without a stable component key, records for the same component would remain duplicated and field values could not be reconciled. The deterministic priority-based strategy is equally important for practical adoption, since reproducibility is a prerequisite for SBOMs used in audit and compliance workflows. Cross-section reference reconstruction and file-level enrichment extend the benefit beyond simple field filling, addressing structural consistency and finer-grained file information.
Several limitations follow from the reported scope. The evaluation covers 90 open-source projects in 9 programming languages, so generalization to closed-source, proprietary, or differently structured codebases is not established by these results. The 8- and 11-percentage-point improvements are relative to the best-performing individual tools on the 39 SPDX 2.3 fields; the residual gap to full coverage is not quantified in the abstract. Finally, the priority-based strategy is deterministic but its priority ordering is a design parameter whose sensitivity is not characterized here.
Overall, sbom-unifier reframes SBOM completeness as a field-level integration and enrichment task, and provides an open-source implementation for reproducibility and further study.
Who should read this
Opening member contentโฆ