SBOM-Review: VEX, Qualitätsprofile und Delivery-Check

Ein Zulieferer schickt ein Release: ein paar Container-Images, ein Helm-Chart, dazu SBOMs und ein Advisory-Dokument. Bis zur Freigabe sind drei Fragen zu beantworten. Stimmt das Gelieferte mit dem überein, was die Stückliste behauptet? Sind die gemeldeten Schwachstellen im Produkt überhaupt erreichbar? Und taugt das SBOM formal genug, um es der Marktüberwachung vorzulegen? Dieser Artikel zeigt den Ablauf, mit dem sich das in etwa zwanzig Minuten beantworten lässt, statt in einem halben Tag Handarbeit.

Erst die Struktur, dann die Details

Ein Release-SBOM ist selten ein einzelnes Dokument. Üblich ist eine Kaskade: ein Dokument auf Release-Ebene, das per ExternalDocumentRef auf Komponenten-SBOMs verweist, die ihrerseits auf Container-Images zeigen. Wer so ein Paket im Texteditor öffnet, verliert nach dem zweiten Verweis den Überblick.

Der Einstieg ist deshalb die Topologie: Wie viele Dokumente hängen zusammen, welche Referenzen laufen ins Leere, wo sitzt welche Komponente? In SBOM Lens beantwortet das die Map-Sicht, ein Baum aus Dokumenten statt aus Paketen. Fehlende Dokumente erscheinen dort als Platzhalter, was in der Praxis der häufigste Befund ist: Der Zulieferer hat das Release-SBOM geschickt, die referenzierten Komponenten-Dokumente aber vergessen. Wie solche Kaskaden aufgebaut sind, haben wir in SPDX-Kaskaden im Detail beschrieben.

Danach lohnt ein Blick in die Conflicts-Sicht. Sie sammelt Pakete, die über die Kaskade hinweg in mehreren Versionen auftauchen. Zwei Versionen derselben Bibliothek in einem Release sind nicht automatisch ein Fehler, aber sie sind fast immer eine Frage wert: gewollte Isolation oder vergessenes Update?

VEX: Wenn die CVE-Liste lügt

Ein Scanner meldet vierzig Schwachstellen, der Hersteller sagt, dreißig davon seien nicht ausnutzbar. Wer hat recht? Genau für diese Lücke gibt es VEX, das Vulnerability Exploitability eXchange. Ein VEX-Dokument ist eine Aussage des Herstellers zu einer konkreten CVE in einem konkreten Produkt: betroffen, nicht betroffen, in Behandlung, behoben. Bei “nicht betroffen” kommt eine Begründung dazu, etwa dass der verwundbare Code-Pfad im Produkt gar nicht aufgerufen wird.

Zwei Formate haben sich durchgesetzt. OpenVEX ist minimalistisch und JSON-basiert, CSAF 2.0 ist der OASIS-Standard und deutlich umfangreicher, unter anderem beim BSI im Einsatz. SBOM Lens liest beide und legt die Aussagen als eigene Spalte über die Komponenten-Tabelle. Die Zuordnung läuft über Package-URL und CPE, also über die Identifikatoren, die auch der Scanner nutzt.

{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "statements": [{
    "vulnerability": { "name": "CVE-2026-1234" },
    "products": [{ "@id": "pkg:oci/billing@sha256:8a1f..." }],
    "status": "not_affected",
    "justification": "vulnerable_code_not_in_execute_path"
  }]
}

Der praktische Gewinn liegt im Nebeneinander: Statt eine CVE-Liste und ein Advisory getrennt zu lesen, steht neben jeder betroffenen Komponente direkt die Herstelleraussage samt Begründung. Was übrig bleibt, sind die Fälle ohne Aussage, und genau die gehören ins Rückfrage-Ticket an den Zulieferer.

Qualität messen statt schätzen

Ein SBOM kann formal existieren und trotzdem wertlos sein. Fehlen Versionsangaben, Lieferanten oder Prüfsummen, lässt sich weder ein CVE-Abgleich fahren noch eine Lieferung verifizieren. Deshalb gehört zu jedem Review eine Qualitätsprüfung, und die sollte Zahlen liefern, keine Ampel nach Gefühl.

Zwei Referenzrahmen sind dafür etabliert. Die NTIA-Minimum-Elements definieren, was ein SBOM mindestens enthalten muss: Autor, Zeitstempel, Namespace, Komponenten mit Version und Lieferant, dazu die Beziehungen zwischen ihnen. Die BSI-Richtlinie TR-03183-2 setzt strengere Anforderungen und ist im deutschen Raum die Messlatte, an der sich CRA-Vorbereitung praktisch orientiert.

SBOM Lens prüft ein geladenes Dokument gegen einen festen Satz von Spec-Regeln für SPDX 2.x, SPDX 3.0.x und CycloneDX 1.x und zeigt daneben die Abdeckungsquoten: Wie viele Pakete haben eine Version, einen Lieferanten, eine Prüfsumme, eine Lizenz? Das Ergebnis sind nackte Zahlen, kein erfundener Score, den niemand nachrechnen kann. Wer eigene Hausregeln durchsetzen will, hinterlegt ein eigenes Profil als JSON-Datei und misst alle zugelieferten SBOMs dagegen. Für die regulatorische Einordnung, warum diese Prüfung ab 2027 keine Kür mehr ist, siehe unseren Artikel zur CRA-SBOM-Pflicht.

Delivery-Check: Passt das Paket zur Stückliste?

Die dritte Frage ist die, die am häufigsten übersprungen wird: Enthält das gelieferte Archiv wirklich das, was im SBOM steht? SBOMs führen Prüfsummen je Datei oder Artefakt. Der Abgleich dagegen ist mechanisch und trotzdem selten automatisiert.

SBOM Lens nimmt die gelieferten Dateien und stellt sie den Prüfsummen im Dokument gegenüber. Das Ergebnis fällt in fünf Kategorien: Match, Mismatch, Missing, Unverifiable und Extra. Interessant sind die letzten drei. Missing heißt, das SBOM verspricht etwas, das nicht mitgeliefert wurde. Extra heißt, es liegt eine Datei bei, die niemand deklariert hat, was bei einer Lieferung in eine regulierte Umgebung eine ernsthafte Rückfrage rechtfertigt. Unverifiable heißt, das SBOM führt für dieses Artefakt gar keine Prüfsumme, ein Qualitätsmangel, der oft erst hier auffällt.

Auf der OCM-Seite gibt es das Gegenstück für Deliveries, das wir in OCM Lens beschrieben haben. Beide Werkzeuge bleiben dabei bewusst lesend: Sie zeigen an, ob Digests und Signaturen vorhanden und stimmig sind, verifizieren aber nicht kryptografisch. Das gehört in die CLI oder die Pipeline, wo es reproduzierbar und automatisierbar ist.

Der Ablauf als Ganzes

Für ein zugeliefertes Release hat sich diese Reihenfolge bewährt. Zuerst die Kaskade laden und die Topologie prüfen, damit klar ist, ob das Paket überhaupt vollständig ist. Dann den Qualitätsbericht ansehen, weil ein SBOM mit dreißig Prozent Versionsabdeckung jede weitere Analyse wertlos macht. Erst danach die Komponenten mit dem VEX-Overlay durchgehen und die Fälle ohne Herstelleraussage markieren. Zum Schluss der Delivery-Check gegen die tatsächlich gelieferten Dateien.

Für ein eigenes Release kommt die Diff-Sicht dazu: zwei Stände vergleichen, hinzugekommene und entfernte Pakete sowie Versionssprünge als Markdown exportieren und in die Release Notes übernehmen. Das ersetzt die Handarbeit, die sonst kurz vor dem Release niemand mehr machen will.

Alles davon läuft im Browser, ohne dass eine Datei den Rechner verlässt, und funktioniert auch offline als installierte Web-App. Für Teams empfiehlt sich die selbst gehostete Instanz mit kuratiertem Katalog, dann liegt der Einstiegspunkt für jedes Release einen Klick entfernt.

Fazit

SBOM-Review ist kein Lesen, sondern Abgleichen: Struktur gegen Erwartung, CVE-Liste gegen Herstelleraussage, Lieferung gegen Prüfsumme, Dokument gegen Mindestanforderung. Mit dem richtigen Werkzeug ist das eine Aufgabe von zwanzig Minuten und kein Projekt. SBOM Lens ist unter Apache-2.0 frei verfügbar, der schnellste Einstieg ist das eingebaute Beispiel im Viewer. Wenn Sie diesen Review-Schritt fest in Ihre Lieferantenprozesse oder Ihre CI/CD einbauen wollen, unterstützen wir dabei hands-on: Software Engineering bei EverBright.

Häufige Fragen

Was ist VEX und wozu braucht man es?

VEX steht für Vulnerability Exploitability eXchange und dokumentiert die Herstelleraussage zu einer CVE in einem konkreten Produkt: betroffen, nicht betroffen, in Behandlung oder behoben. Bei “nicht betroffen” kommt eine Begründung dazu. Das reduziert das Rauschen aus Scanner-Reports erheblich, weil nicht erreichbare Schwachstellen nachvollziehbar entfallen.

Was ist der Unterschied zwischen OpenVEX und CSAF?

OpenVEX ist ein schlankes JSON-Format, das sich auf die reine Exploitability-Aussage konzentriert und schnell in Pipelines integriert. CSAF 2.0 ist der umfangreichere OASIS-Standard für maschinenlesbare Security Advisories, den unter anderem das BSI nutzt. Für den Review-Alltag zählt vor allem, dass ein Werkzeug beide Formate lesen kann.

Was fordert die BSI TR-03183-2 für SBOMs?

Die Technische Richtlinie definiert Anforderungen an Format und Inhalt von SBOMs, darunter Pflichtfelder je Komponente wie Name, Version, Lieferant und eindeutige Identifikatoren. Sie geht über die NTIA-Minimum-Elements hinaus und ist im deutschen Raum die praktische Messlatte für die Vorbereitung auf den Cyber Resilience Act.

Wie prüfe ich, ob eine Lieferung zum SBOM passt?

Über die Prüfsummen im Dokument. Jede gelieferte Datei wird gegen den hinterlegten Hash gestellt, das Ergebnis fällt in Match, Mismatch, Missing, Unverifiable oder Extra. Besonders aussagekräftig sind nicht deklarierte Zusatzdateien und Artefakte ohne Prüfsumme, beides typische Rückfragen an den Zulieferer.