Papers1 provider Β· 2 records
July 15, 2026Β· Zenodo (CERN European Organization for Nuclear Research)
article
Open access

VeriSBOM Artifact

Authors:VeriSBOM *

Abstract

# VeriSBOM: Secure and Verifiable SBOM Sharing Via Zero-Knowledge Proofs **VeriSBOM**, a trustless, selectively disclosed SBOM framework that provides cryptographic verifiability of SBOMs using zero-knowledge proofs. Within VeriSBOM, third parties can validate specific statements about a delivered software, mainly regarding the authenticity of the dependencies and policy compliance, without inspecting the content of an SBOM. Respectively, VeriSBOM allows independent third parties to verify if a software contains authentic dependencies distributed by official package managers and that the same dependencies satisfy rigorous policy constraints such as the absence of vulnerable dependencies or the adherence with specific licenses models. ## Key Features * **Selective Disclosure (Hiding):** Choose which proprietary components to hide from the public SBOM. The system generates a cryptographic proof that replaces the plaintext data, guaranteeing privacy. * **High-Performance Folding:** Powered by **Nova-Scotia**, utilizing recursive SNARKs to handle SBOMs. * **Interactive Dashboard:** A complete 4-step workflow (Package Manager, Auditor, Vendor, Client) built with **Streamlit**. ## Repository structure The repository contains three main folders: 1. **Empirical**: contains **Benchmarking** and **src**, for the analysis and source code, respectively. 2. **User study**: contains the code and results of the user study. 3. **README_Doc**: contains the images used for this documentation. ## VeriSBOM Architecture The system is divided into four main roles: 1. **Package Manager**: Maintains the package repository with the allowed packages. 2. **Auditor:** Represents the regulatory body marking the compliance status by checking the packages of the package manager. 3. **Software Vendor:** Represents the entity that provides software artefacts and wants to hide the related SBOMs for privacy reasons. He is responsible for the generation of the cryptographic proofs as verifiable substitutes of the hidden packages in SBOMs. 4. **Client:** The end-user who receives the cryptographic proofs along with the software artefact for verifying binding, inclusion and compliance status. ## Web Access (Recommended) **For direct access to the artefact, VeriSBOM can be accessed at this public link** https://verisbom-verisbom-software.hf.space ## Setup & Installation Follow the README within the artefact ## Operational Workflow The application follows a **linear workflow** composed of four steps. Each step depends on the output generated in the previous one. > **Performance Note** Due to the cryptographic operations involved, generating proofs may take some time depending on the number and complexity of the active policy constraints. In the current reference environment, proof generation takes approximately **~5 seconds**, while verification takes around **~3 seconds per proof**. ## Step 1 β€” Package Manager In this step, the **Package Manager initialises the package repository**. ### Instructions 1. Open the **Package Manager** tab. 2. Click **`Load repository`**. > For convenience, the system automatically loads a **default repository containing packages from the NPM ecosystem**. ### Expected Output After successful execution: - A **green confirmation message** is displayed. - The **package list** appears on the left panel. - The **dependencies of each package** can be inspected on the right panel using the search bar. - A **dependency graph** is displayed at the bottom of the interface. ## Step 2 β€” Auditor In this step, the **Auditor defines policy constraints** that will be applied to the packages in the repository. ### Instructions 1. Enter a **policy name** (e.g., `Vulnerabilities`, `MIT License`). 2. Click **`Add`** to create the policy constraint. 3. Use the **search bar** to locate target packages. 4. **Uncheck packages** to mark them as **non-compliant**. > By default, **all packages are marked as compliant**. 5. Click **`Save and Propagate`** to apply the policy. ### Optional - Repeat the previous steps to create additional policy constraints. - Remove policies that are no longer required. ### Expected Output - A **green confirmation message** appears. - A **dependency graph visualisation** shows how non-compliance propagates across dependencies for the selected policy (or combination of policies). ## Step 3 β€” Software Vendor In this step, the **Software Vendor generates cryptographic proofs for a given SBOM**. ### Instructions 1. Upload a **local SBOM file**. > For demonstration purposes, the system automatically loads an **example SBOM**. 2. In the **Selective Disclosure** section: - Select which SBOM packages should be used for proof generation. 3. Click **`Generate Proofs`**. 3. Click **`Download`**. - Download the SBOM with hidden components and plaintext components ### Expected Output - A **progress bar** indicates the proof generation process. - **Green confirmation messages** appear once proofs are generated successfully. > **Important:** Successful proof generation only means that the **cryptographic proof has been constructed correctly**. Compliance with policies is verified only in **Step 4**. ## Step 4 β€” Client In the final step, the **Client verifies the proofs generated by the vendor**. ### Instructions 1. Upload the **SBOM**. 2. Select a **policy** from the dropdown menu. 3. Click **`Verify`**. ### Expected Output - **Verified (green badge)** The SBOM satisfies the selected policy. - **Failed (red badge)** The verification failed, and the interface displays the reason for the failure.

Community

0 comments
Use Connect Wallet in the navigation

No discussion yet

Be the first to share a question or observation.