# FOSDEM 2026 devroom proposal

Full proposal content:

## Proposal title:
Software Bill of Materials (SBOM) devroom

## Notes:
This devroom has run the last three years with great success, and we want to host it again in 2026. The number of submissions we received in our CfP in past years was enough to cover almost double the time allocated (full day)! We even made the decision to reject all tool-specific presentations, pushing them to a fringe event. We essentially accept presentations on the common problems and solution approaches, which is very much aligned with the "promoting collaboration and community between different projects" mentioned in this year's call for DevRooms. Our plan is to make this clear in our devroom info and Call for Participation.
Every year we ran almost the whole day Sunday in full room capacity --- 100 seats in H.2213 (2025), 76 seats in K.4.401 (2024), 96 seats in UB4.136 (2023).

## Language:
en

## Why does this proposal fit FOSDEM:
Having a Bill of Materials for software deliveries is becoming more and more important, or even crucial. Security and regulatory obligations, like the recent CRA and AI Acts of EU, require both producers and consumers of software to have a complete and accurate knowledge of all components in a software package. Besides the well-known and understood problem of listing software components and their metadata such as licensing and security-related information, the field of Bill of Materials is constantly facing new challenges. AI-related software is becoming more and more common, and this changes the fundamentals of how we are thinking about software: it is built not only from source code, but also from processing of datasets. In this case there is, therefore, need to record what datasets were used, how the processing was done, and so on. The field is very much open right now and lots of people/teams are working on these issues, both from the requirements/standardization side and the implementation/tools side. We believe that open discussion on all these aspects is important for the Free Software community and FOSDEM provides a perfect venue for it. The success of the SBOM devrooms in the last years attests to the high interest of both presenters and audience. It should be noted that, although related discussions and individual presentations happen in various places, this devroom has been the single event dedicated to the specific problem and the community knows it and anticipates it every year.

The Software Bill of Materials (SBOM) landscape continues to evolve at an unprecedented pace, making the dedicated SBOM devroom more essential than ever for the FOSDEM community. The intersection of regulatory compliance, emerging technologies, and supply chain security has created a perfect storm of challenges that demand focused community attention and collaboration.

The regulatory environment has reached a critical inflection point since our last gathering. The EU's Cyber Resilience Act implementation is now in full swing, with organizations scrambling to meet compliance deadlines that seemed distant just months ago. What was once theoretical regulatory pressure is becoming concrete legal obligations, with real penalties for non-compliance. Simultaneously, similar frameworks are materializing worldwide, from updated NIST guidelines in the United States to emerging standards in Asia-Pacific regions. The Free and Open Source Software community finds itself at the center of these requirements, needing practical guidance on how to maintain the collaborative, transparent nature of FOSS development, while satisfying increasingly complex documentation and traceability demands.

The technical challenges facing SBOM practitioners have expanded far beyond the traditional scope of listing software components and their licensing information. The explosive growth of artificial intelligence and machine learning components in everyday software has fundamentally altered how we think about software composition. Modern applications increasingly incorporate AI models trained on vast datasets, creating new categories of dependencies that existing SBOM frameworks struggle to capture. Questions around training data provenance, model versioning, bias documentation, and AI-specific vulnerability tracking represent entirely new frontiers that the community must address collectively.

Supply chain security incidents continue to demonstrate the critical gaps in our current approaches to software transparency and verification. The community needs dedicated time and space to discuss and develop more robust, security-focused approaches that can withstand these evolving threats while remaining practical for everyday development workflows.

The SBOM devroom has established itself as the premier venue where these diverse challenges converge and where the community develops practical solutions. Unlike scattered discussions in various security, legal, or development-focused venues, this devroom provides the unique combination of technical depth, regulatory awareness, and practical focus that this rapidly evolving field demands. The success of previous SBOM devrooms has demonstrated the community's need for this specialized forum, with consistently high attendance and engagement from participants ranging from individual developers working on personal projects to enterprise architects managing complex software portfolios to policy makers crafting the next generation of software regulations.

## Prefered slot:
Full day (any)

## Submitters affinity to the topic:
I was one of the people involved with running the same SBOM in the previous years; my co-organizers have also indicated that they are willing to serve again. I have been deeply involved in SBOM topics for more than a dozen years, both as a volunteer and as an employee. Part of my day job is implementing such infrastructure in Intel. I am also part of the relevant community and know personally most of its members. I participate in the SPDX Steering Committe, I co-chair its Technical team and participate in its Legal and Outreach teams (SPDX being the international standard for SBOMs). I also participate in numerous other efforts related to SBOMs (e.g. OpenSSF, OpenChain, etc.)

## Relevant URLS:
https://archive.fosdem.org/2025/schedule/track/sbom/
https://archive.fosdem.org/2024/schedule/track/software-bill-of-materials/ https://archive.fosdem.org/2023/schedule/track/software_bill_of_materials/ https://spdx.dev/

## Special Requirements:
None