Imagine you buy lunch at the corner of the street every day. It's fast, it's cheap and it tastes great. Where the ingredients came from or who prepared it, you don't know. Most days that's fine. Until the day you get sick and can't trace it back to anything. Food solved this decades ago with labels, inspected kitchens, known handlers and recalls. Software now has its label too: the Cyber Resilience Act makes the SBOM mandatory. Many of us will generate one, file it and move on. But a label on a kitchen nobody inspected tells you very little.

Here is the uncomfortable part for our own community. Open source is the only model where every station of the supply chain can be inspected, and we barely use that strength. Most of us still pull images from public registries and trust dependencies nobody in the room has read. xz showed how close we came: one exhausted maintainer, years of patient social engineering, and a backdoor found because a login took half a second too long. With the Open Build Service and the SUSE Application Collection as worked examples, this talk shows what running every station properly looks like: preserved source, reproducible builds, known packagers and patches that travel back through the same chain. Only then does the SBOM become proof of something.

It closes with four questions any team can answer this week, one for every station of the chain: Where did it come from? Who built it? How did it reach us? Who fixes it when it breaks?

Governments are rewriting digital sovereignty checklists around servers and cloud providers, but rarely ask who controls the pipe that delivers the software itself. This talk uses the 2025 cutoff of ICC prosecutor Karim Khan's Microsoft email as a lens on a structural blind spot in open source: centralized package distribution. It introduces FAIR (Federated and Independent Repositories) and asks what it would take to make Drupal, WordPress, TYPO3 and similar ecosystems resilient to a single point of legal or technical failure.