Practical Software Bill of Materials: From Generation to Distribution Workshop

Practical Software Bill of Materials: From Generation to Distribution Workshop

Speakers: Adula Garcia, Technical Lead (OpenSSF vex/protobom), Kubernetes Release Engineering; Mike, CTO (Cusari), Governing Board/TAC (OpenSSF), Maintainer (Guac/Salsa), Tech Lead (CNCF TAG Security); Ian, Governing Board (OpenSSF), TC54 (CycloneDX), Maintainer (bombl/sbomb-it)

Conference: VulnCon

YouTube: https://www.youtube.com/watch?v=hhq751ELIVw

Overview

In the rapidly evolving landscape of software supply chain security, the Software Bill of Materials (SBOM) has emerged as a critical artifact. However, merely generating an SBOM is no longer sufficient; its true value lies in its quality, trustworthiness, and actionable insights. This comprehensive workshop, presented by Adula Garcia, Mike, and Ian at VulnCon, delved into the entire lifecycle of practical SBOMs, moving beyond simple compliance to robust security and operational efficiency.

The speakers, all prominent figures in the OpenSSF, Kubernetes, and CNCF communities, brought a wealth of experience from maintaining key SBOM-related projects like Protobom, Guac, Salsa, Bombl, and Sbomb-it. Their collective expertise highlighted a community-driven effort to establish best practices and tooling for SBOM generation, enrichment, verification, signing, distribution, and, crucially, operationalization. The talk emphasized that a high-quality SBOM is not an end in itself, but a foundational element for informed decision-making in vulnerability management, license risk assessment, and overall supply chain transparency.

The core message of the workshop was a call to action for software producers and consumers alike: to elevate SBOM practices beyond a checkbox exercise. By adopting a structured approach—the "SBOM Producer Life Cycle"—and leveraging a suite of open-source tools, organizations can transform their SBOMs from static lists into dynamic, verifiable, and continuously actionable assets that significantly enhance their security posture.

Background

▶ Watch: Speakers Adula Garcia, Mike, and Lars Engebretsen introduce themselves. (0:00)

The pervasive problem in the SBOM ecosystem, as highlighted by the speakers, is the widespread generation of low-quality, incomplete SBOMs. Many organizations produce SBOMs solely to meet compliance mandates, often using basic scanning tools like Trivy or SIFT across their codebase. The resulting documents frequently lack essential metadata, containing placeholder information like "Acme Corporation" for vendor names or "no assertion" for copyright, rendering them practically useless for security analysis or legal compliance. This "generate and forget" mentality undermines the very purpose of an SBOM.

The context for this challenge is rooted in the increasing complexity of software supply chains and the escalating threat of attacks targeting these dependencies. Regulatory bodies and industry standards, such as the NTIA Minimum Elements for SBOMs, have attempted to define what constitutes a useful SBOM. However, generic generation tools often fail to meet these minimum requirements out of the box. The gap between what an SBOM should contain and what it actually contains creates a significant security blind spot.

To address this, the OpenSSF and its various working groups have been actively developing projects and frameworks. A key framework introduced in the talk is the SBOM Producer Life Cycle, originating from the System Tiger Teams. This lifecycle provides a structured, multi-stage approach to producing high-quality SBOMs: Augmentation, Enrichment, Verification, Signing, and Document Linking. This framework serves as the backbone for the practical steps demonstrated throughout the workshop, aiming to guide producers toward creating SBOMs that are not just compliant, but genuinely valuable for security and operational teams.

Key Findings

▶ Watch: Workshop agenda: SBOM generation, sharing, and operations. (3:10)

The workshop distilled several critical insights into the effective use of Software Bill of Materials, moving the conversation beyond mere existence to actionable utility.

Firstly, the paramount finding is that SBOM quality is non-negotiable. Simply generating an SBOM with basic tooling is insufficient; the focus must shift to producing high-quality, complete, and trustworthy SBOMs. An incomplete or inaccurate SBOM can be as detrimental as having none at all, as it provides a false sense of security or misleads consumers.

Secondly, the SBOM Producer Life Cycle is presented as an essential, structured methodology for achieving this quality. This lifecycle comprises five distinct phases:

1. Augmentation: Adding top-level metadata (e.g., author, supplier, overall license) that only the software producer inherently knows.
2. Enrichment: Populating missing, granular metadata for individual components (e.g., specific component licenses, documentation links, external references) that automated tools often miss.
3. Verification: Ensuring the SBOM adheres to its schema, is semantically complete, and is free from inconsistencies before distribution. This includes checks against quality metrics and structural integrity.
4. Signing: Cryptographically asserting the origin and integrity of the SBOM, guaranteeing that it has not been tampered with and comes from a verified source. This is where attestations play a crucial role.
5. Document Linking: While not extensively covered due to time, this phase addresses how multiple SBOMs can be linked to represent complex systems or nested dependencies.

Thirdly, the workshop highlighted that attestations are fundamental for establishing trust and transparency. Beyond simple digital signatures, attestations (such as those following the in-toto specification and leveraging SLSA principles) provide verifiable metadata about how an SBOM was generated, what build system produced it, what tests were run, or what vulnerability scans were performed. This rich, verifiable context significantly enhances the consumer's confidence in the SBOM's contents and provenance.

Finally, the talk underscored the importance of operationalizing SBOMs. The ultimate goal is to transition from a compliance-driven artifact to a continuously utilized asset for active vulnerability management, license risk analysis, and understanding dependency sprawl across an organization's software estate. Tools like Guac are presented as vital for achieving this at scale, allowing for dynamic querying and correlation of SBOM data with other supply chain intelligence. This shift transforms SBOMs into a living, actionable source of truth for software security.

Technical Deep Dive

▶ Watch: The problem: Why many generated SBOMs are incomplete. (4:45)

The workshop provided a hands-on, detailed exploration of the tools and processes involved in creating and leveraging high-quality SBOMs, structured around the SBOM Producer Life Cycle.

SBOM Generation

The initial step involves generating a foundational SBOM. While tools like Trivy and SIFT are commonly used, the speakers stressed the importance of selecting the right tool for the specific project's language and package manager. For instance, specialized tools might be necessary for C/C++ projects to achieve accurate results. A basic SBOM for kubectl was generated, which, as expected, lacked crucial top-level metadata like author, supplier, repository, license, and copyright.

Augmentation: Adding Top-Level Metadata

Purpose: Automated SBOM generators often can't infer the high-level metadata that defines the software product itself. Augmentation addresses this by allowing the producer to inject this vital information.

Tools & Techniques:

• sbom-as-in: An open-source tool from Interlinks, demonstrated for its ability to augment both SPDX and CycloneDX formats. In the demo, it was used twice: first to add document-level metadata (e.g., serial number, tool used, lifecycle phase), and then to update the top-level component with details like author, supplier, repository URL, and license information. This simple step significantly enhances the SBOM's utility for consumers, particularly for legal and security teams.
• jq: Historically, jq (a command-line JSON processor) has been used to merge static JSON files containing top-level metadata with generated SBOMs, especially for CycloneDX. However, sbom-as-in offers a more consistent and format-agnostic approach.

Enrichment: Populating Component-Level Metadata

Purpose: Beyond top-level data, individual components within an SBOM often lack detailed metadata required by standards like the NTIA minimum elements. Enrichment fills these gaps.

Tool: Sneak's Parlay was showcased for this task.

Data Source: parlay can query various databases, with the ecosystems database used in the demo. This database categorizes information for open-source components.

Impact: parlay enriched the kubectl SBOM by adding descriptions, licenses, external references (website, distribution, documentation), and project release/update dates to numerous components. This transforms a basic list of components into a rich dataset, enabling deeper analysis for vulnerability scanning and license compliance. The discussion also touched upon the trade-off between data completeness and potential "noise," concluding that more useful data is generally preferable, as it's easier to filter than to retroactively add.

Verification: Ensuring Quality and Structure

Purpose: Before distributing an SBOM, it's crucial to verify its adherence to schema, completeness, and semantic correctness.

Tools:

• sbomqs (Interlinks): This tool provides quality scores and measures for an SBOM. The demo showed a significant improvement in score after augmentation and enrichment, with the number of components having a defined supplier increasing from 0 to over 2000 out of approximately 4000. It also flags issues like deprecated licenses.
• protobom (OpenSSF): Described as an I/O layer for SBOM data, protobom offers a neutral representation and can ingest/write various SBOM formats. A visualization library within the protobom ecosystem was used to render a terminal-based dependency graph of the kubectl SBOM, quickly illustrating its internal structure (e.g., Go module dependencies).
• SBOM Naming Recommendation: The OpenSSF "SBOM Everywhere" group has developed naming recommendations (e.g., kubernetes-kubectl-1.29.3.spdx.json) to standardize how SBOMs are published, particularly in GitHub releases.

Signing: Establishing Trust with Signatures and Attestations

Purpose: Cryptographically bind the SBOM to its producer and ensure its integrity, preventing tampering.

Methods & Tools:

• Detached Signatures (using Sigstore and Cosign):
• Cosign (part of Sigstore) was used to sign the kubectl SBOM (both CycloneDX and SPDX versions). Sigstore leverages identity providers (like GitHub) to issue temporary certificates, embedding the signer's identity directly into the certificate.
• Verification: cosign verify checks the signature. Critically, to fully benefit from Sigstore's identity binding, consumers must specify the expected identity (e.g., GitHub account or workflow) during verification, rather than using a permissive regular expression.
• Attestations (using in-toto and bind):
• Concept: Attestations provide verifiable metadata about the software supply chain. An SBOM can be embedded as a "predicate" within an in-toto attestation, which is then bound to a "subject" (the software artifact itself, e.g., kubectl.tar.gz). This attestation can also include provenance (how it was built), test results, or vulnerability scan reports.
• bind: A pre-release tool that simplifies the creation of Sigstore-signed attestations. It bundles the SBOM, the attestation, and all necessary verification material (signature, certificate, timestamp proof) into a single, distributable JSON file. This "bundle" ensures that the SBOM and its context are verifiable together.
• Distribution Format: Multiple attestations (e.g., for CycloneDX and SPDX SBOMs) can be combined into a JSON L (JSON Lines) file, allowing for the distribution of a comprehensive set of verifiable supply chain metadata in a single, machine-readable file.

Distribution & Sharing: Making SBOMs Accessible

Purpose: Provide standardized, machine-readable channels for consumers to retrieve SBOMs.

Don'ts & Dos: Avoid emailing SBOMs or imposing excessive NDAs. Instead, distribute SBOMs alongside the software artifact itself and ensure access via standard protocols.

Channels:

• GitHub Releases: A common approach for open-source projects.
• OCI Registries: Demonstrated as a viable mechanism for hosting and retrieving SBOMs.
• Package Managers: Some (like npm) are beginning to integrate SBOM support.
• Commercial Exchanges: Manifest, GitHub's attestations feature, and emerging transparency exchange APIs like SKID and Adigma.

Tool: bombl (OpenSSF):

• Functionality: bombl is designed to fetch SBOMs in a tree structure (recursively following internal references) and push them to various destinations. This is crucial for complex systems composed of multiple, nested SBOMs from different suppliers.
• Demo: bombl was used to fetch two SBOMs (one CycloneDX, one SPDX) from a single URL, demonstrating its ability to handle internal references. It then listed the fetched SBOMs, exported them in different formats (leveraging protobom internally), and successfully pushed them to a local OCI registry. This showcases bombl's role in aggregating and redistributing SBOMs across diverse ecosystems.

Operations: Consuming and Using SBOMs

Purpose: Move beyond static compliance to active, continuous utilization of SBOM data for security and operational insights.

Operational Maturity Model:

• Small Scale (few SBOMs): Simple tools like curl, bombl, Gripe, Trivy, or OSV Scanner can be used for individual scans.
• Medium Scale (more SBOMs, comparisons): In-memory databases like DuctDB allow for loading multiple SBOMs and running SQL queries (e.g., finding unique packages across SBOMs).
• Large Scale (many SBOMs, continuous analysis): Dedicated solutions like Guac, Dependency Track, or commercial vendor tools are necessary.

Tool: guac (OpenSSF):

• Core Function: Ingests SBOMs and correlates them with vast amounts of additional supply chain data, creating a comprehensive graph of software dependencies and their associated metadata.
• Data Sources: guac integrates with the OSV database (via OSV Scanner) for vulnerabilities, deps.dev for package relationships, endoflife.date for end-of-life information, and Clearly Defined (an OSI project) for license verification and correction.
• Capabilities:
• Time-based Tracking: guac tracks changes over time, allowing comparisons between different versions of software and continuous updates on vulnerability status.
• Querying: Enables powerful queries against the entire supply chain graph (e.g., guac one query v pearl to list all known vulnerabilities for a specific package URL).
• Organizational Risk: Helps identify widespread use of vulnerable components (e.g., Log4j sprawl) and assess the impact of new disclosures.
• Patch Plans: By connecting SBOMs across different layers (e.g., container -> application -> libraries), guac can generate comprehensive patch plans, illustrating the upstream dependencies that need fixing to resolve an issue in a deployed artifact.

Actions & Automation:

• Remediation: Using correlated data to prioritize and automate vulnerability fixes (e.g., npm audit fix).
• Policy as Code: Integrating with tools like OPA (Open Policy Agent) to define and enforce security policies based on SBOM data. This can automatically block deployments if certain vulnerability or license criteria are not met.
• Runtime Correlation: Combining SBOM data with runtime analysis tools like Kubescape (for Kubernetes clusters) and eBPF to determine if vulnerable packages are actually loaded into memory in a running environment. This helps prioritize fixes by focusing on actively exploitable vulnerabilities.

Infrastructure as Code (IaC) SBOMs: The speakers acknowledged the emerging need for IaC SBOMs but noted their relative immaturity compared to software SBOMs. Some approaches involve including IaC configuration files within software SBOMs, but the dynamic nature of IaC presents unique challenges for static representation. Runtime correlation is seen as particularly important for IaC.

Demo / Proof of Concept

▶ Watch: SBOM Producer Lifecycle: Verification, attestation, and signing. (6:50)

The workshop was a hands-on experience, extensively utilizing a pre-configured Gitpod environment (accessible via tinyurl.com/sbomb-workshop) to demonstrate each step of the SBOM lifecycle.

The journey began with the generation of a basic SBOM for kubectl using a generic tool, immediately highlighting the typical deficiencies in top-level metadata. This set the stage for the subsequent augmentation process.

Next, the sbom-as-in tool was demonstrated, first by adding essential document-level metadata (such as the SBOM's lifecycle phase and the tools used in its creation), and then by injecting critical component-level data for the top-level kubectl component, including its author, supplier, and repository location. This clearly illustrated how a sparse SBOM could be enriched with producer-specific information.

Sneak's Parlay was then showcased, demonstrating its ability to significantly enrich the kubectl SBOM by querying the ecosystems database. This added detailed metadata like licenses, descriptions, and external references for numerous individual components, transforming a basic component list into a much more informative document.

For verification, the speakers used a visualization library from the protobom project to render a dependency graph of the kubectl SBOM directly in the terminal, providing a quick visual check of its structure and relationships.

The signing process involved Cosign (from Sigstore). The demo illustrated how to sign both the CycloneDX and SPDX variants of the kubectl SBOM, leveraging a GitHub identity through Sigstore's device flow to bind the signature to a verifiable identity. Following this, the new bind tool was used to create an attested SBOM. This involved wrapping the kubectl SBOM within an in-toto attestation, bound to the kubectl.tar.gz artifact, and then signing this bundle, demonstrating the creation of a self-contained, verifiable artifact.

Finally, the bombl tool was presented. The demonstration involved fetching two SBOMs (one CycloneDX, one SPDX) from a single URL, showcasing bombl's ability to recursively follow internal references. The SBOMs were then listed, exported into different formats (highlighting protobom's underlying translation capabilities), and subsequently pushed to a local OCI registry, illustrating how SBOMs can be aggregated and distributed across various repositories.

These live demonstrations were crucial in grounding the theoretical concepts in practical application, allowing participants to follow along and understand the tangible benefits of each tool and process.

Defensive Implications

▶ Watch: Choosing your preferred SBOM generation tool and standard. (7:45)

The detailed technical workshop on practical SBOMs offers several critical implications for defenders seeking to bolster their software supply chain security:

• Elevate SBOM Quality as a Security Imperative: Defenders must move beyond accepting "compliance-only" SBOMs. Organizations should demand and produce augmented and enriched SBOMs that contain comprehensive, actionable metadata. An incomplete SBOM provides a false sense of security and hinders effective vulnerability management.
• Embrace Attestations for Trust and Integrity: Integrate Sigstore and in-toto attestations into the CI/CD pipeline for both software artifacts and their associated SBOMs. This provides cryptographic proof of origin and integrity, allowing defenders to verify that an SBOM (and the software it describes) has not been tampered with and originates from a trusted source. This is a foundational step in building a verifiable supply chain.
• Automate SBOM Generation and Integration: Mandate and automate the generation, augmentation, enrichment, and signing of SBOMs as an integral part of every software build and release process. This ensures that SBOMs are always up-to-date, accurate, and available, reducing manual overhead and human error. Tools like sbom-as-in, parlay, and bind should be integrated into pipelines.
• Operationalize SBOM Consumption for Continuous Analysis: Deploy dedicated platforms like Guac or Dependency Track to ingest, correlate, and continuously analyze SBOM data at scale. This enables proactive identification of vulnerabilities, license risks, and dependency sprawl across the entire software estate, rather than reacting to individual disclosures.
• Prioritize Vulnerability Remediation with Context: Leverage tools like Guac to correlate SBOM data with vulnerability databases (e.g., OSV database) and end-of-life information. This allows defenders to create intelligent "patch plans" that understand transitive dependencies and prioritize fixes based on actual impact and organizational exposure, rather than a flat list of CVEs.
• Implement Policy as Code for Automated Enforcement: Use policy engines like OPA to define and enforce security policies based on SBOM contents and correlated data. For example, policies could automatically block deployment of software containing critical vulnerabilities, non-compliant licenses, or unverified attestations.
• Integrate Runtime Correlation for Real-World Exposure: Combine static SBOM analysis with dynamic runtime data from tools like Kubescape and eBPF. This allows defenders to determine if vulnerable components are actually loaded into memory or actively exploited in production environments, enabling more precise prioritization of remediation efforts based on immediate risk.
• Advocate for Ecosystem Maturity and Standardization: Actively participate in and support initiatives (like those within the OpenSSF) that aim to standardize SBOM formats, exchange mechanisms, and tooling. A more mature and interoperable ecosystem benefits all defenders by simplifying SBOM integration and analysis.

Key Takeaways

• SBOM Quality is Paramount: Generating an SBOM is merely the first step; its true value lies in its completeness, accuracy, and trustworthiness for security and legal analysis.
• The SBOM Producer Life Cycle is a Roadmap: Following the structured phases of augmentation, enrichment, verification, signing, and distribution is critical for creating high-quality, actionable SBOMs.
• Attestations Build Trust: Digital signatures and in-toto attestations, powered by Sigstore, provide verifiable proof of an SBOM's origin and integrity, essential for a secure supply chain.
• Specialized Tools Enhance the Lifecycle: Projects like sbom-as-in, parlay, protobom, cosign, bind, and bombl provide practical, open-source solutions for each stage of SBOM creation and management.
• Operationalization is the Goal: Moving beyond compliance, tools like Guac enable continuous ingestion, correlation, and analysis of SBOM data, transforming them into dynamic assets for vulnerability management, license risk, and dependency sprawl.
• Integrate with Runtime for Context: Combining SBOM insights with runtime observations (e.g., Kubescape, eBPF) allows for more intelligent prioritization of security fixes based on actual exposure.

About the Speaker(s)

The workshop was presented by a trio of experts deeply involved in the open-source software supply chain security community:

Adula Garcia is a key contributor at Kim Systems and a significant figure within the OpenSSF. He serves as a technical lead for both the OpenSSF vex and protobom projects, which are crucial for SBOM data representation and vulnerability exchange. Additionally, Adula is active in the Kubernetes community, contributing to the release engineering team where he focuses on SBOM and supply chain security features for Kubernetes releases.

Mike is the CTO of Cusari, a startup specializing in supply chain security. His influence extends across the OpenSSF, where he is a governing board member and part of the Technical Advisory Council. Mike is also a maintainer of several vital open-source projects, including Guac (Graph for Understanding Artifact Composition) and Salsa (Supply-chain Levels for Software Artifacts), a secure build framework. He holds a tech lead position in CNCF TAG Security and is the co-author of a recently released book on supply chain security.

Ian is another prominent governing board member of the OpenSSF. He is highly active in ECNA International TC54, the committee responsible for overseeing the CycloneDX SBOM standard. Ian's contributions to open-source tooling include maintaining bombl (for fetching and distributing SBOMs) and sbomb-it (focused on SBOM differences and provenance), both OpenSSF projects. Beyond his technical work, Ian has a unique interest in commercial brewing and backpacking.