Welcome to another year of the SBOM devroom, now also including more general Supply Chain topics!
The organizers will introduction the topics and the structure of the devroom.
The growing use of Software Bill of Materials (SBOMs) has introduced a new challenge with six different types exist (Design, Source, Build, Analysed, Deployed, and Runtime). As each type captures component information at a unique point in the development lifecycle, it is no longer sufficient to say that you want an SBOM' ypu mered the right one which meets your use case. So how do you determine which SBOM type is the right fit for your specific use case?
This session attempts to provide the answer through the use of the creation of a sample application moving through the entire development pipeline, demonstrating precisely how the SBOM's content evolves from an initial Design SBOM to a final Runtime SBOM captured within a runtime environment. It will demonstrate the critical information that can be gained at each stage, the specific use cases that each SBOM type enables, and the practical challenges that still need to be overcome to create reliable, high-quality SBOMs.
Modern embedded products are no longer single-processor devices. A typical architecture combines a Linux-based main system, one or more microcontrollers running RTOS workloads, and cloud-side processing also running on Linux. Each of these components produces its own SBOM - often using different formats, tooling, and levels of detail.
But what happens when you need to use all of them together for vulnerability management?
This talk shares a real-world journey of attempting to aggregate and analyse SBOMs across heterogeneous parts of an embedded product. We will walk through the practical challenges encountered: incompatible SBOM formats, ambiguous identifiers, conversion tools that fail in unexpected ways, and friction between ecosystem assumptions and embedded reality. The goal is to highlight what currently works, what does not, and what the community could improve to make multi-SBOM workflows feasible for embedded systems.
Attendees will leave with concrete insights, pitfalls to avoid, and a clearer picture of the current limits of SBOM-based vulnerability management in complex (but totally common) embedded architectures.
Various tools producing SBOMs for pre-built artifacts, such as container images, usually provide only a flat list of components - packages, libraries, RPMs, and binaries - without explaining where any of them originated. But why does this origin information matter, and how can we obtain it?
To simply introduce the concept, imagine your build ecosystem as a bakery: the built container is the loaf of bread, and your SBOM is the ingredient label on the package. While customers only see a flat list of ingredients, bakers actually care about where each one came from, because they are responsible for the quality and safety of the final product. The same applies to components in a Containerfile. As the "building factory", we need to know the provenance of every package, library, and binary - not just that it exists, but whether it came from a base image, a builder stage, or was installed directly in the final Containerfile. This provenance information, captured in a Contextual SBOM, is essential for effective vulnerability management. Once an issue appears, understanding vulnerability origin determines whether we must update a base or builder images, update a Containerfile-installed package, or rethink the build process entirely.
In this talk, we will show how we transform a plain, flat SBOM into a structured, layered Contextual SBOM, and what benefits this brings. We will demonstrate how contextual provenance helps us identify vulnerabilities faster and more reliably, and how it improves our overall vulnerability-management workflow.
Key Topics: - Limitations of traditional SBOMs: Why flat, non-contextual SBOMs fall short in containerized build environments where content origin is unclear - Introducing Contextual SBOM: An overview of contextual SBOMs and how they enrich component data with provenance - Differentiation base image vs. installed content: distinguishing inherited base-image content from software added directly in the Containerfile - Tracing builder-stage content: Identification and attributing content copied from builder stages in multistage builds to final image - Using Contextual SBOMs in vulnerability management: How provenance-aware SBOMs accelerate triage, clarify responsibility, and improve remediation decisions
This talk is ideal for security professionals, compliance officers, compliance auditors, developers and anyone involved in the supply chain aspects of software.
Relevant repositories: https://github.com/konflux-ci/mobster https://github.com/konflux-ci/capo
When a new CVE surfaces in an open-source dependency, teams face an immediate question: Do we really need to update? Is the vulnerability eploitable? In practice, nearly 90% of reported issues never affect the consuming application, but identifying the critical 10% is far from trivial. Reachability analysis offers a path forward by tracing vulnerable functions from the upstream component through multi-hop call graphs to determine whether the affected code is ever invoked downstream.
Despite its value, reachability analysis is notoriously difficult to automate. Most organizations still rely on manual investigation, while existing SCA tools frequently fall short, leaving teams uncertain and prompting unnecessary upgrades.
This talk presents a concrete case study from Apache Hadoop and Solr, illustrating how accurate reachability analysis can prevent wasted effort, reduce noise, and focus attention on the vulnerabilities that truly matter. The reachability of vulnerabilities will be analyzed using the Open Source VEX Generation Toolset project.
The modern software supply chain is no longer suffering from a lack of data. Between SBOMs, SLSA provenance, and vulnerability scans, DevOps teams are drowning in attestations. However, a critical gap remains: the ability to aggregate this diverse evidence and enforce consistent, automated security decisions. Simply having an SBOM does not secure your pipeline; verifying its content against a trusted policy does.
In this talk, we introduce Conforma, an open-source tool designed to address the enforcement gap in supply chain security. We will move beyond static documentation and demonstrate how to implement an automated, blocking Policy Gate that enforces integrity before deployment.
Attendees will learn how to transition from passive observation to active enforcement using Policy-as-Code. We will demonstrate how Conforma acts as a central engine that ingests various security artifacts, including SBOMs, in-toto attestations, and vulnerability reports, to evaluate them against strict policies.
To provide a detailed look at the tool's capabilities, we will showcase two concrete policy checks: SBOM Content Hygiene and SLSA Provenance.
Attendees will leave with a clear understanding that supply chain data is only as valuable as the policies that enforce it. They will learn how Conforma automates this verification, turning a passive collection of attestations into an active, enforceable defense system.
Conforma: https://conforma.dev/ SLSA Provenance: https://slsa.dev/spec/v1.1/provenance In-toto: https://in-toto.io/
As one of the co-leaders of the CISA working group on SBOM Generation and a contributor to its accompanying whitepaper, I’ve spent the last few years deep in the trenches of SBOM creation. With the EU’s Cyber Resilience Act (CRA) raising the bar for software transparency and lifecycle security, the need for reliable, high-quality SBOMs has never been more urgent.
In this talk, I’ll present a practical blueprint for SBOM generation that goes beyond minimal compliance and helps projects prepare for the expectations emerging from the CRA and similar regulatory frameworks. The model breaks SBOM creation into four clear phases:
I’ll discuss the technical considerations behind each phase, common pitfalls, and how these practices help projects avoid the compliance gaps many teams are now discovering as the CRA timeline approaches.
To ground everything in reality, I’ll also demo an open-source implementation of this entire workflow that runs directly inside GitHub Actions (or any CI environment), enabling maintainers to adopt a CRA-ready SBOM pipeline without proprietary tools.
500,000 SBOMs -- that's the scale of Deutsche Bahn's software supply chain. We will show how we extend our automated collection of Source, Build, Artifact, and Runtime SBOMs from both internal systems and external suppliers, and how we make this data usable. Doing this, we understand that SBOMs are not a tool by themselves but a supporting method for various use-cases. To facilitate them, we heavily rely on FOSS tools, enriched with own logic to fit into our enterprise architecture. You love diagrams? We have them!
But tools and clever ideas aren't enough. We need people to integrate them into pipelines and continuously monitor the quality of the resulting SBOMs and derived findings. We depend on cooperation from operators of related internal services. And we also need support from our governance stakeholders. Join this session to hear about our journey, where we stand today, and what lies ahead.
This is a case study of how we managed to analyse & subsequently automate the SBOM generation for a very large, legacy code base. Come and hear about our journey to lift the LibreOffice-family open source projects into modern software supply chain management times, including some war stories about particularly obnoxious dependencies, as well as what tools (standard, as well as home-grown) we're using for that.
SBOMs have become the poster child of supply chain security. Everyone's generating them, regulators are demanding them, and compliance tools are built around them. But, the same package gets identified differently across tools, ecosystems, and standards. You end up with multiple SBOMs for the same software that can't be correlated, cross-referenced, or meaningfully compared - or actionable for vulnerability exploitability and remediation.
Package-URLs (PURLs: https://github.com/package-url/purl-spec) solve the identification problem to make SBOMs actually useful. A PURL provides a universal, standardized identifier for any package across any ecosystem. This simple spec makes supply chain tooling interoperable, enabling vulnerability databases, compliance tools, and SBOM generators to speak the same language about packages, regardless of source.
This talk covers the latest PURL developments that are making it essential infrastructure: validation tools, expanded ecosystem support including AI/ML model identifiers, growing adoption in major security tools and databases, integration into SBOM standards like SPDX and CycloneDX, and community-driven efforts to standardize package identification across the entire supply chain landscape. We'll show real examples where PURLs enable cross-ecosystem vulnerability tracking, make SBOM validation actually possible, and simplify compliance workflows by providing a common identifier system everyone can use.
The title is provocative, but the reality is complementary: SBOMs describe your software's composition, PURLs make those descriptions machine-readable and universally meaningful. You'll leave understanding how PURLs are becoming critical infrastructure for supply chain security, why major projects and ecosystems are adopting PURL, and how to integrate PURLs into your own tooling and compliance automation workflows.
SPDX 3.1 is transforming from a flat bill of material scheme to a knowledge graph” that now covers hardware, supply-chain security and safety tests, and the 130+ crypto algorithms that are used on your data. The AI/Dataset profile added three must-have lines for every smart assistant—AI Agent, Prompt, and RAG so you can see exactly how your AI system (Basiic AI, GenAI and Agentic AI) was created
SPDX has also added a SPDX crypto lalgorithm list which is similar to the methodology and process that was used for the SPDX License list. There are over 130 algorithms that have been reviewed by the SPDX Working group
Demonstrate some newly available SPDX SBOM tools that can automate creating SBOM for existing AI system.
In this talk we will:
1. Show the ontology and how a single spdx:Element can simultaneously be:
hw:Chip (Hardware )
da:Requirement (Design-Assurance)
crypto:Algorithm (Cryptology)
sc:TransportEvent (Supply-Chain)
2. Show how to query the knowledge graph to:
“Return every AI model that was trained on dataset x deployed on a hardware y whose root-of-trust implements one of the 130 curated cryptographic algorithms, and that passed a functional-safety test required by CRA.”
3. Show how the new classes in AI/Dataset profile and relationship can document an Agentic AI system
4. Demonstrate how for CRA, ISO 42001, and FDA : where each regulation asks a different question, but all questions can be seen as graph walk(s).
We will present a multi-layered semantic structure for modelling and examining software supply chains using Software Bills of Materials (SBOMs), and a case study of its application to analyse CERN's computing services.
Contemporary software ecosystems depend significantly on FOSS components, but SBOMs only offer standalone snapshots of elements, missing integrated perspectives on organisational context, vulnerability propagation, and internal software behaviour. This study integrates Semantic Web technologies, graph-based dependency modelling, and function-level structural analysis to overcome these limitations. At the organisational level, diverse SBOMs, survey data, licensing details, and vulnerability records are integrated into an ontology-based knowledge graph, facilitating expressive queries and automated reasoning throughout varied software landscapes. At the project level, the Vulnerability-Dependency Graph (VDGraph) model integrates SBOM dependency details with vulnerability information from Software Composition Analysis(SCA) tools, aiding the analysis of how vulnerabilities spread through dependency chains. Ultimately, at the code level, function-call graphs described by node centrality metrics and Graph Attention Network (GAT) embeddings reflect the structural significance of functions within an application, providing insights on how updates in dependencies might influence internal behaviour.
Created during an internship at CERN’s Open Source Program Office, this framework offers a complete, scalable method for understanding, managing, and safeguarding intricate software supply chains within large and heterogeneous organisations. The framework has been put in practice to perform an analysis of CERN's computing ecosystem during 2025.
Build-time SBOMs for traditional C/C++ applications have historically been difficult to generate. To improve this situation, we have been extending pkgconf to support generating high-quality build-time SBOMs, as the pkg-config database already understands all of the build dependency relationships needed for a build-time SBOM. This talk is intended to be a walk through using the new pkgconf 3.x SBOM tools to generate a high quality build-time SBOM for a project.
A Software Bill of Materials (SBOM) provides a detailed inventory of software components in an artifact. SBOMs allow developers to improve the supply chain security of their Swift projects by analyzing direct and transitive dependencies for vulnerabilities. Currently, Swift Package Manager (SwiftPM) lacks built-in SBOM support, and developers must rely on third-party tools that can under- or over-represent package dependencies in a project, leading to a lack of critical information or too much noise.
This talk focuses on an in-development feature to integrate SBOM generation directly into the Swift toolchain. As a result of this upcoming integration, developers will be able to create industry-standard CycloneDX or SPDX SBOMs as part of their build, without additional configuration. We will delve into the design in which SwiftPM employs the resolved modules graph to generate accurate SBOMs that capture both package and product dependencies, and optionally incorporates SwiftBuild build system’s build graph to align the SBOM with build-time conditions.
Listeners will be introduced to the basics of SwiftPM, learn more about the upcoming SBOM generation design that leverages SwiftPM’s existing graph structures, and have the opportunity to provide feedback before the feature is released.
BuildStream is a software integration tool that allows building software aggregated from multiple sources in a single pipeline to produce a final output. This final output could be a container image, an operating system image or anything that you can write a plugin for.
In this talk, I present buildstream-sbom. It's a tool that extracts information from a BuildStream project and uses it to generate an SPDX-formatted SBoM. I also discuss the issues that I had translating from BuildStream concepts to SPDX.