OCM Lens: Deliveries und ihre SBOMs im Browser prüfen

Wer mit dem Open Component Model arbeitet, kennt den Moment: Ein CTF-Archiv liegt vor, irgendwo darin stecken vier Komponenten, dreißig Ressourcen und ein paar SBOMs, und die einzige Sicht darauf ist ocm get componentversion im Terminal. Für schnelle Antworten auf Fragen wie “Welche Images liefert dieses Release aus?” oder “Ist die Signatur überhaupt vorhanden?” ist das umständlich. Deshalb haben wir OCM Lens gebaut: einen freien Viewer für OCM-Deliveries, der Component Descriptoren und CTF-Archive direkt im Browser öffnet. Wie sein Schwester-Tool SBOM Lens ist er Open Source unter Apache-2.0 und vollständig client-only.

Ein Archiv hineinziehen, einen Baum bekommen

OCM Lens nimmt, was eine Delivery-Pipeline tatsächlich produziert: einzelne component-descriptor.yaml-Dateien oder komplette Archive als .ctf, .tar oder .tgz. Die Archive werden im Browser entpackt, beide Artefakt-Layouts werden unterstützt, flaches OCI-Manifest ebenso wie verschachtelte Artifact Sets. Komponenten-Referenzen löst das Tool über alle geladenen Descriptoren hinweg auf und rendert einen durchgehenden Baum: Komponente, Referenz, Ressource. Nicht auflösbare Referenzen erscheinen als handlungsfähige Platzhalter, derselbe Ansatz, der sich in SBOM Lens bewährt hat. Suche und Facetten-Filter arbeiten über alle Sichten hinweg identisch, ein gesetzter Filter bleibt also beim Wechsel zwischen Baum, Tabelle und Diff erhalten.

Der Clou für die Praxis: SBOMs, die als Ressourcen in der Delivery stecken, werden im selben Vorgang extrahiert und per Prüfsumme ihrer Komponente zugeordnet. Damit beantwortet eine einzige geladene Delivery beide Fragen, die Lieferkette betreffend: Was wird ausgeliefert, und woraus besteht es? Grundlagen zum Modell selbst liefert unser Einführungsartikel zum Open Component Model.

OCM-nativ statt fremdes Vokabular

Ein bewusster Designpunkt: OCM Lens presst OCM-Konzepte nicht in ein SBOM-förmiges Schema. Labels erscheinen mit Signing-Badges, Repository-Kontexte, Signaturen mit Algorithmus und Digest-Tripel, Access-Spezifikationen, Artefakt-Digests und extraIdentity werden so angezeigt, wie der Descriptor sie erfasst. Das Tool bleibt dabei strikt lesend: Digests werden angezeigt, nicht verifiziert. Für kryptografische Verifikation bleibt die OCM-CLI zuständig, ein Viewer soll ehrlich bleiben über das, was er leistet.

Die fünf Sichten entsprechen dem Schwester-Tool. Explore zeigt den Komponenten-Baum samt Roh-Descriptor, Map die Topologie der Delivery, Inventory die Ressourcen-Tabelle mit CSV- und JSON-Export, Conflicts gruppiert Ressourcen, die in mehreren Versionen auftauchen, und Diff vergleicht zwei Delivery-Stände als kopierbares Markdown für Release Notes.

Dazu kommt ein Qualitätsbericht je Descriptor gegen ein eingebautes Profil namens OCM Component Essentials: Versions-Abdeckung als hartes Gate, Digest- und Access-Abdeckung als informative Meter, nackte Zahlen statt erfundenem Score. Wer strengere Hausregeln hat, bringt sein eigenes Profil mit.

Client-only, self-hostbar, im Editor

Wie SBOM Lens ist OCM Lens eine statische Web-App: Descriptoren und Archive werden lokal entpackt und verlassen den Rechner nicht. Das ist bei Deliveries noch relevanter als bei SBOMs, denn ein Component Descriptor verrät Registry-Pfade, interne Komponenten-Namen und Versionsstände. URL-Zugriffe passieren nur auf explizite Anforderung. Für Teams empfiehlt sich die selbst gehostete Instanz hinter dem eigenen Reverse Proxy: Sie erreicht private Registries ohne Tokens im Browser und kann über eine ocmlens.catalog.json einen kuratierten Katalog ausliefern, ein Klick lädt dann einen Descriptor samt allem, was er referenziert.

Für den Arbeitsalltag gibt es die VS-Code-Extension: “Open with OCM Lens” auf jeder component-descriptor.yaml, CTF-Archive öffnen standardmäßig damit, und das Workspace-Scanning findet jede Delivery im Repository. Beide Tools teilen Bedienkonzept und Sichten; der Quellcode liegt auf GitLab, das Schwester-Projekt daneben. Wer eines kennt, findet sich im anderen sofort zurecht.

Fazit

OCM ist ein starkes Modell mit bisher dünner Werkzeuglage jenseits der CLI. OCM Lens füllt die Lücke für den lesenden Teil: Deliveries öffnen, verstehen, vergleichen, inklusive der SBOMs, die darin mitreisen, ohne dass eine Datei den Rechner verlässt. Der schnellste Einstieg ist das eingebaute Beispiel im Viewer. Und wenn Sie OCM in Ihrer Delivery-Pipeline erst noch einführen wollen, begleiten wir den Weg von der Architektur bis zum Betrieb: Cloud & Infrastruktur bei EverBright.

Häufige Fragen

Was ist OCM Lens?

OCM Lens ist ein kostenloser Open-Source-Viewer für Deliveries nach dem Open Component Model, entwickelt von EverBright IT. Er öffnet Component Descriptoren und CTF-Archive direkt im Browser, löst Komponenten-Referenzen auf und zeigt eingebettete SBOMs. Das Tool ist client-only und steht unter Apache-2.0-Lizenz.

Welche Formate kann OCM Lens öffnen?

OCM Lens liest Component Descriptoren als YAML oder JSON sowie CTF- und Component-Archive als .ctf, .tar oder .tgz. Beide Artefakt-Layouts werden unterstützt, flaches OCI-Manifest und verschachtelte Artifact Sets. In der Delivery enthaltene SBOMs werden extrahiert und der passenden Komponente zugeordnet.

Verifiziert OCM Lens Signaturen?

Nein, bewusst nicht. OCM Lens zeigt Signaturen mit Algorithmus und Digest-Tripel so an, wie der Descriptor sie erfasst, bleibt aber strikt lesend. Kryptografische Verifikation gehört in die OCM-CLI oder die CI-Pipeline. Der Viewer macht sichtbar, ob und welche Signaturen vorhanden sind.

Bleiben meine Deliveries beim Öffnen lokal?

Ja. OCM Lens ist eine statische, client-only Anwendung: Archive werden im Browser entpackt und nie hochgeladen. URLs lädt das Tool nur auf explizite Anforderung. Für private Registries lässt sich eine eigene Instanz hinter dem Reverse Proxy betreiben, optional mit kuratiertem Delivery-Katalog fürs Team.