sbom-unifier: Integration Framework for Heterogeneous SBOMs

arXiv:2608.30708v1 [cs.SE] 31 Aug 2026

sbom-unifier: Integration Framework for Heterogeneous SBOMs Yusuke Moriwaki

Tetsuya Kanda

Yuki Manabe

Ritsumeikan University Osaka, Japan is0746ps@ed.ritsumei.ac.jp

Notre Dame Seishin University Okayama, Japan kanda@m.ndsu.ac.jp

The University of Fukuchiyama Kyoto, Japan manabe-yuki@fukuchiyama.ac.jp

Shi Qiu

Shiyu Yang, Erina Makihara, Norihiro Yoshida, and Katsuro Inoue

Toshiba Corporation Kanagawa, Japan shi.qiu.b79@mail.toshiba

Ritsumeikan University Osaka, Japan (yangsy, makihara, norihiro, inoue-k)@fc.ritsumei.ac.jp

Abstract—A Software Bill of Materials (SBOM) is a machinereadable 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 bestperforming individual tools. sbom-unifier is available at https: //github.com/MoriwakiYusuke/sbom-unifier. Also, a short video is available at https://youtu.be/QgjcEADFB1w. Index Terms—software bill of materials, SPDX, software supply chain, field-level merge

I. I NTRODUCTION Modern software development increasingly depends on a large ecosystem of third-party components, particularly opensource software (OSS). While this trend accelerates development, it also introduces challenges in managing security risks and license compliance [1]. A key mechanism for addressing these challenges is the Software Bill of Materials (SBOM), which provides a machine-readable representation of software components and their dependencies [2]. The Software Package Data Exchange (SPDX), standardized by the Linux Foundation, defines a structured format of fields for representing SBOMs [3]. SBOMs represent software as sets of components described by metadata such as name, version, license, dependency, and others. However, existing SBOM generation tools often provide incomplete field availability due to their design policy, resulting in missing or partially missing fields [4].

To address this limitation, we propose sbom-unifier, a framework that improves SBOM completeness through complementation-based merging and file-level enrichment using external tools. The system identifies components across input SBOMs with PURL (Package URL) as a common identifier, complements missing field values from peer records, and enriches missing fields through lightweight file inspection. Furthermore, sbom-unifier includes an evaluation framework that quantitatively measures field-level completeness, enabling direct comparison with individual tool outputs. sbom-unifier is intended for users who need to integrate, inspect, and compare SBOMs generated by multiple tools for security and compliance workflows. The contributions of this paper are as follows: • We design and implement sbom-unifier, a framework that integrates heterogeneous SBOMs generated by multiple tools and complements missing metadata through file-level enrichment. • Through an empirical evaluation on 90 open-source projects, we show that sbom-unifier improves field-level completeness compared with individual SBOM generation tools. II. BACKGROUND AND R ELATED W ORK A. SBOM Generation Tools and Completeness SBOM generation tools produce machine-processable SBOMs from target software artifacts. Depending on the software lifecycle stage, SBOMs are categorized into types such as design, source, build, and runtime SBOMs [5]. Among these, source SBOMs are widely used in practice, as they provide a fundamental view of software composition [6]. In this paper, we focus on source SBOMs. Various SBOM generation tools have been developed, including Microsoft SBOM Tool1 , Syft2 , Trivy3 , and GitHub 1 https://github.com/microsoft/sbom-tool 2 https://github.com/anchore/syft 3 https://github.com/aquasecurity/trivy

Dependency Graph4 . These tools are designed with different analysis goals, such as dependency extraction, vulnerability scanning, or repository metadata analysis [7]. As a result, the set of fields in the SBOMs they generate varies significantly [8], [9], and no single tool achieves comprehensive metadata completeness of SPDX-defined fields [4]. Even for required fields, tools may leave some fields blank, and coverage becomes substantially lower when optional fields are included. This incompleteness of SBOM metadata can negatively affect downstream tasks such as vulnerability detection and license compliance analysis [10]. Section VI quantitatively evaluates this limitation and shows how sbomunifier improves field-level completeness.

TABLE I E VALUATED SPDX 2.3 FIELDS BY SECTION AND REQUIREMENT STATUS (R: REQUIRED , O: OPTIONAL ). T HE 39 EVALUATED FIELDS COMPRISE 14 REQUIRED AND 25 OPTIONAL FIELDS ( DEPRECATED AND OMITTED FIELDS ARE EXCLUDED ). Section

Field

R/O

Document Creation

SPDX Version Data License SPDX Identifier Document Name SPDX Document Namespace License List Version Creator Created

R R R R R O R R

Package

Package Name Package SPDX Identifier Package Version Package File Name Package Supplier Package Originator Package Download Location Files Analyzed Package Checksum Package Home Page Source Information Concluded License Declared License Copyright Text External Reference Package Attribution Text Primary Package Purpose Release Date Built Date Valid Until Date

R R O O O O R O O O O O O O O O O O O O

File

File Name File SPDX Identifier File Type File Checksum Concluded License License Information in File Copyright Text File Contributor File Attribution Text

R R O R O O O O O

Relationship

Relationship Relationship Comment

R O

B. SBOM Merging Existing approaches to improving SBOM completeness include merging multiple SBOMs. We distinguish two strategies based on how they treat entries that describe the same package or file. Concatenation-based merging. Most existing tools, such as CycloneDX CLI5 , SPDXMerge6 , and sbommerge7 , concatenate the entries of input SBOMs section by section (Packages, Files, Relationships, etc.) without checking whether two entries describe the same package or file. Consequently, the same component appears as duplicate entries, missing fields in one entry are not filled in from another entry of the same component, and cross-section references (e.g., a Relationship pointing to a Package by its SPDX ID) still point to the premerge entries instead of the merged ones. Complementation-based merging. An alternative strategy is to identify, across input SBOMs, entries that describe the same package or file, and to complement missing or NOASSERTION values (which indicate that no claim is made in SPDX) in one entry using the corresponding entry in another. FatBOM8 invokes multiple SBOM generators and merges results based on package identification by name and version; however, it neither performs perfield complementation—filling missing field values from peer records—nor preserves original cross-section references such as Relationships, instead regenerating them uniformly. Furthermore, FatBOM does not support PURL-based identification, which limits its ability to align packages across tools with heterogeneous naming conventions. To our knowledge, no existing tool combines PURL-based entry identification, perfield complementation, and reconstruction of cross-section references into a single workflow. These limitations motivate our approach, which we describe in the following section. 4 https://docs.github.com/en/code-security/supplychain-security/understanding-your-software-supplychain/about-the-dependency-graph 5 https://github.com/CycloneDX/cyclonedx-cli 6 https://github.com/philips-software/SPDXMerge 7 https://github.com/anthonyharrison/sbommerge 8 https://github.com/VexStore/fatbom

III. SBOM F IELDS AND E VALUATION S COPE An SBOM defined in SPDX consists of multiple fields that describe software components and their associated metadata. We assign each field to one of the following attributes based on the SPDX specification, with additional criteria for Omitted fields. Required: Fields that must be present. Optional: Fields that may be included but not mandatory. • Deprecated: Fields that are no longer recommended for use. • Omitted: Fields that are not commonly used in practice and are therefore excluded from the evaluation. • •

The deprecated fields correspond to those explicitly marked as deprecated in SPDX 2.3 specification. The omitted fields include (i) optional SBOM sections that are not typically generated by existing tools (e.g., Snippet Information, Other Licensing Information, and Annotation Information), and (ii) fields that require manual input or external curation, such as comment and attribution-related fields. In this study, we evaluate only the fields categorized as required or optional. This results in a total of 39 evaluated fields, consisting of 14 required fields and 25 optional fields. The complete list of evaluated fields, grouped by SPDX section and annotated with their requirement status, is presented in Table I.

sbom-unifier input Target GitHub Repository URL

Generation Engine (R1) Repository cloning

Enrichment Engine (R4) File inspection File type / File license enrichment

Merging Engine (R1, R3) PURL alignment Field-level integration Priority-based conflict resolution

Evaluation Engine (R2) Completeness metrics full / part / miss Optional input

output

Unified SBOM

File license info Target Repository

SBOM

SBOM Microsoft SBOM Tool

Syft

SBOM

SBOM Trivy

GitHub Dependency Graph (via REST API)

Ninka License Detector

Custom SBOM (Optional )

External Tools / Services

Fig. 1. System overview of sbom-unifier.

Based on these definitions, we consider two evaluation scopes: • Required Scope: fields categorized as required • Required+Optional Scope: fields categorized as required or optional These definitions are used consistently in the evaluation described in Section VI-C. IV. D ESIGN P RINCIPLES AND R EQUIREMENTS sbom-unifier is designed to support configurable and reproducible SBOM integration workflows targeting the fields defined in Section III. The framework is based on four principles: component alignment, field complementarity, deterministic resolution, and measurable completeness. Based on these principles, sbom-unifier satisfies the following requirements. R1: Complementation-based merging across heterogeneous SBOMs. The framework identifies components across SBOMs using a common identifier (PURL) and complements missing field values from peer records, in contrast to concatenation-based merging that performs only a structural union without record identification. R2: Inspection and comparison of field-level completeness. The framework measures field-level completeness and enables comparison between individual tools and the unified SBOM. R3: Reproducible and configurable conflict handling. The framework resolves conflicting field values using a deterministic priority strategy. R4: SBOM enrichment via lightweight file inspection. The framework enriches missing fields through lightweight file inspection and external tools. V. A RCHITECTURE OF SBOM - UNIFIER sbom-unifier takes a target repository URL and generates a unified SBOM together with a field-level completeness evaluation. As shown in Fig. 1, the framework consists of four components corresponding to R1–R4. A typical workflow starts by selecting a target repository, SBOM generation tools, and merge settings, and ends with the generation of a unified SBOM together with a field-level completeness summary.

Fig. 2. Input interface for configuring sbom-unifier.

The Generation Engine (R1) collects SBOMs from external tools, including Microsoft SBOM Tool, Syft, Trivy, and GitHub Dependency Graph, while also accepting externally generated SBOMs as optional inputs. The input configuration is specified through the interface shown in Fig. 2, where users select target repositories, choose SBOM generation tools, and configure merge priorities. The Merging Engine (R1, R3) performs complementationbased merging by aligning packages using Package URL (PURL) and files using file paths. Missing or NOASSERTION values are complemented using peer SBOM records describing the same component. PURL was selected because it provides ecosystem-independent package identification across heterogeneous SBOM generators. Entries without a PURL are excluded

Fig. 4. Field-level coverage in the Required Scope (14 fields), averaged over 90 projects across 9 programming languages (10 projects per language). The proposed method is highlighted in red.

Fig. 3. Result interface showing field-level completeness.

from this alignment, and unmatched entries are retained as distinct packages. The Enrichment Engine (R4) complements fields that cannot be recovered through cross-tool complementation alone. In particular, it enriches file-related metadata such as file types and license information using lightweight file inspection and the external tool Ninka [11]. The Evaluation Engine (R2) summarizes field-level completeness, enabling users to assess the effects of integration and enrichment. The resulting completeness statistics and unified SBOM are presented through the interface shown in Fig. 3. VI. E VALUATION A. Evaluation Setup The objective of this evaluation is to quantitatively assess how sbom-unifier improves field-level completeness of source SBOMs. Throughout this evaluation, we report field-level coverage, defined as the proportion of evaluated SPDX fields populated within their corresponding records, classified into full, part, and miss categories (described in VI-B). To ensure a fair comparison, we use the same set of SBOM generation tools (Microsoft SBOM Tool, GitHub Dependency Graph, Syft, and Trivy) and compare their individual outputs with the SBOM produced by sbom-unifier, which merges and enriches these outputs. We conduct the evaluation following the architecture described in Section V. The process is as follows: 1) A target repository is cloned from GitHub. 2) sbom-unifier is executed, which internally invokes multiple SBOM generation tools, merges their outputs by complementation, and enriches missing fields. 3) Field-level coverage (described also in VI-B) is computed for both the individual tool outputs and the unified SBOM, and the results are compared under identical conditions. For reproducibility, the merge order is fixed during the evaluation. The output of Microsoft SBOM Tool is used as

Fig. 5. Field-level coverage in the Required+Optional Scope (39 fields), averaged over 90 projects across 9 programming languages (10 projects per language). The proposed method is highlighted in red.

the base SBOM, and Dependency Graph, Syft, and Trivy are applied as sources in this order, followed by the output of the Enrichment Engine. The target repositories consist of 90 public GitHub projects, with 10 highly starred ones selected from each of 9 programming languages (C#, Go, Java, JavaScript, PHP, Python, Ruby, Rust, and Swift) and at least 95% language purity. We evaluate two scopes, Required Scope and Required+Optional Scope. B. Evaluation Criteria Each field is classified into one of three categories: • full: generated for all target projects • part: generated for at least one but not all target projects • miss: not generated for any target project The coverage is computed as the proportion of these categories over all evaluated fields. C. Evaluation Results Fig. 4 and Fig. 5 present the field-level coverage for the Required Scope and the Required+Optional Scope, respectively. In both figures, full indicates that all projects populated the field, part indicates some, and miss indicates none. In the Required Scope, the upper bound on field-level completeness is already attained by the strongest individual tools: sbom-unifier, Microsoft SBOM Tool, and Syft all reach 93% full, while Dependency Graph and Trivy retain a 21% miss rate. Although the full rate remains identical to the strongest individual tools, sbom-unifier further reduces missing fields by complementing them as partially populated fields (turning red into orange in Fig. 4).

In the Required+Optional Scope, sbom-unifier attains 50% full and 29% miss, outperforming the best individual tools (42% full with Microsoft SBOM Tool; 40% miss with Syft), while Trivy and Dependency Graph leave 59–61% of fields missing. These results indicate that complementation-based merging and file-level enrichment recover information that no single tool can provide. This result is consistent across the nine languages, with per-language full rates ranging from 48.7% to 51.3% (standard deviation: 0.8 percentage points). D. Discussion The two scopes expose complementary aspects of sbomunifier’s behavior. In the Required Scope, sbom-unifier preserves the completeness level of the strongest individual tools without degradation. In the Required+Optional Scope, the improvement over the best individual tool (50% vs. 42% full) confirms that the gains reflect genuine complementation across heterogeneous tools and file-level enrichment, not mere redistribution of existing information. Some fields remain missing because they essentially require external metadata or manual curation. Addressing these fields would require integration with additional data sources such as package registries or curated datasets. E. Limitations The correctness of the generated SBOMs largely depends on the outputs of the underlying SBOM generation tools. While sbom-unifier improves field-level completeness, it does not verify or correct the values provided by the underlying tools. Since an incorrect value can be more harmful than a missing one for downstream tasks, assessing and improving the correctness of field values is an important future direction of this work. The generated SBOM quality could be further improved by incorporating deeper analysis of the target software, such as source-code inspection, or by leveraging external information sources (e.g., web-based metadata). However, such mechanisms are beyond the scope of the current implementation. Another limitation is that the current implementation supports only SPDX 2.3 because, at the time of writing, it is the only format common to all of the integrated generation tools. Although the proposed approach is not specific to this format, extending the system to support newer standards such as SPDX 3.0 and other formats like CycloneDX remains future work. VII. C ONCLUSION We presented sbom-unifier, a tool that improves the completeness of source SBOMs through complementation-based merging and file-level enrichment. Unlike concatenation-based merging, sbom-unifier identifies components by PURL, complements missing or NOASSERTION field values from peer records, and reconstructs cross-section references to preserve document consistency. Through an empirical evaluation on 90 open-source projects, we showed that sbom-unifier improves field-level completeness compared to individual SBOM generation tools. In par-

ticular, the system preserves high completeness for required fields while reducing missing values across optional fields. This work suggests that improving SBOM quality should be treated not merely as document aggregation, but as a structured software metadata integration problem. The current architecture separates alignment and conflict-handling policies, enabling future integration of more advanced conflict-resolution strategies, including semantic or AI-based approaches. Artifact Availability: sbom-unifier is published as open source under the MIT License at https://github.com/MoriwakiYusuke/sbom-unifier, associated with the replication package at https: //github.com/MoriwakiYusuke/sbom-unifier-replication. A pre-built image is distributed on Docker Hub as yusukemoriwaki/sbom-unifier:latest. Acknowledgment: This work is partially supported by JSPS JP23K28065, JP24K02923, JP24K14895, and JST JPMJCR25U7. We thank Yusaku Kato and the anonymous reviewers for their valuable feedback. Claude Code assisted parts of the implementation, and Claude and ChatGPT were used for English translation and proofreading. All content was validated by the authors. R EFERENCES [1] Black Duck Software, “2026 Open Source Security and Risk Analysis Report,” 2026. [Online]. Available: https://www.blackduck. com/resources [2] National Telecommunications and Information Administration, “The Minimum Elements for a Software Bill of Materials (SBOM),” 2021. [Online]. Available: https://www.ntia.gov/SBOM [3] Linux Foundation, “Spdx (software package data exchange): The software supply chain specification.” [Online]. Available: https: //spdx.dev/ [4] C. Wang, J. Wu, H. Lyu, X. Ling, T. Luo, Y. Wu, and C. Zhao, “A large scale empirical analysis on the adherence gap between standards and tools in sbom,” ACM TOSEM, Jan. 2026. [Online]. Available: http://dx.doi.org/10.1145/3788692 [5] Cybersecurity and Infrastructure Security Agency (CISA), “Types of Software Bill of Materials (SBOM),” https://www.cisa.gov/ resources-tools/resources/types-software-bill-materials-sbom, 2023. [6] M. Mirakhorli, D. Garcia, S. Dillon, K. Laporte, M. Morrison, H. Lu, V. Koscinski, and C. Enoch, “A landscape study of open source and proprietary tools for software bill of materials (sbom),” 2024. [Online]. Available: https://arxiv.org/abs/2402.11151 [7] A. R. M. Muneza, A. Keefe, E. O’Donoghue, C. Izurieta, and A. M. Reinhold, “SBOM Generation Tools and Formats Affect Compliance with US Standard,” in 2025 IEEE International Conference on Software Analysis, Evolution and Reengineering Companion (SANER-C), Montreal, QC, Canada, 2025, pp. 81–88. [8] A. Halbritter and D. Merli, “Accuracy evaluation of sbom tools for web applications and system-level software,” in 19th International Conference on Availability, Reliability and Security, ser. ARES ’24, 2024, pp. 1–9. [Online]. Available: https://doi.org/10.1145/3664476. 3670926 [9] S. Yu, W. Song, X. Hu, and H. Yin, “On the correctness of metadatabased sbom generation: A differential analysis approach,” in 2024 54th Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN), 2024, pp. 29–36. [10] E. O’Donoghue, B. Boles, C. Izurieta, and A. M. Reinhold, “Impacts of software bill of materials (sbom) generation on vulnerability detection,” in 2024 Workshop on Software Supply Chain Offensive Research and Ecosystem Defenses (SCORED), 2024, p. 67–76. [Online]. Available: https://doi.org/10.1145/3689944.3696164 [11] D. M. Germán, Y. Manabe, and K. Inoue, “A sentence-matching method for automatic license identification of source code files,” in ASE10 Proceedings of the IEEE/ACM International Conference on Automated Software Engineering, 2010, pp. 437–446.

Related documents

• SpliTEE: Fast and Private LLM Inference by Coupling GPU-Assisted Trusted Execution Environments with Differential Privacy#1117564
• SpliTEE: Improving LLM Inference on Trusted Hardware with Differentially Private GPU Outsourcing#1084933
• Hardware-Aware Features for CUTLASS Kernel Selection#1130242
• Hardware-Aware Features for CUTLASS Kernel Selection#1108775
• Hidden Dependencies and Component Variants in SBOM-Based Software Composition Analysis#126591