OSS + ELC EU 2026

Package updates across multiple architectures and long-term release branches complicate pipeline testing. Source-level tests usually pass during a package upgrade, missing Application Binary Interface (ABI) changes that later break downstream images and containers at runtime.

This talk introduces an extension to meta-binary-audit [1] that adds automated binary analysis to release CI pipelines for Yocto environments. Integrating libabigail into the pipeline reports exactly what changed in the binary interface before code is released.

The session details the CI architecture, parallel binary audits across multiple architectures, and how to track symbol-level ABI changes during LTS uplifts, using the migration from Scarthgap to Wrynose as an example. Attendees will leave with practical methods to analyze these interface changes, evaluate compatibility across releases, and prevent broken downstream images.

[1] https://github.com/Nordix/meta-binaryaudit/

This isn't just about Airtel but for every organisation as multi-arch OCI manifest list lets one image tag resolve to different binaries per architecture, teams treat that tag as a single security unit, yet the amd64, arm64 & riscv64 builds underneath frequently diverge, a base-image bump, a differently resolved dependency version or missing backport can leave one architecture patched against CVE while another silently isn't & no scanner today compares SBOMs across the architectures inside same manifest list, each platform image is scanned in isolation & reported as N separate, ostensibly fine results. Talk introduces manifest-list-aware SBOM differ that pulls every per-architecture image inside tag, generates SBOM for each & diffs them against each other rather than against historical baseline, flagging any package, version or vulnerability status that differs across architectures sharing same tag, the same Dockerfile & same assumed security posture across every platform it claims to support. We show this catching real drift in popular base images, demo CI gate that blocks a push when architectures diverge unexpectedly & discuss how it slots into existing signing pipelines.

Container image signing, SBOMs, SLSA attestations.... five years ago, the Kubernetes project was a trailblazer securing its releases using these and other security features. Having developed its own tools and solutions, things "just worked" for the project, but security technologies evolve and so have we.

Join us as as we dig deep to explore and compare the metadata the project started producing in 2021 with how modern supply chain tools expect them today.

During this talk, we'll do an overview of the updates and modernization of the Kubernetes secure build process and tools. We will examine visually the quality improvements to the Kubernetes SBOMs, how we migrated the SLSA provenance we use to gate our releases to SLSA v1, signing into Sigstore bundles, and, most importantly, how the the toolchain built by K8s Release Engineering enables more than a hundred independently managed projects under the Kubernetes umbrella to build and ship security features to protect themselves and their users.

Out tooling is available for anyone so perhaps we can inspire you to to the same for your projects!

Somewhere along the way, the security ecosystem started asking maintainers to add more steps, update more plugins, and generate more outputs, without asking what it costs them. At cdCon, the OpenSSF DevRel community ran two back-to-back sessions to fix that: first an open, no-pitches roundtable where practitioners told us where tools miss the mark, then a maintainer lightning round where the people who could act on that feedback were already in the room.

This talk distills what came out of both. We'll cover the adoption gap (lots of awareness, far less implementation), why a year on this community still doesn't trust the SBOMs it generates, the recurring "I have one security engineer — where do I start?" problem, and the confusion created by too many badges and not enough wayfinding. Then we'll show how a wave of OpenSSF projects — from gittuf and Sigstore to OpenVEX, SBOMit, and the OSPS Baseline — are responding, including where there is work to do.

Modern software projects depend on hundreds of third-party libraries, making reproducible and secure builds increasingly difficult. However, Maven, one of the most widely used Java build tools, has no native lockfile support. This leaves projects exposed to version drift, tampered artifacts, and dependency confusion attacks, while making hermetic builds difficult to achieve.

Maven-lockfile addresses this by generating a cryptographic record of all resolved artifacts, including transitive dependencies, and validating them on every build. This enables frozen dependency sets for exact historical reproducibility. In collaboration with Red Hat, we extended maven-lockfile to systematically capture build extensions, BOMs, and other dynamically fetched artifacts required for hermetic builds, and compare it against Maven-native approaches like Trusted Checksums.

To complete the workflow, we demo maven-lockfile alongside Hermeto, a CLI tool that pre-fetches dependencies into a local cache, enabling fully network-isolated builds.

When you run pip install numpy, pip downloads a pre-built binary someone else compiled. For most developers that's fine, but in regulated environments or anywhere supply chain integrity matters, it's a gap one that incidents like the LiteLLM PyPI compromise and fake DeepSeek packages have made harder to ignore.

There's a bootstrapping problem too: building numpy needs setuptools, and building setuptools needs… setuptools. Every existing tool pip, uv, conda breaks this cycle by quietly downloading pre-built binaries. None give you a unified view of the full dependency tree, making it hard to audit what was built, from where, and in what order.

This talk walks through an unsolved problem in Python packaging bootstrapping entire dependency trees from source and how Fromager tackles it using PEP 517. We'll cover:

1. Why pip install --no-binary :all: doesn't get you to "built from source"
2. Where pip, Nix, Spack, and Bazel each fall short
3. The two-stage discover/build split and the JSON artifacts it produces for auditing
4. Why building packages as collections keeps them ABI-compatible critical for stacks like PyTorch with CUDA/ROCm native code