feat: convert remaining talks to content

This commit is contained in:
2026-02-21 16:36:04 +01:00
parent f04d279e2b
commit 10097fb4ac
78 changed files with 823 additions and 13 deletions

Binary file not shown.

Before

Width:  |  Height:  |  Size: 308 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 242 KiB

View File

@@ -9,7 +9,10 @@ tags:
- SupplyChain
- Security
headerimage:
src: firstslide.jpg
src: fosdem-2026-sbom-approach.jpg
alt: Max Mehl giving the presentation at FOSDEM 2026. The image contains the title slide in large, and a small picture of Max Mehl in the corner.
processes:
- fill 1000x440 bottom webp
video: https://video.fosdem.org/2026/ud2208/7EYTRJ-deutsche-bahn-large-scale-sbom-approach.av1.webm
slides: https://fosdem.org/2026/events/attachments/7EYTRJ-deutsche-bahn-large-scale-sbom-approach/slides/267417/2026-02-0_wtntumx.pdf
event:
@@ -17,6 +20,10 @@ event:
href: https://fosdem.org/2026/schedule/event/7EYTRJ-deutsche-bahn-large-scale-sbom-approach/
---
500,000 SBOMs -- that's the scale of Deutsche Bahn's software supply chain. In this FOSDEM 2026 session, I showed 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.
At FOSDEM 2026, I presented Deutsche Bahn's journey from operational need to concrete implementation of large-scale SBOM collection and use. The scale is staggering: approximately 500,000 SBOMs across our software supply chain expected, covering 7,000+ IT applications, 100,000+ Open Source components, and diverse sourcing streams from software we build ourselves to what we buy and operate. The talk focused on how we moved from understanding that "we need to know, in real-time, which exact component is used where and how" to actually making this happen in an organization with 220,000+ employees and hundreds of subsidiaries.
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. This session was about our journey, where we stand today, and what lies ahead.
I explained our approach to treating SBOMs as shared infrastructure rather than a goal in itself. SBOMs support multiple use cases: Open Source license compliance, security vulnerability checking, understanding component distribution, assessing quality, satisfying governance requirements, and supporting strategic decisions about ecosystem engagement. We heavily rely on FOSS tools enriched with our own logic to fit DB's enterprise architecture. A key insight was the integration of VEX (Vulnerability Exploitability eXchange) with SBOMs allowing us to track vulnerability status throughout processes and enabling manufacturers to communicate their assessments to us directly.
The presentation detailed our SBOM strategy and architecture built from scratch: starting with a small interdisciplinary volunteer group, iterating quickly with continuous feedback, focusing on existing organizational needs rather than abstract best practices, and documenting everything publicly. Our technical principles emphasized modularity, open standards, central SBOM storage with decentral sourcing and analysis. The SBOM Blueprint serves as our guiding star, implemented through prioritized increments. We started by focusing on Source/Build SBOMs for in-house developed software, creating low-threshold drop-in solutions for CI pipelines. But as I emphasized throughout: tools and clever ideas aren't enough we need people to integrate them, continuous quality monitoring, cooperation from related service operators, and support from governance stakeholders.
This presentation was a follow-up to my talk the day before on [Deutsche Bahn's overall software supply chain strategy in the context of the EU Cyber Resilience Act (CRA)]({{< relref "2026-01-fosdem-supply-chain-strategy" >}}) while that talk focused on the strategic rationale and high-level approach, this one dove into the technical architecture and practical lessons learned from our initial implementation. Together, they provided a comprehensive overview of how Deutsche Bahn is approaching software supply chain strategy in the context of CRA and beyond.