Max Mehl (Supply chain)

Deutsche Bahn's Approach to Large-Scale SBOM Collection and Use

Sun, 01 Feb 2026 00:00:00 +0000

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.

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) – 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.

Software Supply Chain Strategy at Deutsche Bahn

Sat, 31 Jan 2026 00:00:00 +0000

At FOSDEM 2026, I presented Deutsche Bahn’s software supply chain strategy in the context of the EU Cyber Resilience Act (CRA), but made clear from the start that CRA was the context, not the trigger. We didn’t adopt SBOMs because of regulation – regulation validated the direction we were already taking based on operational needs. The presentation positioned our work at the intersection of CRA compliance requirements, IT operation best practices, and the practical realities of running IT infrastructure for an organization with 220,000+ employees, 7,000+ IT applications, and 100,000+ Open Source components.

I outlined how we understand CRA as consisting of four activity areas: general principles of secure software (which we already do), professional handling of vulnerabilities (also already doing), transparency of software supply chains with SBOMs (the new challenge and focus of this talk), and information to users plus conformity assessments (out of scope but interesting). Deutsche Bahn’s challenge is particularly complex because we take on different roles – customer, manufacturer, and indirectly even steward – across our diverse operations. We build software for ourselves and external customers (ranging from operating systems in train displays to mobile apps), we buy software (local, on-premise, SaaS, bundled in hardware like trains), and we operate everything across multiple environments (on-premise, cloud, edge/embedded).

The strategy presentation emphasized how we created an SBOM architecture from scratch to handle this complexity. Working with a small interdisciplinary volunteer group, we focused on iterating quickly, gathering continuous feedback, and thinking in capabilities rather than specific tools. Our technical principles centered on modularity, open standards and interfaces, central SBOM storage with decentral sourcing and analysis – providing the flexibility needed to adapt to varying stakeholder needs and evolving regulations. The key message was that at DB’s scale and diversity, you cannot implement a one-size-fits-all solution overnight. Instead, we prioritize based on identified risks and external requirements, document everything publicly, and connect the concrete CRA compliance requirements with our broader effort to bring transparency to software supply chains. This transparency forms the basis not just for regulatory compliance, but for security processes, license compliance, and proactively shaping the Open Source ecosystems we depend on.

The day after, I gave a follow-up presentation on our large-scale SBOM collection and use, which dove deeper into the technical architecture and practical lessons learned from our initial implementation. The two talks together provided a comprehensive overview of how Deutsche Bahn is approaching software supply chain strategy in the context of CRA and beyond.

The Burden of Knowledge: Dealing With Open Source Risks

Mon, 10 Mar 2025 00:00:00 +0000

At FOSS Backstage 2025 in Berlin, I explored a critical challenge facing OSPOs and development teams: as we increase analysis of our software supply chains, tools and scorecards reveal potential risks in Open Source projects like low maintenance, lack of community, or poor security practices. But this data alone doesn’t help if it merely points out potential problems without offering solutions. The question is: how should we handle this burden of knowledge? Through manual reviews? Questionnaires? Funding? Or should we look away?

In this session, I focused on the strategic decisions organizations need to make when assessing risk in Open Source dependencies. Drawing from my experience at an organization using a six-digit number of Open Source packages, I explored the options between the extremes of “Let’s measure everything”, “Let’s avoid all risky Open Source”, and “Let’s not look at the data because it might scare off management”. I discussed how to decide whether to use a project, invest resources to support it, or move away from a dependency, and when it makes sense to actively engage with or withdraw from an Open Source project.

This talk provided an overview of feasible options and the foundation for a more informed discussion on managing Open Source risks strategically – without ignorance or fear.

The burden of knowledge: dealing with open-source risks (LWN.net)

Mon, 10 Mar 2025 00:00:00 +0000

My talk at FOSS Backstage (see earlier post) was also covered by LWN.net, in an article by Joe Brockmeier. It’s an extensive summary of the talk.

Organizations relying on open-source software have a wide range of tools, scorecards, and methodologies to try to assess security, legal, and other risks inherent in their so-called supply chain. However, Max Mehl argued recently in a short talk at FOSS Backstage in Berlin (and online) that all of this objective information and data is insufficient to truly understand and address risk. Worse, this information doesn’t provide options to improve the situation and encourages a passive mindset. Mehl, who works as part of the CTO group at DB Systel, encouraged better risk assessment using qualitative data and direct participation in Open Source.

[…]

You’re invited to read the full article.

Who are these Open Source maintainers, actually?

Tue, 14 May 2024 00:00:00 +0000

At Siemens Open Source 2024, I presented a narrative journey through the life of an Open Source maintainer, structured as a five-act drama with a happy ending. Through the story of “Alex”, a fictional developer, I explored what really drives maintainers, what they actually do beyond writing code, and the challenges they face when interacting with corporate structures. The talk moved from the initial motivation of creating a new tool driven by passion and intrinsic needs, through the growth into respected maintainership with community building responsibilities, to the eventual transition of passing on the role to ensure project sustainability.

The presentation highlighted the often-overlooked aspects of maintainership: responding to issues and pull requests, moderating discussions, ensuring code of conduct compliance, mentoring newcomers, designing roadmaps, and making strategic decisions. I also addressed the cultural and process differences between companies and Open Source communities – from hierarchical versus peer production models to the different resource availability and commitment structures. The key message: maintainers are not bosses but servants of their communities, and the true capital of an Open Source project lies not in the code, but in the people and community that keep it alive.

This talk emphasized that while maintainers differ in motivation, funding models, and governance structures, they share core characteristics: a high sense of responsibility, autonomous action, balance of interests, and servant leadership.

The Growing Importance of Software Bills of Materials (SBOM)

Wed, 29 Nov 2023 00:00:00 +0000

I have been invited to talk about Software Bills of Materials (SBOM) in SAP’s Open Source Way Podcast, hosted by Karsten Hohage and with SAP’s Sebastian Wolf as co-guest. We had an interesting conversation about the growing importance of SBOMs in the software industry and their role within Deutsche Bahn. We also discussed the limits of SBOMs and how they can be complemented with other approaches to better understand and manage risks.

In this episode, our host Karsten Hohage talks to Max Mehl and Sebastian Wolf about Software Bills of Materials or SBOMs. An SBOM is a detailed record of all components within a software application, including Open Source libraries, third-party dependencies and licenses. Max and Sebastian discuss the importance of SBOMs as well as some challenges and unanswered questions of the state of the art. They also speak with Karsten about SBOMs within SAP and Deutsche Bahn and the importance of SBOMs when it comes to Open Source.

You can listen to the episode on Apple Podcasts or on Spotify.

SBOMs – A Short Introduction

Tue, 10 Oct 2023 00:00:00 +0000

At OSPOlogy Live Frankfurt in October 2023, I gave an introduction to Software Bills of Materials (SBOMs) for the OSPO community. Everyone had heard of SBOMs by then – they seemed ubiquitous, with shiny tools sprouting up everywhere. But what were they actually all about? What were the real use cases? And what often caused practical applications to fail? This talk aimed to provide a common understanding without the marketing-speak.

The session covered the fundamental concepts of SBOMs, explored concrete use cases where they add value, and discussed the challenges organizations face when trying to implement them in practice. Drawing from my experience working with software supply chain transparency at Deutsche Bahn, I highlighted common pitfalls and offered practical insights for OSPOs looking to make sense of the SBOM landscape.

This was part of a two-day event hosted by SAP’s OSPO and co-organized with TODO Group, InnerSource Commons, LF Energy, OpenChain, SPDX, CHAOSS, and OpenSSF projects.

Hardware Bills of Material with Deutsche Bahn

Wed, 07 Jun 2023 00:00:00 +0000

At Upstream 2023, I participated in a fireside chat with Luis Villa (Tidelift) and my colleague Erik Schaufuss exploring the fascinating intersection between Software Bills of Materials (SBOMs) and Hardware Bills of Materials (HBOMs) within Deutsche Bahn’s complex supply chain. As Germany’s national railway company with hundreds of federated subsidiaries, we face unique challenges in managing both rolling stock hardware and the increasingly software-driven assets within trains. The discussion centered on how learnings from the software supply chain transparency movement – particularly around standards like CycloneDX – can inform and improve hardware supply chain management.

The conversation explored Deutsche Bahn’s federated corporate structure and how this complexity makes supply chain management particularly challenging yet critical. We discussed the need for standards to communicate information across organizational boundaries, the clash between traditional hardware procurement and modern software practices, and how tracking components in both domains presents parallel challenges. The fireside chat highlighted practical experiences in bridging the gap between software and hardware supply chain transparency, and the importance of ISO standards and industry collaboration in this evolving space.

This session demonstrated that whether dealing with software packages or physical train components, the fundamental challenges of transparency, traceability, and security have more in common than one might initially expect.