High-level: what's this even about?

Imagine you're delivering software. That software consists of several parts — an application, a reverse proxy in front of it, perhaps a scheduler, a key-value store, a few configuration files. During an audit or a security incident, you want to be able to answer: What's inside each individual part? That's the classic SBOM — Software Bill of Materials. List of all libraries, licenses, versions. Who built it and how? That's provenance, keyword SLSA. Which commit, which runner, which inputs. Which parts in which versions belong to Release 2.4.0, atomically as a set? That's the composition — and this is exactly where the Bill-of-Delivery discussion comes in. Point 3 is the interesting one. An SBOM describes what's inside a container. But it says nothing about which containers in which versions make up a particular release. That's exactly the gap concepts like the Open Component Model (OCM) try to close. But: this gap doesn't exist everywhere equally. It's primarily a consequence of K8s' design decisions — not a bug, but a result of the requirements K8s was optimized for: dynamic systems, independently versioned deployments, decentralized composition as a deliberately chosen architecture. Why K8s structurally has the composition gap A typical K8s deploy is conceptually fragmented — and for good reasons. K8s is built for dynamic systems with independently versioned components; composition is deliberately distributed so that operator lifecycles, service updates, and cluster platform components don't have to move in lockstep. In concrete terms: Container images live in one registry, with tags that are mutable and can drift over time. Helm charts live in another registry or chart repo. values.yaml and overrides live in a GitOps repo. ConfigMaps and secrets are injected through external mechanisms (External Secrets Operator, Vault Agent Injector, whatever). CRDs and operator versions have their own lifecycles. Service mesh configuration lives in yet other repos. Ingress routing comes from cluster platform charts. There's simply no single place that authoritatively states: this is Release X, here are all its components with their digests, signed as one atomic unit. Helm tries, but only covers its subcharts. Flux/Argo work at the GitOps level, not the artifact level. Tags drift, ImagePullPolicy varies, operators are versioned outside app releases. From this deliberate decentralization, a real need arises for a bundle layer that “binds it all together atomically” — when you want to roll out releases as closed units or promote them between environments. OCM positions itself exactly there. It's more than just a transport format — it defines a descriptor and a reference model for how components express their artifacts, provenance, and cross-component references. Conceptually well done. The need is legitimate, the solution holds up. What NixOS + Podman does structurally differently We know both worlds. With customers, we operate K8s clusters and work in exactly the tooling landscape I sketched above — composition fragmentation isn't a theoretical problem for us, it's daily business. For our hosting infrastructure operated with German hosters, we've deliberately chosen multiple NixOS VPS with Podman instead. This isn't a value judgment on the platforms, but a different architectural choice with different tradeoffs. What's interesting: what shows up as a separate tooling problem in the K8s context is a side effect of the configuration in the NixOS context. A NixOS container definition looks roughly like this: virtualisation.oci-containers.containers.app = { image = "registry.example.com/app@sha256:abc123..."; ports = [ "127.0.0.1:8080:8080" ]; environment = { ... }; dependsOn = [ "kv-store" "scheduler" ]; }; virtualisation.oci-containers.containers.proxy = { image = "registry.example.com/proxy@sha256:def456..."; # ... }; Three properties stand out immediately: Digest pinning is the default. You can use tags, but for production you write digests. Tag drift is constructively excluded — not by discipline or a Renovate bot. Composition lives in the same file as everything else. Configuration, firewall rules, systemd units, reverse proxy, backup timers, TLS certificates — all in one language, one evaluation step. No “coordinating between three tools”. nixos-rebuild is atomic. Either the entire new generation activates, or the old one stays. Rollback is a boot menu entry, not a contraption with footnotes. With one limitation that's fair to mention: Nix describes the desired state, not the actual runtime state. External dependencies — SaaS APIs, third-party-managed services, databases outside the configuration — fall outside the model. What Nix gives you is a very clean, deterministic description of the build and deploy layer. The runtime truth still has to be uncovered through observability — but that applies to any stack. In our context, the tuple of release module (with the container set configuration) and flake.lock, versioned in Git and signed, is the more complete form of composition — because it's simultaneously the deployment truth, not just its description. What OCM additionally offers — cross-registry distribution, airgap transport, multi-cluster promotion — we don't need at this point. In a K8s context with distributed targets, the calculation would come out differently. What you still need — regardless of K8s or NixOS This is often abstracted incorrectly: “if I have Nix, I don't need DevSecOps anymore.” Wrong. Nix solves the composition layer. The other layers remain unchanged in their relevance. SLSA provenance per image For each container build, your pipeline produces an in-toto statement with predicate type slsa.dev/provenance/v1. It documents: which commit was built, on which runner and with which builder image, which inputs went into the build (resolvedDependencies). Important: the base image belongs in those inputs — as a digest, not a tag. This creates a verification chain you can trace back during an audit: App-Provenance ─ baseImage: php-base@sha256:xyz │ └── own provenance ─ baseImage: wolfi-base@sha256:... │ └── ... Attach to the image via cosign attest --type slsaprovenance. This is the lower layer of the supply chain, and it's orthogonal to your deployment model. Image signing with Cosign With self-hosted GitLab, keyless Sigstore is currently not an option (the Sigstore Public Good trust root expects an OIDC identity that works cleanly for gitlab.com but doesn't establish trust for self-managed instances out of the box). So key-based signing with short-lived build keys from Vault. Every image that goes into the production registry is signed. OpenVEX for vulnerability hygiene Wolfi images are extremely lean, but Trivy/Grype still regularly report CVEs in transitive libraries whose vulnerable code paths aren't even reached. Instead of documenting that in a Confluence doc or a ticket system, you write OpenVEX statements: signed, machine-readable, in the OCI registry as an attestation alongside the image. Per CVE, one clear statement — affected, not_affected with justification, fixed, under_investigation. This massively reduces audit noise and is exactly the mechanism that's missing from a pure SBOM check. For ISO 27001 or TISAX, it's worth gold, because an auditor no longer has to ask “why is this high CVE open for three weeks”, but reads “not affected, because X” with signature and date. System SBOM from the Nix closure A Nix derivation is essentially a very precise component description — content-addressed, deterministic, with a complete closure graph. Tools like genealogos export this to CycloneDX. For our NixOS hosts, that means: a system SBOM falls out almost as a by-product — and the reproducibility is real, not claimed. With one caveat: a Nix closure SBOM isn't one-to-one equivalent to a classically maintained SBOM. License metadata, maintainer fields, and a few other standard attributes don't come along automatically; depending on audit requirements, you have to supplement them from Nix package definitions or fill them in via additional tools. Doable, but not a free ride. Verify-on-deploy The most important step that often gets forgotten: what isn't verified isn't signed. In the NixOS stack, the nixos-rebuild path lends itself well — a cosign verify as a build step ensures that a configuration referencing an image that doesn't validate against the signature key fails the build. Production hosts only get configs that have already passed the verify step. In the K8s context, the equivalent place is Kyverno or the Sigstore Policy Controller — admission webhooks that reject unsigned images at scheduling time. Mechanically different, semantically identical: what isn't signed doesn't run.

The honest assessment: when does OCM pay off?

I don't consider OCM marketing fluff. It solves a real problem — just not mine. Concretely, it pays off when: you have to atomically transfer multi-artifact releases between registries (build registry → customer cluster registry, or region A → region B), you're operating in a K8s world where composition fragmentation is real, you have cross-cluster promotion workflows that get painful with plain helm upgrade. It doesn't pay off when: your composition already lives in a deterministic configuration language (Nix, Bazel rules, Cue configs), you have exactly one registry from which you deploy, you've already cleanly solved the “composition as first-class artifact” property by other means. Concretely, this means two different answers for us depending on the context: in customer K8s setups, OCM is a building block worth examining — especially when multi-artifact promotion between environments or cross-registry transfer becomes a topic. For our own NixOS infrastructure, we solve the composition property differently, without having to introduce an additional bundle format. Both answers are clean in their respective contexts. What I take from the original article Terminology hygiene matters. “Software Bill of Delivery” is not an established standard — neither NTIA, nor CISA, nor OWASP, nor CNCF use the term. That's not a reproach to an author who uses it as a descriptive umbrella term. But anyone who adopts it in formal external communication or with auditors makes interoperability unnecessarily hard. The established acronyms are SBOM, SLSA, in-toto, VEX, Sigstore. Auditors recognize them. That's why I use them in my own documentation as well. Take the mental model anyway. Atomic composition with a provenance chain is the right mental lens — regardless of the tooling you implement it with. With NixOS, it's release modules plus flake.lock plus signed images with provenance. With K8s, it's OCM or a self-built manifest plus Sigstore. The properties are the same, the tools are different. DevSecOps architecture is architecture. Many tooling necessities disappear when you choose the architecture one layer down correctly. That's not an argument against K8s — there are good reasons for cluster platforms, and scaling needs is one of them. But it is an argument against choosing K8s because “everyone uses it” and then having to engage with the associated tooling landscape, when the actual requirements don't call for it. Take-away The question isn't “do I need a Bill of Delivery?” The question is: “where does my stack already bring the composition property along, and where do I have to add it on?” In K8s, add it on — through bundle formats, Sigstore policies, GitOps discipline. In NixOS hosts with Podman, it's there as a side effect — all that's left is making it visible and signed. Provenance per image, OpenVEX for audit hygiene, and verify-on-deploy remain mandatory in both worlds. The rest depends on which composition problem your stack has handed you — or spared you from. Both paths are legitimate. K8s with OCM or an equivalent bundle layer is a consistent answer to a consistent problem. NixOS with Podman is a different — not superior — answer that resolves the problem at a different point. What counts isn't the choice itself, but that the properties end up cleanly in place: atomic composition, traceable provenance, signature, verification. Which path leads there depends on the stack, the team, the customer, the scaling requirements. That's exactly why I find engagements like the one with the Appetizers post valuable: not to be right, but to more clearly name the properties we're all trying to achieve — and to see how many different paths can lead there.

Bill of Delivery — oder: Wessen Problem ist das eigentlich?

Eine SBOM beschreibt, was in einem Container steckt. Aber welche Container in welchen Versionen ein Release ausmachen — das ist eine andere Frage. Über Composition, das Open Component Model, NixOS+Podman und die Frage, warum die Bill-of-Delivery-Diskussion stark aus dem K8s-Ökosystem heraus geprägt ist.

3. Mai 2026

Drei einzeln versiegelte Holzkisten neben einer größeren versiegelten Sammelkiste auf einer Holzwerkbank im warmen Nachmittagslicht.

Vor wenigen Tagen ist auf appetizers.io ein Artikel von Matthias Bruns erschienen — Software Bills of Delivery: Beyond SBOMs with Component Models —, der das Open Component Model (OCM) als nächste Evolutionsstufe nach klassischen SBOMs positioniert. Der Post ist lesenswert, weil er ein reales Problem adressiert: Eine SBOM beschreibt, was in einem einzelnen Container steckt, sagt aber nichts darüber, welche Container als Set zu einem Release gehören.

Ich komme bei der vorgeschlagenen Lösung zu einer anderen Schlussfolgerung als der Autor — weniger, weil ich OCM für falsch halte, sondern weil ich die Frage anders stelle: nicht „wie löse ich das Problem“, sondern „wo habe ich es überhaupt?“. Mein Eindruck ist, dass die ganze Bill-of-Delivery-Diskussion stark aus dem K8s-Ökosystem heraus geprägt ist und sich verändert, sobald man eine Schicht tiefer schaut.

Diesen Punkt finde ich interessant genug für einen Post, weil er etwas Größeres beleuchtet: Wie viele unserer „DevSecOps-Tooling-Notwendigkeiten“ sind eigentlich Antworten auf Probleme, die wir uns durch unsere Architekturwahl selbst geschaffen haben?

High-Level: Worum geht's überhaupt?

Stell dir vor, du lieferst Software aus. Diese Software besteht aus mehreren Teilen — eine Anwendung, ein Reverse-Proxy davor, vielleicht ein Scheduler, ein Key-Value-Store, ein paar Konfigurationsdateien. Beim Audit oder beim Sicherheitsvorfall willst du beantworten können:

Was steckt in jedem einzelnen Teil? Das ist die klassische SBOM — Software Bill of Materials. Liste aller Bibliotheken, Lizenzen, Versionen.
Wer hat es wie gebaut? Das ist Provenance, Stichwort SLSA. Welcher Commit, welcher Runner, welche Inputs.
Welche Teile in welcher Version gehören zu Release 2.4.0, atomar als Set? Das ist die Composition — und genau hier setzt die Bill-of-Delivery-Diskussion an.

Punkt 3 ist der spannende. Eine SBOM beschreibt, was in einem Container steckt. Sie sagt aber nichts darüber, welche Container in welchen Versionen ein bestimmtes Release ausmachen. Genau diese Lücke versuchen Konzepte wie das Open Component Model (OCM) zu schließen.

Nur: Diese Lücke existiert nicht überall gleich. Sie ist primär eine Folge der Designentscheidungen von K8s — kein Bug, sondern Konsequenz aus den Anforderungen, für die K8s optimiert wurde: dynamische Systeme, unabhängig versionierte Deployments, dezentrale Composition als bewusst gewählte Architektur.

Warum K8s die Composition-Lücke strukturell hat

Ein typischer K8s-Deploy ist konzeptionell zerrissen — und das aus guten Gründen. K8s ist für dynamische Systeme mit unabhängig versionierten Komponenten gebaut; die Komposition ist bewusst dezentral angelegt, damit sich Operator-Lifecycles, Service-Updates und Cluster-Plattform-Bestandteile nicht synchron bewegen müssen.

Konkret bedeutet das:

Container-Images leben in einer Registry, mit Tags, die mutable sind und über die Zeit driften können.
Helm-Charts liegen in einer anderen Registry oder einem Chart-Repo.
values.yaml und Overrides leben in einem GitOps-Repo.
ConfigMaps und Secrets werden über externe Mechanismen injiziert (External Secrets Operator, Vault Agent Injector, was auch immer).
CRDs und Operator-Versionen haben eigene Lifecycles.
Service-Mesh-Konfiguration liegt in nochmal anderen Repos.
Ingress-Routing kommt aus den Cluster-Plattform-Charts.

Es gibt schlicht keinen einzelnen Ort, der verbindlich sagt: Das ist Release X, hier sind alle seine Bestandteile mit ihren Digests, signiert als atomare Einheit. Helm versucht das, deckt aber nur seine Subcharts ab. Flux/Argo arbeiten auf GitOps-Ebene, nicht auf Artefakt-Ebene. Tags driften, ImagePullPolicy variiert, Operatoren werden außerhalb der App-Releases versioniert.

Aus dieser bewussten Dezentralisierung entsteht ein echter Bedarf nach einem Bundle-Layer, der „all das atomar zusammenbindet“, wenn man Releases als geschlossene Einheiten ausrollen oder zwischen Umgebungen promoten will. OCM positioniert sich genau dort. Es ist mehr als nur ein Transport-Format — es definiert einen Descriptor und ein Referenzmodell dafür, wie Komponenten ihre Artefakte, Provenance und Cross-Component-Referenzen ausdrücken. Konzeptionell sauber gemacht. Der Bedarf ist legitim, die Lösung trägt.

Was NixOS + Podman strukturell anders macht

Wir kennen beide Welten. Bei Kunden betreiben wir K8s-Cluster und arbeiten dort in genau der Tooling-Landschaft, die ich oben skizziert habe — die Composition-Fragmentierung ist für uns kein theoretisches Problem, sondern Alltagsgeschäft. Für unsere bei deutschen Hostern betriebene Hosting-Infrastruktur haben wir uns dagegen bewusst für mehrere NixOS-VPS mit Podman entschieden. Das ist keine Wertung der Plattformen, sondern eine andere Architekturwahl mit anderen Tradeoffs. Was dabei interessant ist: Was im K8s-Kontext als separates Tooling-Problem auftaucht, ist im NixOS-Kontext Nebeneffekt der Konfiguration.

Eine NixOS-Container-Definition sieht in etwa so aus:

virtualisation.oci-containers.containers.app = {
  image = "registry.example.com/app@sha256:abc123...";
  ports = [ "127.0.0.1:8080:8080" ];
  environment = { ... };
  dependsOn = [ "kv-store" "scheduler" ];
};

virtualisation.oci-containers.containers.proxy = {
  image = "registry.example.com/proxy@sha256:def456...";
  # ...
};

Drei Eigenschaften fallen direkt ins Auge:

Digest-Pinning ist Default. Du kannst Tags nutzen, aber für Production schreibst du Digests. Tag-Drift ist damit konstruktiv ausgeschlossen, nicht durch Disziplin oder einen Renovate-Bot.

Composition lebt in derselben Datei wie alles andere. Konfiguration, Firewall-Regeln, systemd-Units, Reverse-Proxy, Backup-Timer, TLS-Zertifikate — alles in einer Sprache, einem Evaluation-Schritt. Kein „abstimmen zwischen drei Tools“.

nixos-rebuild ist atomar. Entweder die ganze neue Generation aktiviert sich, oder die alte bleibt. Rollback ist ein Boot-Menü-Eintrag, keine Hilfekonstruktion mit Sternchen.

Mit einer Einschränkung, die fair zu nennen ist: Nix beschreibt den gewünschten Zustand, nicht den tatsächlichen Runtime-Zustand. Externe Abhängigkeiten — SaaS-APIs, drittpartei-gemanagte Services, Datenbanken außerhalb der Konfiguration — fallen nicht ins Modell. Was Nix gibt, ist eine sehr saubere, deterministische Beschreibung der Build- und Deploy-Schicht. Die Runtime-Wahrheit muss man weiterhin über Observability erschließen — das gilt aber für jeden Stack.

In unserem Kontext ist das Tupel aus Release-Modul (mit der Container-Set-Konfiguration) und flake.lock, in Git versioniert und signiert, die vollständigere Form der Composition — weil es zugleich die Deployment-Wahrheit ist und nicht nur ihre Beschreibung. Was OCM zusätzlich anbietet — Cross-Registry-Distribution, Airgap-Transport, Multi-Cluster-Promotion — brauchen wir an dieser Stelle nicht. In einem K8s-Kontext mit verteilten Targets würde die Rechnung anders ausgehen.

Was du trotzdem brauchst — egal ob K8s oder NixOS

Hier wird oft falsch abstrahiert: „Wenn ich Nix habe, brauche ich kein DevSecOps mehr.“ Falsch. Nix löst die Composition-Schicht. Die anderen Schichten bleiben unverändert relevant.

SLSA-Provenance pro Image

Pro Container-Build erzeugt deine Pipeline ein in-toto-Statement vom Predicate-Type slsa.dev/provenance/v1. Es dokumentiert:

welcher Commit gebaut wurde,
auf welchem Runner und mit welchem Builder-Image,
welche Inputs in den Build geflossen sind (resolvedDependencies).

Wichtig: Das Base-Image gehört in diese Inputs — als Digest, nicht als Tag. Damit entsteht eine Verifikationskette, die du im Audit zurückverfolgen kannst:

App-Provenance ─ baseImage: php-base@sha256:xyz
                                       │
                                       └── eigene Provenance ─ baseImage: wolfi-base@sha256:...
                                                                              │
                                                                              └── ...

Anhängen ans Image via cosign attest --type slsaprovenance. Das ist die untere Schicht der Lieferkette, und sie ist orthogonal zu deinem Deployment-Modell.

Image-Signing mit Cosign

Bei selbst-gehostetem GitLab ist keyless Sigstore aktuell keine Option (der Sigstore-Public-Good-Trust-Root erwartet eine OIDC-Identität, die für gitlab.com sauber funktioniert, für eigene Instanzen aber nicht ohne weiteres Trust etabliert). Also key-based Signing mit kurzlebigen Build-Keys aus Vault. Jedes Image, das in die Production-Registry geht, ist signiert.

OpenVEX für Vulnerability-Hygiene

Wolfi-Images sind extrem schlank, aber Trivy/Grype melden trotzdem regelmäßig CVEs in transitiven Libraries, deren verwundbare Code-Pfade gar nicht erreicht werden. Statt das im Confluence-Doc oder im Ticket-System zu dokumentieren, schreibst du OpenVEX-Statements: signiert, maschinenlesbar, im OCI-Registry als Attestation neben dem Image. Pro CVE eine klare Aussage — affected, not_affected mit Justification, fixed, under_investigation.

Das reduziert Audit-Lärm massiv und ist genau der Mechanismus, der bei reiner SBOM-Prüfung fehlt. Für ISO-27001 oder TISAX ist das gold wert, weil ein Auditor nicht mehr fragen muss „warum ist diese High-CVE seit drei Wochen offen“, sondern liest „nicht betroffen, weil X“ mit Signatur und Datum.

System-SBOM aus dem Nix-Closure

Eine Nix-Derivation ist faktisch eine sehr präzise Komponentenbeschreibung — content-addressed, deterministisch, mit vollständigem Closure-Graph. Tools wie genealogos exportieren das nach CycloneDX. Für unsere NixOS-Hosts heißt das: System-SBOM fällt fast als Nebenprodukt ab — und die Reproduzierbarkeit ist echt, nicht behauptet.

Mit einer Einschränkung: Eine Nix-Closure-SBOM ist nicht eins-zu-eins gleichwertig zu einer klassisch gepflegten SBOM. Lizenz-Metadaten, Maintainer-Felder und einige andere Standard-Attribute kommen nicht automatisch mit; je nach Audit-Anforderung muss man sie aus den Nix-Paketdefinitionen ergänzen oder über zusätzliche Tools nachreichen. Das ist machbar, aber kein Selbstläufer.

Verify-on-Deploy

Der wichtigste Schritt, der oft vergessen wird: Was nicht verifiziert wird, ist nicht signiert. Im NixOS-Stack bietet sich dafür der nixos-rebuild-Pfad an — ein cosign verify als Build-Schritt sorgt dafür, dass eine Konfiguration, die ein Image referenziert, das nicht gegen den Signaturschlüssel validiert, beim Build fehlschlägt. Production-Hosts bekommen damit nur Configs, die diesen Verify-Schritt bereits bestanden haben.

Im K8s-Kontext liegt die äquivalente Stelle bei Kyverno oder dem Sigstore Policy Controller — Admission Webhooks, die unsignierte Images beim Scheduling abweisen. Mechanisch unterschiedlich, semantisch identisch: Was nicht signiert ist, läuft nicht.

Die ehrliche Abwägung: Wann lohnt OCM?

Ich halte OCM nicht für Marketing-Geschwurbel. Es löst ein reales Problem — nur eben nicht meines. Konkret lohnt es sich, wenn:

du Multi-Artifact-Releases atomar zwischen Registries transferieren musst (Build-Registry → Kunden-Cluster-Registry, oder Region A → Region B),
du in einer K8s-Welt operierst, in der die Composition-Fragmentierung echt ist,
du Cross-Cluster-Promotion-Workflows hast, die mit reinem helm upgrade schmerzhaft werden.

Es lohnt sich nicht, wenn:

deine Composition ohnehin in einer deterministischen Konfigurationssprache lebt (Nix, Bazel-Rules, Cue-Configs),
du genau eine Registry hast, aus der du deployst,
du die „Composition als first-class Artefakt“-Eigenschaft schon anderweitig sauber gelöst hast.

Konkret heißt das für uns zwei verschiedene Antworten je nach Kontext: In den K8s-Setups bei Kunden ist OCM ein durchaus prüfenswerter Baustein — gerade dann, wenn Multi-Artifact-Promotion zwischen Umgebungen oder Cross-Registry-Transfer ein Thema werden. Für unsere eigene NixOS-Infrastruktur lösen wir die Composition-Eigenschaft auf andere Weise, ohne ein zusätzliches Bundle-Format einführen zu müssen. Beide Antworten sind in ihrem jeweiligen Kontext sauber.

Was ich aus dem Ausgangsartikel mitnehme

Begriffshygiene zählt. „Software Bill of Delivery“ ist kein etablierter Standard — weder NTIA, noch CISA, noch OWASP, noch CNCF nutzen den Begriff. Das ist kein Vorwurf an einen Autor, der ihn als beschreibenden Sammelbegriff verwendet. Aber wer ihn in formaler Außenkommunikation oder gegenüber Auditoren übernimmt, hat es bei der Anschlussfähigkeit unnötig schwer. Die etablierten Akronyme sind SBOM, SLSA, in-toto, VEX, Sigstore. Auditoren erkennen sie. Ich verwende sie deswegen auch in eigener Dokumentation.

Das mentale Modell trotzdem mitnehmen. Atomic Composition mit Provenance-Kette ist die richtige mentale Brille — egal mit welchem Tooling man sie umsetzt. Bei NixOS sind es die Release-Module plus flake.lock plus signierte Images mit Provenance. Bei K8s sind es OCM oder ein selbstgebautes Manifest plus Sigstore. Die Eigenschaften sind dieselben, die Werkzeuge unterschiedlich.

DevSecOps-Architektur ist Architektur. Viele Tooling-Notwendigkeiten verschwinden, wenn man die Architektur eine Schicht tiefer richtig wählt. Das ist kein Argument gegen K8s — es gibt gute Gründe für Cluster-Plattformen, und Skalierungsbedarf ist einer davon. Aber es ist ein Argument dagegen, K8s zu wählen, weil „alle es nutzen“, und sich dann mit der zugehörigen Tooling-Landschaft auseinanderzusetzen, ohne dass die Anforderungen das tatsächlich erfordern.

Take-away

Die Frage ist nicht „brauche ich eine Bill of Delivery?“. Die Frage ist: „Wo bringt mein Stack die Composition-Eigenschaft schon mit, und wo muss ich sie nachrüsten?“

Bei K8s nachrüsten — über Bundle-Formate, Sigstore-Policies, GitOps-Disziplin. Bei NixOS-Hosts mit Podman ist sie als Nebeneffekt vorhanden — bleibt nur, sie sichtbar und signiert zu machen.

Provenance pro Image, OpenVEX für Audit-Hygiene und Verify-on-Deploy bleiben in beiden Welten Pflicht. Der Rest hängt davon ab, welches Composition-Problem dein Stack dir gestellt hat — oder dir erspart.

Beide Wege sind legitim. K8s mit OCM oder einem äquivalenten Bundle-Layer ist eine konsistente Antwort auf ein konsistentes Problem. NixOS mit Podman ist eine andere — nicht überlegene — Antwort, die das Problem an einer anderen Stelle auflöst. Was zählt, ist nicht die Wahl an sich, sondern dass die Eigenschaften am Ende sauber gegeben sind: atomare Komposition, nachvollziehbare Provenance, Signatur, Verifikation. Welcher Pfad dorthin führt, hängt vom Stack ab, vom Team, vom Kunden, von Skalierungsanforderungen.

Genau deswegen finde ich Auseinandersetzungen wie die mit dem Appetizers-Post wertvoll: nicht, um Recht zu haben, sondern um die Eigenschaften, die wir alle erreichen wollen, klarer zu benennen — und zu sehen, auf wie unterschiedlichen Pfaden man dort ankommt.