Skip to main content

BSides Munich 2025 Workshop: SBOM 1x1

Marius Biebel9/16/25About 11 min

BSides Munich 2025 Workshop: SBOM 1x1

Workshop Agenda

  • Introduction to SBOMs
  • Overview of SBOM standards: SPDX & CycloneDX
  • Legal requirements for SBOMs around the world
  • Generating a first SBOM using Syft and CdxGen
  • Looking at an SBOM: understanding its contents and lifecycle
  • Scanning SBOMs for vulnerabilities using Grype
  • Processing SBOMs at scale – using DependencyTrack

VM Setup

For this workshop, we provide a preconfigured VM image that contains all necessary tools and resources to follow along with the exercises. You can download the VM image from the following link:

GitHub Workspace Setup

As a lightweight alternative to a full VM image, you can also use the GitHub Workspace setup provided in the workshop repository. This allows you to run all exercises directly in your browser.

::: warn
If the commons-io or the keycloak repositories are not already cloned in your workspace, please clone them using the following skript:

./clone-repos.sh

What is an SBOM?

An SBOM (Software Bill of Materials) is a comprehensive inventory of all components, libraries, and dependencies within a software application. It includes details such as version numbers, licenses, and relationships between components, providing transparency and facilitating better security and compliance.

Why do I need an SBOM?

  1. Compliance: Many regulations and standards now require SBOMs to ensure software supply chain transparency.
  2. Security: SBOMs help identify vulnerabilities in third-party components, enabling proactive risk management.
  3. Incident response: In the event of a security breach, an SBOM allows for quick identification of affected components.
  4. License management: SBOMs assist in tracking open-source licenses to ensure compliance with legal obligations.
  5. Transparency: Provides customers and stakeholders with insight into the software's composition.

Threat Scenario

Info

Based on the 2024 Report of the State of the Software Supply Chain by Sonatype

Graph of Malicious packages discovered by Sonatype
Graph of Malicious packages discovered by Sonatype

In recent years, we have seen a significant increase in supply chain attacks. Sonatype alone identified over 700,000 malicious packages in the last five years. This increase shows how attractive supply chain attacks have become for attackers, as this attack vector offers wide reach with relatively low effort. While most of the malicious packages found were not very sophisticated, there are also examples of highly sophisticated attacks like the XZ Utils incident, which was attributed to APT29 (Cozy Bear). This shows that nation-state actors are also leveraging supply chain attacks to fulfill their objectives, weaponizing open source for their own interests.

This raises the question of how many such malicious packages are still undetected and waiting to be discovered. To be able to respond quickly to such incidents, it is crucial to have a good overview of the software components used in your applications. This is where SBOMs come into play: they provide a detailed inventory of all components, their versions, and relationships. With this information at hand, organizations can quickly identify if they are affected by a newly discovered malicious package and take appropriate actions to mitigate the risk.

Graph of SBOM publishing count by Sonatype
Graph of SBOM publishing count by Sonatype

In recent years, several countries have introduced regulations and guidelines that mandate or encourage the use of SBOMs to enhance software supply chain security. Most recently, 17 countries came together to issue the Cybersecurity Information Sheet (CSI), “A Shared Vision of Software Bill of Materials (SBOM) for Cybersecurity,” to promote SBOM adoption and standardization globally. The following is a brief overview of current requirements and guidelines from different regions:

Overview of current requirements and guidelines

Warning

This is not an exhaustive list and does not constitute legal advice.

United States:
🇺🇸

  • Executive Order 14028 + NTIA “Minimum Elements” define baseline expectations. (Biden Administration)
  • OMB M-22-18 and follow-ons push federal software supply chain assurances; SBOM or equivalent attestations may be requested in procurement.
  • FDA (medical devices): 2023 Final Guidance “Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions” expects an SBOM (list of software components with version, supplier, purpose) in submissions; FDORA (Sec. 524B) reinforces postmarket cybersecurity and update obligations. SBOM supports vulnerability communication.
  • NIST SSDF (SP 800-218) references software supply chain transparency practices.

European Union:
🇪🇺

  • Cyber Resilience Act (CRA) introduces product security obligations; SBOM-like transparency supports vulnerability handling and conformity assessments.
  • NIS2 raises the bar for essential/important entities; SBOMs support risk management and incident response duties.

Germany:
🇩🇪

The Technical Guideline TR-03183: Cyber Resilience Requirements for Manufacturers and Products Part 2 Software Bill of Materials (SBOM) provides essential guidance for creating an SBOM. The Technical Guideline TR-03183 aims to provide manufacturers with advance access to the requirements that will be imposed by the future EU Cyber Resilience Act (CRA).

Japan:
🇯🇵

METI/IPA SBOM guidelines encourage creation and exchange; pilots observed in automotive and medical sectors.

Netherlands
🇳🇱

The Dutch National Cyber Security Center (NCSC) has published an SBOM Starter Guide to assist managers involved in their organization's cybersecurity strategy with implementing SBOMs. This guide explores how organizations can establish processes for using SBOMs, create, manage, and share them effectively, and develop strong agreements with vendors. It also dives into how SBOMs can be utilized for vulnerability management and offers additional insights through supporting frameworks.

India
🇮🇳

No explicit SBOM statute; government cybersecurity guidance and CERT-In advisories promote supply-chain risk management where SBOMs are useful.

SBOM standards SPDX & CycloneDX

  • SPDX (ISO/IEC 5962:2021): an open standard developed under the umbrella of the Linux Foundation.
  • CycloneDX: an open standard maintained by the OWASP Foundation.
SPDX ElementsCycloneDX Elements
Package InformationBOM Metadata Information
File InformationComponent Information
Snippet InformationServices Information
Other Licensing InformationDependency Relationship
Relationship between ElementsCompositions
Annotation InformationVulnerabilities
Review InformationFormulation
Annotations
Extensions

Note

It is important to note that CycloneDX is a simple tree object structure, which makes its serialization and parsing very easy. SPDX is based on a graph structure, which makes it more complex to parse and process.

Versions and Formats

The following timeline shows the release history of both SBOM standards, including their major versions and standardization milestones. Both standards were standardized in 2021 and 2024, respectively. While SPDX saw a major version release to version 3.0 in 2024, redesigning the whole object structure, CycloneDX has been evolving with regular minor version updates, with the latest being version 1.7 in 2025.

Note

Currently, there are only 5 tools that claim to support SPDX 3.0 (and only 4 further tools that claim to implement SPDX 3.0). Most tools that support SPDX are still on version 2.2 or 2.3.

Generating a first SBOM

To generate an SBOM, we need a project that we can scan and work with. Therefore, we chose the Keycloak project as a reference project for its heterogeneous composition and complexity.

Keycloak is made up of multiple components, including Java, JavaScript, and various libraries, making it an ideal candidate for demonstrating SBOM generation.

Task

Use the following tools to generate SBOMs for the Keycloak project source code and container image. Find out how many different components and dependencies are used in the project.

Generating an SBOM using Syft

Syft is an open-source SBOM scanning tool and a Swiss Army knife for SBOM generation. It can analyze various package formats and generate SBOMs in multiple formats, including SPDX and CycloneDX. Syft considers itself a security tool, which means it does not shell out to build tools or other applications to retrieve package information but implements all necessary logic itself.

To generate an SBOM using Syft, we can run the following commands. These commands analyze the specified source directory and output the SBOMs in SPDX or CycloneDX format.

commons-io
# Generate SBOM for Keycloak source code in SPDX JSON format
syft dir:/workspaces/Bsides-25-Munich-Workshop-SBOM-1x1/commons-io -o spdx-json > ~/commons-io.syft.source.spdx.json

# Generate SBOM for Keycloak source in CycloneDX JSON format 
syft dir:/workspaces/Bsides-25-Munich-Workshop-SBOM-1x1/commons-io -o cyclonedx-json > ~/commons-io.syft.source.cdx.json

# Generate SBOM for Keycloak source in SPDX XML format
syft dir:/workspaces/Bsides-25-Munich-Workshop-SBOM-1x1/commons-io -o spdx > ~/commons-io.syft.source.spdx.xml

# Generate SBOM for Keycloak source in CycloneDX XML format
syft dir:/workspaces/Bsides-25-Munich-Workshop-SBOM-1x1/commons-io -o cyclonedx > ~/commons-io.syft.source.cdx.xml

Syft can also scan container images. To scan a container image, use commands like the following:

# Generate SBOM for Keycloak container image in SPDX JSON format
syft registry:quay.io/keycloak/keycloak:26.3.3 -o spdx-json > ~/keycloak.syft.container.spdx.json

# Generate SBOM for Keycloak container image in CycloneDX JSON format
syft registry:quay.io/keycloak/keycloak:26.3.3 -o cyclonedx-json > ~/keycloak.syft.container.cdx.json

# Generate SBOM for Keycloak container image in SPDX XML format
syft registry:quay.io/keycloak/keycloak:26.3.3 -o spdx > ~/keycloak.syft.container.spdx.xml

# Generate SBOM for Keycloak container image in CycloneDX XML format
syft registry:quay.io/keycloak/keycloak:26.3.3 -o cyclonedx > ~/keycloak.syft.container.cdx.xml

Generate an SBOM using CdxGen

CdxGen is another tool that can be used to generate SBOMs in the CycloneDX format. It is designed to be simple and easy to use, making it a good choice for quickly generating SBOMs for projects.

Unlike Syft, CdxGen shells out to other build tools like Maven, Gradle, or npm and might execute parts of build scripts. This comes with the advantage of more accurate results for, e.g., version resolution or licensing information.

commons-io
# Generate SBOM for commons-io source code in CycloneDX JSON format
cdxgen -o ~/commons-io.cdxgen.source.cdx.json /workspaces/Bsides-25-Munich-Workshop-SBOM-1x1/commons-io

# Generate SBOM for commons-io source in CycloneDX XML format
cdxgen -o ~/commons-io.cdxgen.source.cdx.xml -f xml /workspaces/Bsides-25-Munich-Workshop-SBOM-1x1/commons-io
Resources to improve quality
RUN apt-get update \
    && apt install default-jdk -y \
    && apt install maven -y

Implementing SBOM Generation in the Build Process

To ensure that the SBOM is aligned with the artifact build, it is recommended to integrate SBOM generation into the build pipeline. This can be achieved by adding SBOM generation plugins to the build tools used in the project. For example, in Keycloak the main technology is Java/Maven, while the frontend is built using Node.js/npm. Therefore, in both tools we can add SBOM generation plugins, and then merge the generated SBOMs for each module into a final SBOM.

This is implemented as a POC in the provided VM image in the Keycloak project. Open IntelliJ IDEA and check out the branch sbom-tooling-pilot. Using the compare function of the IDE with the tag 26.3.3, you can see the changes made to the build files to integrate SBOM generation into the build process.

Using the run configuration SBOM Generation, you can trigger a full build of the Keycloak project including SBOM generation for each module. The final SBOM is then located in the target/sbom/keycloak-sbom.json file.

Looking at an SBOM

Once we have generated an SBOM, we can take a look at its contents to understand the components and dependencies of the project. SBOMs are typically structured in a machine-readable format, making it easy to parse and analyze them using various tools.

For example, we can use the jq command-line tool to query and filter the JSON output of the SBOM. Here are a few examples of how we can explore the contents of an SBOM:

commons-io
# View the entire SBOM
cat ~/commons-io.syft.source.spdx.json | jq .

# List all packages in the SBOM
cat ~/commons-io.syft.source.spdx.json | jq '.packages[] | {name: .name, version: .version}'
commons-io
# View the entire SBOM
cat ~/commons-io.syft.source.cdx.json | jq .

# List all components in the SBOM
cat ~/commons-io.syft.source.cdx.json | jq '.components[] | {name: .name, version: .version}'

Visualizing an SBOM

To better understand the structure and relationships within an SBOM, we can use visualization tools. One such tool is CycloneDX Visualizer, which provides a graphical representation of the SBOM.

Using SBOMQS to assess SBOM quality

To get a good impression of the quality of the generated SBOMs, we can use the open-source tool SBOMQS.

If not installed yet, download the following file and open it via double-click in the VM environment to install it.

# Score all SBOMs in the home directory
sbomqs score -b *

# See detailed breakdown
sbomqs score ~/keycloak.syft.source.cdx.json

To look into the details of SBOM quality, we can query for missing features like components without version or supplier information.

# Components without versions
sbomqs list ~/keycloak.syft.source.cdx.json --feature comp_with_version --missing

# Components without suppliers
sbomqs list ~/keycloak.syft.source.cdx.json --feature comp_with_supplier --missing

Analyzing SBOMs

Until now, we have taken the perspective of a software producer generating SBOMs for their software projects. Now we will take the perspective of a software consumer that receives SBOMs from suppliers and wants to analyze them for potential vulnerabilities and risks. To obtain real-world SBOMs of high quality, we can use repositories from the Apache Foundation and the Eclipse Foundation that provide SBOMs for their open-source projects.

Analyzing SBOMs using Grype

Grype is an open-source vulnerability scanner that can analyze SBOMs to identify known vulnerabilities in the components listed within them. It supports various SBOM formats, including SPDX and CycloneDX.

To scan an SBOM, Grype uses the Grype DB, which is a regularly updated database of known vulnerabilities (by Anchore Inc.). Grype automatically downloads and updates this database to ensure that it has the latest information on vulnerabilities. To manually update the Grype DB, you can run the following command:

# Update the Grype vulnerability database
grype db update

Grype DB is based on multiple data sources listed by the following command:

# List data sources used by Grype DB
grype db providers

Currently, Grype DB includes data from the following sources:

  • Alma
  • Alpine
  • Amazon
  • Bitnami
  • Chainguard
  • Chainguard-libraries
  • Debian
  • Echo
  • EPSS
  • GitHub
  • KEV
  • Mariner
  • Minios
  • NVD
  • Oracle
  • RHEL
  • SLES
  • Ubuntu
  • Wolfi

To scan an SBOM using Grype, you can use the following command:

# Scan the SBOM for vulnerabilities
grype sbom:~/syft.source.spdx.json

The results of Grype can not only be viewed in the CLI but also exported to various formats for further processing. For example, to export the results in CycloneDX JSON format, you can use the following command. This way, you can enrich a CycloneDX SBOM with vulnerability information, including VEX data, that can be processed by other tools like DependencyTrack.

# Scan the SBOM for vulnerabilities and export results in CycloneDX JSON
grype sbom:~/syft.source.spdx.json -o cyclonedx-json > ~/grype.vulnerabilities.cdx.json

Analyzing SBOMs using DependencyTrack

DependencyTrack is an open-source platform that helps organizations manage and analyze software supply chain risks. It can ingest SBOMs in various formats, including SPDX and CycloneDX, and provides features for vulnerability management, license compliance, and risk assessment.

To use DependencyTrack, first go into the ~/DependencyTrack directory and start the application using Docker Compose:

Alternative: Using DependencyTrack for GitHub Codespaces

Github Codespaces can't provide a DependencyTrack instance. Therefore, you can find a public instance on https://lab-pub-67.seclab.cs.hm.edu/
Credentials will be provided during the workshop.

Details
  • Username: bsides
  • Password: [provided during the workshop]

In DependencyTrack, you can see a range of SBOMs related to real-world projects from the Apache Foundation and the Eclipse Foundation. Both organizations have a strong focus on open-source security and SBOM adoption.

The Eclipse Foundation also provides a public DependencyTrack instance where you can explore SBOMs and vulnerability data for various Eclipse projects. This is also a good reference for how DependencyTrack can be used in practice to manage software supply chain risks. You can register a free Eclipse account on their website to access the DependencyTrack instance.

Finding further tools to implement SBOM generation and processing

To find further tools for SBOM generation and processing, you can refer to the SBOM Catalog from the OpenSSF. You can also consult the catalogs from the SPDX and CycloneDX projects. These catalogs provide a comprehensive list of tools and resources related to SBOMs, including generators, parsers, viewers, and more.

Outlook on VEX

VEX (Vulnerability Exploitability eXchange) is a standardized format for communicating the exploitability of vulnerabilities in software components. It provides additional context to SBOMs by indicating whether a specific vulnerability affects a particular component in a given environment.

The idea here is to avoid false positives when scanning SBOMs for vulnerabilities by providing information from upstream sources about the exploitability of vulnerabilities.

Currently, VEX is supported by tools like Grype and DependencyTrack, which can generate and consume VEX data to enhance vulnerability management processes. As the adoption of SBOMs continues to grow, VEX is expected to play an increasingly important role in helping organizations prioritize and manage vulnerabilities effectively.

However, at the time of writing, VEX information is hard to come by and not widely adopted yet. And even if such information is provided, it's often not in a general format like CSAF, OpenVEX, or CycloneDX. For example, Keycloak provides such information in their osv-scanner.toml file in their GitHub repository. However, this is only used by their own vulnerability scanning tooling and not passed along to consumers of the Keycloak project.

Bugs are attracted by light, so use a dark theme.
Copyright © 2025 Marius Biebel