A Hyperledger Fabric-Based SBOM Management System for Secure Software Supply Chain Integrity

Abstract

Recently, there has been an increasing prevalence of software supply chain attacks on software component suppliers. These attacks have targeted suppliers with relatively weak security or they have exploited vulnerabilities in open-source software. The software bill of materials (SBOM) has gained significant attention as a mechanism for improving software supply chain transparency and traceability. In this study, we propose an SBOM distribution architecture based on Hyperledger Fabric, which is a permissioned blockchain platform, to facilitate secure SBOM management. This approach utilizes Hyperledger Fabric private data collections (PDCs) to separate SBOM metadata from sensitive component information, thereby enabling confidential data sharing while reducing the blockchain storage overhead compared to a fully on-chain approach. The proposed PDC-based architecture achieves lower latency and higher throughput than the fully on-chain approach under the evaluated workload conditions, while supporting integrity verification and controlled sharing of sensitive component data.

1. Introduction

In recent years, software supply chain attacks have emerged as a critical cybersecurity threat, exploiting the increasing complexity and interdependence of modern software ecosystems. As modern software systems rely increasingly on third-party libraries, open-source components, and external dependencies, vulnerabilities introduced at any stage of the supply chain can propagate rapidly across downstream systems. Recent studies have demonstrated that these ecosystems are highly interconnected, increasing the risk of widespread vulnerability propagation [1].

To address these challenges, the software bill of materials (SBOM) was introduced to improve software transparency and security. An SBOM provides a structured inventory of software components, enabling organizations to identify vulnerabilities, manage risks, and respond effectively to security incidents. The importance of an SBOM has been further emphasized by government regulations and security guidelines, including the secure software development framework of the US National Institute of Standards and Technology (NIST) [2] and Executive Order 14028 [3], which highlight the need for improved visibility and integrity in software supply chains.

Despite its advantages, conventional SBOM management systems typically rely on centralized architectures, where SBOM data are stored and distributed through a single server. This centralized model introduces a critical security risk, as the server itself can become a target of supply chain attacks. In such scenarios, both the software and its corresponding SBOM data may be simultaneously compromised, undermining the reliability of SBOM-based verification mechanisms.

To mitigate these limitations, blockchain technology has been explored as a promising solution for decentralized SBOM management, enabling the detection of any tampering attempts. By leveraging distributed ledger technology, blockchain technology enables immutable recording of SBOM data, improving integrity and traceability without relying on a single trusted authority. However, existing approaches primarily focus on integrity and transparency while providing limited support for confidentiality and controlled data sharing.

In this study, we propose a secure SBOM management system based on Hyperledger Fabric, a permissioned blockchain platform that supports fine-grained access control. By utilizing private data collection (PDC), the proposed system enables selective sharing of sensitive SBOM data among authorized participants while preserving confidentiality. At the same time, the integrity of the data is maintained through hash-based verification recorded on the distributed ledger.

The main contributions of this study are as follows. First, we analyze the limitations of existing centralized SBOM management systems. Second, we design a blockchain-based SBOM management architecture that supports integrity verification and controlled sharing of sensitive SBOM component data. Third, we implement the proposed system using Hyperledger Fabric and evaluate its performance under different SBOM data management strategies.

Through this study, we demonstrate the feasibility of a Hyperledger Fabric-based SBOM management framework designed to support integrity- and confidentiality-aware SBOM distribution in modern software supply chains.

The remainder of this paper is organized as follows. Section 2 reviews background concepts and related work, including software supply chain attacks, SBOM, and blockchain-based approaches. Section 3 presents the proposed SBOM management system based on Hyperledger Fabric. Section 4 describes implementation and performance evaluation. Finally, Section 5 concludes the paper and discusses the scope for future studies.

2. Related Work

This section introduces software supply chain attacks, SBOM, Hyperledger Fabric, and related research as background concepts, and establishes the threat model and security goals for the proposed system.

2.1. Software Supply Chain Attacks

Software supply chain attacks modify software components during development, testing, distribution, or operations, introducing vulnerabilities or malicious code into final products [4]. As software modernizes, development ecosystems rely heavily on specialized outsourcing and open-source software, significantly widening the security threat propagation opportunities [4]. Software component suppliers often exhibit weaker security postures compared to consumer-facing enterprises, making their update servers prime targets for attackers.

There have been several prominent historical incidents that illustrate the critical nature of these risks.

2.1.1. SolarWinds Attack (2020) [5]

Attackers compromised an update server to inject a backdoor, causing widespread damage across downstream federal organizations and global enterprises. This demonstrates how modern software ecosystems are highly interconnected, allowing threats to cascade rapidly [1,5].

2.1.2. Log4Shell Vulnerability (2021) [6]

Exploiting a zero-day vulnerability in the open-source Log4j library, this attack targeted servers globally. A major risk was that organizations lacked visibility into whether their software contained Log4j, hindering timely remediation.

2.1.3. 3CX Attack (2023) [7]

Chained supply chain attacks targeting specialized communication applications further confirm that organizations remain highly vulnerable to domestic and international supply chain threats, necessitating systematic, proactive response frameworks.

2.2. SBOM

An SBOM is a formal record that lists all components included in a software system. Figure 1 illustrates the conceptual structure of an SBOM, which consists of metadata, software components, dependencies, and security information. The structure is derived from the SBOM guidance and minimum elements defined by NTIA and CISA [8,9]. An SBOM provides several advantages across the software lifecycle, including development, procurement, and operation. It allows organizations to identify security vulnerabilities in open-source software and other components and to respond more rapidly when new vulnerabilities are discovered [5]. The conceptual structure shown in Figure 1 is compatible with common SBOM standards such as SPDX and CycloneDX, which provide standardized representations for component metadata, dependencies, licenses, and vulnerability information.

Case studies comparing time-to-remediation with and without an SBOM [10] have shown that vulnerabilities can be addressed more efficiently when an SBOM is available, as it enables simultaneous mitigation actions across multiple stages of the software supply chain.

From a security perspective, SBOMs play a critical role in vulnerability management and risk assessment. By providing visibility into software components, they enable organizations to quickly determine whether they are affected by newly disclosed vulnerabilities. This capability significantly reduces the time required for impact analysis and remediation in the event of security incidents.

Furthermore, SBOMs enhance software transparency and enable effective vulnerability management by providing visibility of software components and dependencies. Their importance has been emphasized in recent industry guidelines and threat landscape reports, highlighting the growing risks associated with software supply chain attacks [10,11,12].

Owing to these advantages, many countries have begun adopting SBOMs as a key mechanism for software supply chain security. For example, the United States has mandated the submission of SBOMs for software supplied to federal agencies based on the minimum elements defined by the National Telecommunications and Information Administration. Similarly, the European Union and Japan are promoting the adoption of SBOMs through regulatory frameworks and pilot programs. In South Korea, software supply chain security guidelines have also been introduced to encourage SBOM-based management.

In addition, international standards organizations have defined essential elements for SBOM implementation, including data fields, automation support, and operational processes [9]. Security frameworks such as the NIST Secure Software Development Framework further emphasize the integration of security practices throughout the software development lifecycle to reduce vulnerabilities and strengthen supply chain security [2].

Despite these benefits, conventional SBOM management approaches typically rely on centralized systems for storing and distributing SBOM data. This introduces potential security risks because a compromised central server may result in simultaneous tampering of both the software and its corresponding SBOM. Therefore, supporting the integrity and integrity-aware distribution of SBOMs remains a critical challenge in modern software supply chain security management.

2.3. Hyperledger Fabric

Hyperledger Fabric is an open-source permissioned distributed ledger technology platform designed for enterprise environments and hosted by the LF decentralized trust of the Linux Foundation. It features a modular architecture that separates transaction execution, ordering, and validation phases, enabling scalability and flexibility [13].

Hyperledger Fabric maintains a distributed ledger across participating nodes without centralized control. The ledger comprises two main components: (1) the World State, which represents the latest state of the ledger and is stored in a key-value database, such as LevelDB or CouchDB, and (2) the blockchain, which records all changes to the World State as an immutable transaction log. Because transactions are organized into blocks and cannot be altered, the system supports the integrity and traceability of the transaction history.

Chaincode, which defines the smart contract logic in Hyperledger Fabric, supports general-purpose programming languages such as Go, Java, and Node.js, providing high development flexibility. Through the chaincode, external applications can query or update the World State, enabling customized management for enterprise environments.

Unlike public blockchains such as Bitcoin and Ethereum, where all transactions are executed and visible to every node, Hyperledger Fabric enhances confidentiality through channel and PDC mechanisms. Channels allow a subset of participants to maintain a separate ledger, while PDC enables selective data sharing by storing sensitive data in a private database accessible only to authorized organizations. In this model, private data are transmitted peer-to-peer among authorized participants, while only its hash value is recorded on the shared ledger to ensure integrity.

Network participants are authenticated through certificates issued by a certificate authority (CA), and transaction signatures guarantee that operations are approved by authorized organizations. This identity management mechanism strengthens trust within the network.

Figure 2 shows three participating nodes (Peer0, Peer1, and Peer2) in the Hyperledger Fabric blockchain network, the organizations (Org1, Org2, and Org3) to which each node belongs, and the structure of the ledger. It illustrates differences in ledger visibility according to PDC access permissions. In this example, Peer0 (Org1) and Peer1 (Org2), which are included in the private data collection policy, can access both the Channel State and the Private State. In contrast, Peer2 (Org3), which is not included in the collection policy, can access only the hash values recorded in the Channel State and cannot access the corresponding private data. Therefore, peers can verify ledger information only within the scope permitted by the channel policy and PDC access rights.

Furthermore, prior studies have analyzed the performance characteristics of Hyperledger Fabric and identified key bottlenecks affecting throughput and latency, proposing optimization strategies to improve system efficiency [14]. In addition, system-level optimizations have demonstrated that Hyperledger Fabric can achieve high scalability and significantly improve transaction throughput under optimized configurations [15].

Figure 2. Conceptual diagram illustrating ledger visibility differences between authorized and unauthorized peers under PDC access permissions, adapted from the Hyperledger Fabric documentation [16].

Figure 2. Conceptual diagram illustrating ledger visibility differences between authorized and unauthorized peers under PDC access permissions, adapted from the Hyperledger Fabric documentation [16].

2.4. Related Research

As discussed above, the use of SBOMs to respond to software supply chain attacks has several advantages. However, storing and providing an SBOM in a centralized client-server structure can make it an attractive attack target. In such cases, both the SBOM data and software may be simultaneously tampered with, reducing the reliability of SBOM-based approaches. Therefore, ensuring the integrity of SBOM while enabling secure distribution is a critical challenge.

Currently, hash-based verification techniques are widely used to ensure SBOM integrity [10]. In these approaches, the supplier provides both the software and its hash value, and users verify integrity by recomputing the hash. However, because both are distributed through the same server, this method remains vulnerable to server-side attacks, where both the software and hash value can be compromised.

To address these limitations, recent studies have explored blockchain-based approaches for secure software supply chain management [6]. As demonstrated in broader supply chain contexts, blockchain systems can provide tamper-resistant and transparent records of system data, thereby improving trust and traceability [17]—qualities that are equally important for managing software artifacts. In addition, research on blockchain-based data provenance has demonstrated that decentralized ledgers and smart contracts can securely record data origin and history, thereby enabling reliable dependency tracking [18]. Furthermore, integrity verification frameworks, such as in-toto, distribute trust across multiple entities, eliminating reliance on a single trusted authority [19]. Recent studies have also explored advanced AI-based security analysis and interpretable intrusion-detection frameworks for improving software and network security management in complex distributed environments [20].

These approaches, including prior SBOM-focused blockchain systems [21], primarily concentrate on ensuring data integrity and traceability. However, they provide limited support for confidentiality and fine-grained access control in SBOM sharing.

The confidentiality assessment of BC-SBOM is based on the architecture described in [22]. In that framework, SBOM data are stored entirely on-chain without a dedicated private data isolation mechanism, such as Hyperledger Fabric’s Private Data Collection (PDC) [16]. Consequently, while this architecture effectively supports integrity and traceability, its capability to restrict access to sensitive SBOM component information is relatively limited.

This limitation highlights the need for a system that can support integrity verification and confidentiality-aware data sharing in SBOM management.

Table 1. Comparison of BC-SBOM (2025) and the proposed system.

Feature	BC-SBOM (2025)	Proposed System
Blockchain Type	Permissioned	Permissioned
Storage Structure	Fully on-chain	Hybrid (On-chain + PDC)
Confidentiality Support	Limited	PDC-based selective sharing
Access Control	Basic	MSP + Collection Policy
Integrity Verification	Hash-based	Hash-based
Scalability	Limited by full ledger size	Improved through data separation
Performance Optimization	Not discussed	Experimentally evaluated
Private Component Protection	Not explicitly supported	Supported

Note: Membership service provider (MSP); private data collection (PDC).

compares our proposed system with BC-SBOM (2025).

2.5. Threat Model and Security Goals

The proposed system assumes a permissioned blockchain environment in which participating organizations are authenticated through the membership service provider (MSP) of the Hyperledger Fabric. The CA is assumed to be trusted for issuing valid certificates to authorized participants.

The adversary is assumed to have the capability to compromise centralized servers, tamper with SBOM files, intercept network traffic, or attempt unauthorized access to software component information. However, it is assumed that the adversary cannot simultaneously compromise a majority of authenticated blockchain peers participating in the endorsement process.

The security goals of the proposed system are as follows:

• Integrity: Unauthorized modification of SBOM metadata or component data must be detectable through hash verification and immutable ledger records.
• Authenticity: Only authenticated organizations with valid MSP certificates should be able to upload or endorse SBOM transactions.
• Confidentiality: Sensitive software component information should only be accessible to organizations authorized through PDC policies.
• Traceability: All SBOM upload and modification events should remain permanently traceable through blockchain transaction records.

Based on these assumptions and security goals, the proposed system utilizes Hyperledger Fabric endorsement policies, immutable ledgers, and PDC mechanisms to reduce the risk of simultaneous tampering of software and SBOM data.

3. Hyperledger Fabric-Based SBOM Management System

This section presents a distribution network model that simultaneously supports integrity verification and confidentiality-aware data sharing of SBOMs by utilizing the PDC function of Hyperledger Fabric. As discussed in the previous section, the SBOM distribution method has a centralized structure; therefore, when a server attack occurs, there is a risk of simultaneous tampering of SBOM data and hash values. Accordingly, in this study, a permissioned blockchain-based network is applied so that multiple participating nodes jointly manage the ledger, thereby improving SBOM integrity assurance.

In addition, the system leverages the channel and PDC functions of Hyperledger Fabric to ensure that only authorized organizations can access specific SBOM data, thereby ensuring confidentiality. By using the PDC function, not all SBOM data are directly stored on-chain but are separately stored in a side database. This approach reduces blockchain storage overhead while preserving data verification capability.

Access control for the PDC is enforced through the MSP and collection configuration policies of Hyperledger Fabric. Only peers belonging to authorized organizations listed in the collection configuration file are permitted to store and query private SBOM component data.

In the implemented network, three private data collections were configured: a shared collection accessible to both Org1 and Org2, an Org1-specific private collection, and an Org2-specific private collection.

Unauthorized organizations can still verify the integrity and existence of the SBOM through the hash value recorded in the channel ledger, but they cannot access the actual component information stored in the private database. The proposed threat model assumes that authenticated organizations may behave maliciously on an individual basis; however, large-scale collusion among most endorsing peers is beyond the scope of the current study.

An example of the Hyperledger Fabric-based SBOM distribution network to be constructed is shown in Figure 3. In the Hyperledger Fabric network, peer nodes of Org1, Org2, and Org3, which represent three organizations, participate in a single channel. Each organization receives certificates through its own independent CA, which are used to identify the participants in the network.

Each peer possesses a ledger, and the ledger comprises a Channel State shared by all participating organizations in the channel and a Private State accessible only to specific organizations. The Private State is managed through PDC, and only authorized organizations can store and query detailed SBOM information. Meanwhile, the Orderer node responsible for block generation and transaction ordering, as well as the CA server for the Orderer, are omitted for visual clarity of the figure.

The process by which SBOM data are securely distributed and verified in the proposed Hyperledger Fabric-based network is shown in Figure 4. This figure illustrates an example data-sharing scenario in which, after a client of the software provider (Org1) uploads the SBOM, it is processed by Org2, which is included in the relevant private collection policy, while Org3 is excluded from the private collection policies. It is assumed that the peers of Org2 and Org3 have already received certificates from their respective certificate authorities (CAs) and joined the same channel.

• The client of the software provider (Org1) first obtains authorization by receiving a certificate from the CA of Org1 to access the network and then joins the channel.
• The client of Org1 invokes the chaincode to upload SBOM data by dividing it into Channel State and Private State.
• The Components data of the SBOM that require confidentiality are transmitted through a peer-to-peer mechanism only to peers authorized by the relevant private collection policy.
• The metadata of SBOM and the hash value of the Components data are included in the block and recorded in the channel ledger, and the block is shared with all peers (Org2, Org3) in the channel.
• The client of Org2 queries the Components data stored in the Private State through chaincode and verifies whether the data have been tampered with by comparing them with the hash value recorded in the Channel State.

Meanwhile, because the peer of Org3, which does not have access rights, cannot receive the Components data, it can only confirm that a specific SBOM has been registered in the network through the metadata and hash value recorded in the Channel State.

Through the proposed network structure and SBOM processing procedure, access-controlled confidentiality can be enforced through Hyperledger Fabric PDC policies, while SBOM data integrity can be verified using hash values recorded on the immutable ledger.

Read and write permissions for private SBOM component data are enforced through Hyperledger Fabric MSP authentication, endorsement policies, and collection configuration rules. Only organizations explicitly listed in the private collection policy are permitted to invoke chaincode functions that query or modify private SBOM component data.

Unauthorized organizations can access only public metadata and hash values recorded on the shared ledger. Access to private SBOM component data is restricted through MSP-based authentication and private collection policies, and the actual component contents are accessible only to authorized members of the corresponding private data collection.

This restricted-access configuration follows the principle of least privilege by limiting sensitive SBOM component visibility only to organizations that require access for software supply chain operations.

4. Experiment and Results

In this section, the network is implemented based on the model designed above in Section 3, and the performance characteristics of the proposed system are evaluated experimentally.

4.1. Experimental Environment Setup

An experiment was conducted to evaluate the performance characteristics of the Hyperledger Fabric-based SBOM distribution network. In addition, for simplification and reproducibility of the experiment, a verification environment was constructed based on a data-sharing scenario between Org1 (supplier) and Org2 (consumer). The experiment was conducted on Ubuntu 24.04.1 LTS of WSL2 (Windows Subsystem for Linux 2), which allows Linux to run on Windows, and all nodes were configured to run independently based on Docker containers.

The network infrastructure used the official binaries and Docker images provided by Hyperledger Fabric. Among the official binary files, the network was configured by adding detailed execution options suitable for this experiment to the shell script (network.sh). For this configuration, the following Hyperledger Fabric network execution command and parameters detailed in

Table 2. Detailed parameter options of Hyperledger Fabric network execution.

Parameter Option	Meaning of the Option
createChannel	Creates a channel named ‘mychannel’ and registers peers
-ca	Separate CA node is created to issue certificates to network participants like a real environment instead of pre-generated certificates
-s couchdb	Database of World State ledger set to CouchDB instead of LevelDB of key-value structure so that SBOM data in JSON format can be easily handled

were applied: “$ ./network.sh up createChannel -ca -s couchdb.”

Figure 5 shows the logs output during network execution and the state in which the containers are normally running through the Docker Desktop screen. Through this, it can be confirmed that the Orderer, Org1 and Org2 peer, and CouchDB nodes, which are state databases, are properly created and running in the Docker environment.

Hyperledger Caliper, which can test several different blockchain solutions, was used to measure the performance of the proposed network model. Among the different methods of installing Caliper, the CLI version 0.6.0 was installed using the Node Package Manager. To use Caliper, a binding step was required to specify the target platform and version of the platform Software Development Kit to be used. Therefore, considering the constructed network, all configurations for performance benchmarking were completed by performing binding with the Software Development Kit of Hyperledger Fabric version 2.2.

4.2. Chaincode Implementation

Chaincode was implemented to store the SBOM data separately on-chain and off-chain using the PDC function of Hyperledger Fabric. Java was used as the development language, with particular emphasis placed on separating the large component part of the SBOM structure, which requires confidentiality. In addition, components were configured together with serialNumber (an SBOM metadata field) so that the corresponding SBOM could be identified. Figure 6 illustrates the classes designed to store the SBOM data separately. The design distinguishes data intended for storage on the public ledger, which are encapsulated in the Sbom.java class, from the actual software component information, which is stored in the SbomPrivate.java class.

For reproducibility, the experimental SBOM dataset was constructed in JSON format based on the CycloneDX specification. The SBOM comprises metadata fields (serialNumber, supplier, version, timestamp, and hash value) and a Components field containing detailed software dependency information.

The Components field includes approximately 120 software components with attributes such as component name, version, supplier, hash, and dependency relationship. The complete SBOM JSON file is approximately 180 KB, while the separated metadata stored on-chain is approximately 12 KB.

To maintain consistent benchmarking conditions, the same SBOM structure and component composition were repeatedly used during the experiments. Only the serialNumber field was dynamically modified using timestamps to prevent duplicate transaction keys in Hyperledger Fabric.

To record SBOM on the network, the createAsset chaincode function was implemented, as shown in Figure 7.

The access permissions of the private collection were defined in the collection configuration file referenced by the cccg parameter during chaincode deployment. The policy specifies which organizations are authorized to endorse, store, and query the private SBOM data. As a result, only authorized peers satisfying the MSP policy can access the Components data, whereas non-authorized peers only receive the hash value recorded on the public ledger. The data storage logic is as follows. First, encrypted SBOM data are received through the key “sbom_property” of the transient field. Then, the data are mapped and assigned to each variable using functions of the JSONObject object. At this time, the hash value is calculated using the SHA-256 hash value for the entire JSON file data and assigned to the variable. After creating an SBOM object using the fields, excluding components, the object is serialized into JSON format and recorded in the Hyperledger Fabric public ledger. For the components part, an SbomPrivate object is separately created together with serialNumber and stored in a private data collection according to the configured collection policy. Access to each private collection is controlled through Membership Service Provider (MSP) authentication and collection-specific access policies. Consequently, authorized organizations can access only the private data collections for which they are explicitly granted permissions, while unauthorized organizations can access only the metadata and hash values recorded on the shared channel ledger.

To enable the use of the designed chaincode in the executed Hyperledger Fabric network, the chaincode was deployed using the command in Figure 8, and the detailed parameter options used together are listed in

Table 3. Detailed parameter options of the SBOM chaincode deployment command.

Parameter Option	Meaning of the Option
ccn	Name of the contract to be deployed
ccp	Path of the chaincode to be deployed
ccl	Programming language of the chaincode to be deployed
ccep	Endorsement policy required for consensus when recording data (In Figure 8, endorsement from one of the peers of Org1 or Org2 is required)
cccg	Location of the file containing information required to create the collection where data is stored
ccs	Sequence number of the chaincode
ccv	Version of the chaincode

. When the command was executed, the Java code was compiled and then installed on each peer node.

In addition to the SBOM chaincode, to compare performance, a basic chaincode of a fully on-chain approach that uploads all contents of the SBOM to the Hyperledger Fabric ledger without using the PDC function was also implemented. The confidentiality properties of the proposed architecture depend not only on the PDC mechanism itself but also on the correct MSP configuration, endorsement policies, certificate management, peer access control, and protection of the underlying private state database. Therefore, confidentiality should be interpreted as policy-enforced restricted sharing within a permissioned blockchain environment rather than absolute secrecy. This chaincode was configured so that all contents, including components, were included in the Sbom.java class without separating the Components part. Unlike the method of storing data by separating collections, createAsset was implemented so that all contents were recorded on-chain by storing them in the same collection.

4.3. Experimental Execution

For the PDC-based implementation, confidential component information was stored in a private data collection according to the configured collection policy, while metadata and hash values were recorded on the shared channel ledger.

Figure 9 shows a part of the config.yaml file that defines the detailed settings of the experiment. The rounds section was configured with two rounds so that two experiments with different transactions per second (TPS) values could be executed sequentially. In addition, txDuration was set to 30 so that the SBOM upload requests corresponding to the TPS were generated for 30 s, thereby performing a load test on the network. In the module section, the path of pCreateAsset.js, which contains the code that loads the SBOM and calls the createAsset function of the chaincode, was specified. Because the experiment repeatedly uses the same SBOM template for reproducible benchmarking, the current time was appended only to the serialNumber field to prevent duplicate transaction keys while maintaining an identical SBOM structure, component count, and data complexity across all experiments.

After completing all preparations, the experiment was conducted by running Hyperledger Caliper. After the two test rounds were completed, the JavaScript file in the module section of config.yaml was modified to test the case that does not use the PDC function. Figure 10 shows the log screen displaying the results after running Caliper and the dashboard of CouchDB showing the ledger of the Components part stored in it.

Figure 11 shows the result page generated through the Hyperledger Caliper experiment. This is the benchmark result screen of the PDC-based approach with TPS set to 10, where the brief benchmark configuration of config.yaml can be confirmed. Subsequently, metrics, such as name; number of successful and failed transactions; throughput; maximum, minimum, and average latency; and actual network performance indicators, are all recorded in a table.

4.4. Experimental Result Analysis

The Hyperledger Fabric network was comparatively analyzed based on the output after benchmarking through Hyperledger Caliper.

Figure 12a shows the benchmark result of the fully on-chain approach in which all SBOM contents are uploaded without using the PDC function, and Figure 12b shows the benchmark result of the PDC-based approach in which components and metadata are separated and stored both off-chain and on-chain together with the hash value using the PDC function. In both benchmarks, activities were performed to upload 10 and 30 SBOMs per second to the blockchain for 30 s, and the numbers of successful and failed transactions, configured TPS, latency, transaction success rate, and throughput were measured. Among these, transaction success rate, average latency, and throughput were compared, as summarized in

Table 4. Comparative benchmark results between the fully on-chain and PDC-based architectures.

Metric	Target TPS	Fully On-Chain	PDC-Based	Relative Improvement
Avg Latency	10	10.3 ± 1.0 s	0.90 ± 0.03 s	91.3% reduction
Avg Latency	30	39.3 ± 18.0 s	20.4 ± 3.7 s	48.1% reduction
Success Rate	30	33.6 ± 19.7%	100.0 ± 0.0%	66.4 percentage-point increase
Throughput	10	6.5 ± 0.2 TPS	9.3 ± 0.1 TPS	42.3% increase
Throughput	30	12.4 ± 3.4 TPS	13.2 ± 0.7 TPS	6.1% increase

. Minor performance variations between repeated runs are observed because of container scheduling and resource-sharing characteristics in the WSL2/Docker environment. Table 4 summarizes the average benchmark results obtained (mean ± standard deviation) from five repeated executions under identical experimental conditions. The results indicate that the proposed PDC-based architecture generally achieves lower latency and higher throughput than the fully on-chain configuration under these evaluated workload conditions.

The average latency was improved by 50–90% depending on the TPS workload, by using the PDC-based approach. Both architectures achieved stable transaction processing with 100% success rates under the 10 TPS workload. However, under the 30 TPS workload, the fully on-chain approach showed a sharply reduced success rate, whereas the PDC-based approach maintained 100%. This result indicates that the PDC-based architecture provides more stable transaction processing under high workload conditions. The throughput results suggest that separating sensitive component data into the PDC reduces the on-chain storage burden and helps maintain more stable performance under the evaluated workload conditions.

Although the PDC-based architecture achieved a 100% transaction success rate under the 30 TPS workload, the measured throughput remained lower than the submitted workload rate. This result indicates that all submitted transactions were eventually committed successfully, while the overall processing rate was constrained by endorsement, ordering, validation, and execution overhead in the Hyperledger Fabric network. Therefore, transaction success rate and throughput should be interpreted as complementary performance metrics.

The fully on-chain approach was selected as the primary comparison baseline because it directly represents the blockchain storage scalability problem addressed by the proposed architecture. Comparisons with centralized repositories, InterPlanetary File System-based hybrid architectures, and existing industrial SBOM platforms remain important future research directions.

This paper proposes a Hyperledger Fabric-based SBOM management framework that simultaneously supports integrity, authenticity, confidentiality, and traceability. The experimental results confirm that using the PDC mechanism improves network performance while preserving secure and verifiable SBOM distribution. From a security perspective, the proposed architecture reduces the risk of simultaneous tampering of software and SBOM data by separating integrity verification information from confidential component data. Because the hash value of the SBOM is immutably recorded on the shared ledger, unauthorized modification of private component data can be detected through integrity verification procedures.

In addition, direct access to sensitive component information is restricted by the PDC mechanism to authorized organizations defined by MSP and collection policies. Consequently, unauthorized peers can still verify the existence and integrity of the SBOM without accessing the actual component contents.

However, the current study does not include formal attack simulations or penetration testing against advanced adversarial scenarios. Therefore, the presented security properties should be interpreted as architecture-based security characteristics rather than formally proven guarantees.

This experiment has several limitations. First, it involved only two organizational peers in a local container environment. Second, the current evaluation primarily focused on the SBOM upload performance through the CreateAsset operation. Additional experiments involving query latency, integrity verification overhead, concurrent access handling, and inter-peer synchronization performance should be conducted in future studies.

In addition, future studies should evaluate more complex SBOM datasets with varying component counts and larger file sizes to further analyze scalability and access-control overhead in large-scale software supply chain environments.

The present evaluation focuses on the CreateAsset operation because SBOM registration and storage constitute the primary workload targeted by the proposed architecture. Additional evaluations involving query latency, integrity verification overhead, and synchronization performance remain important future research directions.

5. Conclusions

In this study, software supply chain attacks and SBOMs, which are a key element for responding to them, were examined, and a method using Hyperledger Fabric, a permissioned blockchain, was proposed to support the simultaneous integrity and confidentiality of SBOMs.

Although the proposed architecture leverages the security mechanisms of Hyperledger Fabric to improve integrity and confidentiality, this study did not conduct formal security proofs, penetration testing, or attack simulations against malicious adversaries. Future studies should therefore include rigorous security validation under realistic attack scenarios, including compromised peers, insider attacks, unauthorized access attempts, and distributed tampering attacks.

Furthermore, a network was constructed using the PDC function of Hyperledger Fabric, and comparative experiments with the fully on-chain approach were conducted. The PDC-based approach reduced average latency by 48.1% under a high workload of 30 TPS and improved the transaction success rate by 66.4% compared to the fully on-chain approach. These results show that the PDC-based approach provides more stable transaction processing and performance advantages under the evaluated workload conditions.

However, the conducted experiment has several limitations. First, it was performed with only two organizational peers in a local container environment. Second, the current evaluation primarily focused on SBOM upload performance through the CreateAsset operation. Additional experiments involving query latency, integrity verification overhead, concurrent access handling, and inter-peer synchronization performance should be conducted in future studies. Furthermore, future studies should evaluate query throughput, verification latency, concurrent transaction handling, and synchronization costs in larger multi-organization environments to further validate the scalability and practicality of the proposed system. Therefore, the current study should be interpreted as a prototype-oriented architectural and performance evaluation study rather than a production-scale deployment validation.

The security analysis presented in this paper is based on the architectural security mechanisms provided by Hyperledger Fabric. Formal security proofs, penetration testing, and adversarial evaluations remain important future research directions.