Events in room UD2.208 (Decroly)

Welcome and update on the logistics of the dev room

LF Energy SEAPATH is an open source, high-availability real-time platform designed for hosting virtualized protection and control applications within electrical substations. As a complex project bridging electrical and computer engineering, it integrates multiple open source tools and expertise from diverse domains. Following the recent release of version 1.0, the project undertook a refactoring of its documentation to improve clarity and accessibility for a growing community of users and contributors

This talk will present the documentation strategy for such a complex project, highlighting the challenges encountered and the solutions implemented. Key discussion points include:

• Balancing documentation across multiple platforms: Ensure consistency and reduce redundancy between Confluence, GitHub, and Ansible Galaxy
• Structuring the wiki: Organize the information for diverse audiences
• Establishing clear naming conventions: A consistent terminology for pages, concepts, and components.

Documentation is the backbone of successful projects, yet many tools fall short in balancing ease of use, collaboration, and flexibility. https://github.com/suitenumerique/docs is an open source, block-based editor designed to solve these challenges. Built by the French and German govs, it offers a snappy editing experience, real-time collaboration, fine-grained access control, and powerful features like sub-docs and a headless CMS API. This talk will demonstrate why Docs is the ideal tool for teams looking to create, manage, and scale their documentation effortlessly.

Sometimes you need to mark up what Markdown doesn’t. It’s tempting to pick up a heavyweight Markdown variant, such as MDX, or to build your own just-this-once extension. But extensions to Markdown are often eye-wateringly ugly, fragile, and prone to lock-in. What’s to be done, switch formats? No, you’re too busy for that.

In this talk, I’ll teach you about the little-used extension points that already exist in mainstream Markdown flavors, such as CommonMark, and how to take advantage of them before going off the beaten path. In this talk, you’ll learn about:

• The risks of inventing or adopting yet another Markdown variant
• Three extension points that you can start using today with your existing tools
• When deviating from Markdown can truly help

Daniel D. Beck is a documentation consultant who helps software engineering teams make tools, processes, and content that reach developer audiences. His talk draws from experience as a longtime contributor and maintainer of open source software and documentation, including as a current maintainer of Baseline, a browser compatibility tool, and a past role as technical content lead for MDN Web Docs.

Docling is an open source toolkit that simplifies document processing by converting various formats like PDFs and Word documents into structured, searchable data. It can handle complex layouts, tables, code, and formulas to preserve the meaning of the data and maintain the formats and relationships of the information. Find out how you might include Docling in your documentation workflow to emcompass diverse documentation sources and formats - including images and audio. As gen AI and LLMs are changing the way we document things and retrieve info, the importance of quality structured data cannot be understated.

You've perfected your Docs-as-Code pipeline. Your HTML documentation is beautiful, version-controlled, and deploys instantly. Then someone asks for a printing version. Printing? What is it? Ah, a primitive pre-HTML way of publishing, no problem... until you try it.

This talk addresses the fundamental mismatch between the web's fluid layout and the paged, fixed-layout world of print. After creating Asciidoctor to Open Document converter (https://github.com/CourseOrchestra/asciidoctor-open-document) I was so stuck in this mismatch that I nearly concluded print output from simple markup was just a toy, and that achieving quality was impossible.

Luckily, I found inspiration in Pandoc's architecture, which acts as a "metaconverter" -- a factory for building converters. Based on its ideas I completely rewritten Asciidoctor to Open Document converter into Unidoc Publisher (https://github.com/fiddlededee/unidoc-publisher). This worked excellently and now I can share my experience in this field.

I will then map the landscape of rendering solutions. We will compare the core options, which are limited to:

• native convertors relying on PDF libraries,
• Paged Media CSS,
• TeX (and all around),
• Text Processors Formats (OpenXML in MS Office, Open Document in LibreOffice).

There's no silver bullet, there is just a sensible path. Hope this talk will help to choose the right solution for your needs.

The addition of a new Extensions SDK in Superset led to a new initiative: a Developer Portal.

That, in turn, gave us the chance to re-imagine how we WANT our docs to work: • Bringing in scattered readmes/wikis/etc. under one roof • Creating independently versioned areas for different release cycles and intents • Automating screenshots and content to "keep up" with the codebase • Bringing API docs, React Story book, and more into a centralized interactive portal • Leveraging AI to build and maintain docs... for people AND for humans • Syndicating content from third party sources to be the end-all-be-all of Superset documentation • Leveraging AI (for free!) to provide chat-based support AND learn where our docs are falling short from the result

We've learned a lot of hard lessons over the years, and we're happy to share the process, ideas, and tools we've used to take things to the next level.

Documentation often lags behind code changes, leading to inconsistencies and outdated information. This session explores how to automate the generation of comprehensive and up-to-date documentation using a custom Yaml-based domain-specific language alongside Asciidoctor and Antora. By defining product behavior in a DSL, we not only produce the framework for software code but also generate the bulk of the documentation, making the DSL the single source of truth for the project. We'll discuss the power of this approach in keeping documentation aligned with the codebase and also demonstrate how to test code snippets within your documentation. Learn how this practice prevents broken examples and leverages Asciidoctor's capabilities to ensure your documentation remains reliable and accurate.

We introduce a workflow engine that automates and documents complex shell-based tasks in software development. By capturing command sequences as reproducible workflows, the tool reduces technical debt and significantly facilitates maintenance across long-lived projects.

Common use cases include wrapping Yocto and Buildroot builds, automating Linux kernel testing and debugging, and supporting routine IT, network, and infrastructure operations.

In this interactive talk, we demonstrate (live) how the tool:

• builds and documents a more general procedure of cross-compiling the Open Source Software firmware for Broadcom's bcm5719 NIC chip than currently available,

• automates generating PDF documentation of this procedure,

• facilitates sharing this procedure and its documentation in a public or commercial context.

Attendees will learn how to transform hard-to-follow shell scripts into reproducible workflows that produce better documentation and improve collaboration.

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' you need 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:

• Authoring – producing the initial SBOM from a lockfile
• Augmenting – resolving gaps and adding metadata to meet increasingly strict transparency requirements that SBOM generation tools can't do
• Enriching – improve the quality of the SBOM using open data sets
• Signing – provide attestation to ensure the SBOM can be trusted

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 demo a fully open-source workflow built with the sbomify action, a tool from sbomify that runs in GitHub Actions or any CI environment, enabling CRA-ready SBOM pipelines without proprietary tooling.

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.

Note: This talk is a follow-up to the session Software Supply Chain Strategy at Deutsche Bahn that puts an emphasis on the overall strategy and organizational implementation.

The open-source ecosystem, and quite prominently the Cloud Native Computing Foundation (CNCF), have matured to the point where proprietary vendors are increasingly challenged in the areas of keeping up with formalities and documentation, historically one of their key advantages. Innovations such as OCI attestations and Vulnerability Exploitability eXchange (VEX) go beyond metadata – they have the potential to fundamentally change how software is procured and evaluated. This talk explores the concept of shared responsibility in software security and quality, focusing on practical initiatives in Germany, including the container ecosystem, the openCode platform and its Badge Programme: transparent standards, verifiable provenance, and community-driven approaches can strengthen digital sovereignty, improve supply chain security, and reshape the way public sector organisations adopt and reuse software.

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 for embedded systems are harder than for typical apps: vendor HALs, out-of-tree modules, binary blobs... accurately capturing what actually ended up in the binary image deployed on your product is crucial for addressing future CVEs with confidence, as well as to comply with regulations such as CRA.

In this talk, I’ll show how Zephyr RTOS integrates SPDX-based SBOM generation into its CMake build system, and how we’re exploring SPDX 3 to describe things that aren’t just source code — build configuration, AI/ML artifacts, etc. — so that SBOMs for Zephyr-based products reflect the real security and compliance surface of the device, not just the code that was compiled.

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.

This presentation will explain how we built a tool that can create an SBOM for a Linux kernel build that describes the generated artifacts, the source files included and the build relations between them as an SPDX3 document. This is deduced from kernel specific build outputs. In our journey we overcame several hurdles and we want to share what we learned.

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.

Functional safety is crucial for open-source components used in safety-critical domains like automotive, medical, and industrial control. However, the current practice for managing the Safety Case—the collection of documents (requirements, tests, analyses, and evidence) proving compliance with standards like IEC 61508 or ISO 26262—is manual, chaotic, and inefficient. These artifacts are often fragmented across proprietary lifecycle systems, spreadsheets, or PDFs, leading to broken traceability and overwhelming manual effort in the supply chain. This talk introduces the SPDX Functional Safety Profile, a critical extension built on the upcoming SPDX 3.1 specification. We will demonstrate how this profile moves the entire Safety Case into a single, standardized, and machine-readable exchange format. The profile achieves this by introducing new classes beyond the SPDX Core: - REQUIREMENT: Capturing functional, non-functional, and design needs. - VERIFICATION: Defining specifications for tests, reviews, and analyses. - EVIDENCE: Storing test reports, build logs, and compliance evidence. Attendees will learn how to use machine-readable relationships to trace requirements through the V-Model, connecting code, design documents, and test results automatically. This profile is the key to building an automated, auditable, and tool-agnostic safety documentation pipeline, finally delivering the ability to exchange comprehensive Safety SBOMs across complex, multi-party supply chains.

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.