Open Component Model erklärt: Software Bill of Delivery

Das Open Component Model (OCM) ist ein offener Standard, der eine erstaunlich alltägliche Frage beantwortet: Was genau gehört eigentlich zu einer Software-Lieferung? Nicht zum Quellcode, nicht zum einzelnen Container-Image, sondern zur vollständigen Delivery eines Produkts über Umgebungsgrenzen hinweg. OCM nennt das treffend “Software Bill of Delivery”. Während die SBOM beschreibt, woraus ein Artefakt besteht, beschreibt OCM, welche Artefakte zusammen ausgeliefert werden, wo sie liegen und wie sich ihre Integrität prüfen lässt. Dieser Artikel erklärt das Modell, seine Werkzeuge und die Szenarien, in denen es seine Stärken ausspielt.

Das Problem: Eine Lieferung ist mehr als ein Image

Ein reales Produkt-Release besteht aus einem Bündel: mehrere Container-Images, Helm-Charts, Konfigurationsdateien, vielleicht Binaries und Dokumentation. Dieses Bündel wandert durch Stationen, von der Build-Umgebung über interne Registries bis zur Kundenumgebung, die im regulierten Umfeld gerne komplett vom Internet getrennt ist. Spätestens beim Transport in eine Air-Gapped-Umgebung zerfällt der übliche Ansatz “wir referenzieren einfach die Registry-URLs”: Die URLs des Quellsystems sind drüben wertlos, Digests und Signaturen müssen die Reise trotzdem unverändert überstehen.

OCM setzt genau hier an. Ein Component Descriptor beschreibt eine Komponenten-Version mit ihren Ressourcen (Images, Charts, Dateien), ihren Quellen und ihren Referenzen auf weitere Komponenten. Das Format ist technologie-agnostisch und maschinenlesbar, ein Beispiel gekürzt:

meta:
  schemaVersion: v2
component:
  name: acme.org/billing
  version: 2.4.1
  provider: acme
  resources:
    - name: billing-image
      type: ociImage
      version: 2.4.1
      access:
        type: ociArtifact
        imageReference: ghcr.io/acme/billing:2.4.1
      digest:
        hashAlgorithm: SHA-256
        value: 8a1f...
  componentReferences:
    - name: payment-gateway
      componentName: acme.org/payment-gateway
      version: 1.9.0

Der entscheidende Kniff steckt im access-Block: Er trennt die Identität eines Artefakts von seinem Speicherort. Beim Transport in eine andere Umgebung schreibt das OCM-Tooling die Access-Angaben um (“by value” statt “by reference”), während Digests und Signaturen stabil bleiben. Die Komponente bleibt dieselbe, nur ihr Ablageort ändert sich.

Signieren, transportieren, verifizieren

Um Descriptoren und Artefakte gemeinsam zu bewegen, definiert OCM das Common Transport Format (CTF), ein dateibasiertes Layout als Verzeichnis, .tar oder .tgz. Damit wird eine komplette Delivery zu einer Datei, die sich auf ein Medium schreiben und auf der anderen Seite in eine OCI-Registry importieren lässt. Der Ablauf mit der CLI ist bewusst unspektakulär:

ocm transfer componentversion ghcr.io/acme//acme.org/billing:2.4.1 ./delivery.ctf
ocm sign componentversion --signature acme-release ./delivery.ctf
ocm verify componentversion --signature acme-release ./delivery.ctf

Signaturen decken den Komponenten-Graphen samt Artefakt-Digests ab. Der Empfänger verifiziert gegen den öffentlichen Schlüssel und weiß dann, dass weder Descriptor noch referenzierte Artefakte unterwegs verändert wurden. Für Kubernetes-Umgebungen liefert das Projekt zusätzlich das OCM K8s Toolkit, einen Operator, der Komponenten-Versionen im Cluster verfügbar macht und mit Flux oder kro zur vollständigen Deployment-Kette wird, inklusive Konfiguration und Lokalisierung der Image-Referenzen zur Deploy-Zeit.

Wer dahintersteht und warum das relevant ist

OCM wurde von SAP initiiert, die es intern für die Auslieferung großer Produktlandschaften einsetzt, und wird heute als Open-Source-Projekt unter Apache-2.0 weiterentwickelt, eingebettet in die NeoNephos Foundation unter dem Dach der Linux Foundation Europe und gefördert im Rahmen des europäischen Souveränitäts-Programms ApeiroRA. Die Spezifikation, eine Go-Library, die CLI und der Kubernetes-Operator sind öffentlich, dokumentiert auf ocm.software.

Diese Herkunft erklärt den Zuschnitt: OCM ist für Szenarien gebaut, in denen Software kontrolliert über Umgebungs- und Organisationsgrenzen bewegt werden muss. Das passt in eine Zeit, in der viele Unternehmen ihre Abhängigkeiten neu bewerten, wie wir im Artikel zur Sovereign Cloud beschrieben haben: Nachvollziehbare, signierte Lieferketten sind die operative Seite digitaler Souveränität.

Wann OCM die richtige Wahl ist, und wann nicht

Ehrlich eingeordnet: Wer ein einzelnes SaaS-Produkt aus einer Pipeline in die eigene Cloud deployed, braucht OCM nicht. Der Standard lohnt sich, wenn mindestens eines von drei Mustern zutrifft. Erstens Lieferung an Dritte, etwa Kunden, die On-Premises oder in eigene Clouds deployen. Zweitens Air-Gapped- oder stark regulierte Zielumgebungen, in denen Transport per Medium und Signatur-Verifikation Pflicht sind. Drittens Produktlandschaften aus vielen Komponenten mit eigenen Release-Zyklen, deren Zusammensetzung pro Release dokumentiert und prüfbar sein muss.

Zur SBOM verhält sich OCM komplementär statt konkurrierend: SBOMs beschreiben den Inhalt einzelner Artefakte und reisen in OCM-Deliveries als Ressourcen mit. Wie solche verschachtelten Strukturen auf SPDX-Ebene funktionieren, zeigt unser Deep-Dive zu SPDX-Kaskaden.

Fazit

OCM schließt eine Lücke, für die es bisher nur Eigenbau-Lösungen gab: ein offener, signierbarer, transportierbarer Standard für die Frage, was zusammen ausgeliefert wird. Für Produkt-Deliveries an Kunden, regulierte Umgebungen und Air-Gapped-Szenarien ist das Modell einen ernsthaften Blick wert, zumal Tooling und Governance offen sind. Wenn Sie Ihre Delivery-Pipeline auf signierte, nachvollziehbare Lieferungen umstellen wollen, unterstützen wir von der Architektur bis zur Umsetzung: Cloud & Infrastruktur bei EverBright.

Häufige Fragen

Was ist das Open Component Model?

Das Open Component Model ist ein offener, technologie-agnostischer Standard zur Beschreibung von Software-Lieferungen, einer Software Bill of Delivery. Component Descriptoren erfassen Artefakte, Quellen und Referenzen einer Komponenten-Version maschinenlesbar, inklusive Signaturen und Digests. Initiiert von SAP, wird OCM heute offen unter der NeoNephos Foundation entwickelt.

Was ist der Unterschied zwischen SBOM und OCM?

Eine SBOM beschreibt, woraus ein einzelnes Artefakt besteht, etwa welche Pakete in einem Container-Image stecken. OCM beschreibt, welche Artefakte gemeinsam eine Lieferung bilden, wo sie liegen und wie ihre Integrität geprüft wird. Beide ergänzen sich: SBOMs reisen als Ressourcen innerhalb von OCM-Deliveries mit.

Wofür braucht man das Common Transport Format (CTF)?

CTF ist das dateibasierte Format von OCM, das eine komplette Delivery samt Descriptoren und Artefakten als Verzeichnis, tar- oder tgz-Archiv abbildet. Damit lassen sich Lieferungen ohne Netzverbindung transportieren, etwa in Air-Gapped-Umgebungen, und auf der Zielseite wieder in eine OCI-Registry importieren.

Für wen lohnt sich der Einsatz von OCM?

OCM lohnt sich für Anbieter, die Software an Kunden mit eigenen Umgebungen ausliefern, für regulierte und Air-Gapped-Szenarien mit Signatur-Pflicht sowie für Produktlandschaften aus vielen unabhängig versionierten Komponenten. Für einfache SaaS-Deployments aus einer Pipeline in die eigene Cloud ist es meist Overhead.