OSS + ELC EU 2026

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.