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

Kraken is Uber's open-source P2P container registry. It serves 23 petabytes of data daily with 99.9% reliability. However, during recovery from a complete regional failure, Kraken was pushed over its historical peak load by 10 times. It had to distribute over 100,000 container images every minute. The registry that "just worked" became the bottleneck blocking disaster recovery.

Adding capacity proved insufficient. So, the team reworked the caches and tuned download parallelism. But closing such a large performance gap required architectural changes. If downloads are too slow, move the data closer to the client. If you cannot serve everything at once, tier images by criticality. These optimizations eventually broke Uber’s deployment throughput record.

This talk presents a case study of evolving Kraken to deliver 10x performance under extreme load - the architectural changes, necessary trade-offs, and hard-won lessons. All optimizations are open-sourced in Kraken.

Managing vulnerabilities across large fleets of container images remains a persistent challenge in cloud-native environments. In our platform, patching a single critical image often required several engineer-days of manual effort, creating remediation backlogs and compliance risk.
To address this, we built a self-healing vulnerability remediation pipeline using open source technologies across the container lifecycle. This session presents the architecture behind the system, including automated dependency updates with Dependabot, reproducible image rebuilds with DALEC, continuous OS-level patching using Project Copacetic, and deployment validation through staged rollout pipelines.
We will share the engineering decisions, trade-offs, and lessons learned while reducing remediation time from days to minutes and eliminating approximately 90% of manual patching effort. We will also discuss integrating an AI-assisted remediation agent for complex fixes and the safeguards used to validate and govern AI-generated changes in production environments.

When a CI/CD pipeline runs each step as a separate Kubernetes Pod, those Pods need a way to pass data to one another. Tekton chose the obvious Kubernetes-native answer: a shared persistent volume. Clone code in step one, build it in step two, both read from the same disk. Simple.

It wasn't. Shared volumes meant pinning Pods to the same node, which broke autoscaling. Users hit storage limits, leaked volumes after failures, and spent more time debugging infrastructure than building pipelines. Each fix created new edge cases.

Then a different question: what if steps didn't share a disk at all? What if each step uploaded what it produced, and the next downloaded and verified it, with cryptographic hashes at every handoff? That's Trusted Artifacts. The shared volume disappears, and in its place you get a verifiable chain of trust: every handoff is hashed, signed, and traceable. A storage problem became a security feature.

This talk traces that journey: the design that seemed right, the years of workarounds, and the moment the team stopped fixing the plumbing and rethought the architecture. It's for anyone who's wondered whether to keep patching a leaky abstraction or tear it out.

Research data repositories and software package registries serve different audiences, but they answer the same four questions:
- who published this and can we trust them
- has it been tampered with
- where did it come from
- how long will it stay available and verifiable?

Both communities have answered them in parallel, different vocabularies, different tooling, little exchange.

This talk maps that exchange both ways, grounded in my work on Djehuty (behind 4TU.ResearchData) and as a maintainer of TUF and in-toto and an OpenSSF Securing Software Repositories contributor.

Data repositories can borrow from software: delegated, verifiable signing (TUF, Sigstore), in-toto provenance for AI training data, and the OpenSSF security-maturity model.

Software registries can borrow from data: FAIR's verifiable provenance, persistent identifiers (DOIs, ORCIDs) for durable SBOMs, OAIS preservation against dependency rot, and pre-publication curation.

It closes on the problem neither has solved: permanence versus incident response revoking trust without deleting an immutable, citable record.

Who secures the teams building open source security tooling? At Open Source & Security Africa (OSSAfrica) — a Linux Foundation Special Interest Group supporting the pan-African open source ecosystem — we asked that exact question and built the answer into our pipelines.
This lightning talk walks through the CI/CD architecture powering OSSAfrica's projects: GitHub Reusable Workflows for DRY, composable pipelines across repositories; CodeQL and Semgrep running automated SAST on every PR; and Cloudflare Pages and Render handling deployments with zero operational overhead for a volunteer-driven team.
The core argument: supply chain security isn't a luxury reserved for enterprise platforms. With the right reusable workflow patterns, a lean community team can ship with the same security guarantees as a well-staffed engineering org — and share those patterns across every project they maintain.
Attendees leave with a concrete, replicable blueprint for community-scale secure CI/CD, and a fresh perspective on what open source infrastructure looks like when it's built from and for the African tech ecosystem.

The Shai Hulud worm family has stalked the npm supply chain across multiple variants, stealing credentials from developer and CI environments, propagating via stolen npm and GitHub identities, poisoning workflows, and carrying a dead switch that can wipe home directories on command. Version four just crossed a new line. SANDWORM_MODE, deployed across 19 malicious npm packages, keeps the full prior playbook and adds AI toolchain poisoning via MCP server injection into Claude Code, Claude Desktop, Cursor, and Windsurf. The rogue MCP server uses prompt injection to instruct AI assistants to silently exfiltrate SSH keys, AWS credentials, and LLM API tokens from nine providers, without alerting the user. We present the full story: the Shai Hulud lineage, how the obfuscated three-layer loader was detected, how 19 packages were linked to one operator, how a bidirectional CI worm loop was built from a weaponized GitHub Action, and how coordinated takedown with npm, GitHub, and Cloudflare dismantled the infrastructure, along with what the dormant polymorphic engine tells us about where version five is heading.