Bill of Delivery, OCM und NixOS: Wessen Problem ist das eigentlich?
Auf appetizers.io ist ein Artikel erschienen, der „Software Bills of Delivery“ als nächste SBOM-Generation positioniert. Ole hat das auf seinem persönlichen Blog ausführlich aufgegriffen — über das Open Component Model, NixOS+Podman und die Frage, warum die Composition-Lücke primär ein K8s-Phänomen ist. Hier eine Kurzfassung mit Link zum Originaltext.
Wessen Problem ist Composition eigentlich?
Auf appetizers.io ist kürzlich ein Artikel erschienen, der „Software Bills of Delivery“ als nächste Evolutionsstufe nach klassischen SBOMs positioniert — und das Open Component Model (OCM) als zentrales Werkzeug. Die Composition-Lücke ist real: SBOMs beschreiben einzelne Container, nicht aber die Komposition eines Releases.
Ole hat den Artikel auf seinem persönlichen Blog ausführlich kommentiert. Kurzfassung: Das Problem ist real, OCM löst es sauber — aber primär als Folge der Designentscheidungen von Kubernetes. In einem NixOS-/Podman-Setup, wie wir es bei Moselwal selbst betreiben, ist Composition Nebeneffekt der Konfiguration und kein separates Bundle-Format.
Was überall zählt und was Auditoren in ISO-27001- oder TISAX-Kontext tatsächlich abfragen: SLSA-Provenance pro Image, OpenVEX für Vulnerability-Hygiene, signierte Images mit Cosign und Verify-on-Deploy. Die etablierten Akronyme.
Den vollständigen Post lesen
Die ausführliche Auseinandersetzung mit Bill-of-Delivery, OCM und NixOS — inklusive konkreter Bausteine, einer ehrlichen Abwägung wann OCM sich lohnt und Diskussion der Grenzen jedes Ansatzes — gibt's auf Oles persönlichem Blog.
Wenn Sie eine konkrete Pipeline-Frage haben, melden Sie sich direkt bei uns über die Kontaktseite.