Dein Blog zum Thema digitales Business

Eine Datei im Ordner ist noch kein Nachweis

Die SBOM ist per Mail oder Portal gekommen, und der schnellste Weg ist, sie abzulegen und das Häkchen zu setzen. Dann liegt eine Datei im Ordner, von der niemand weiß, ob sie sich auswerten lässt, ob sie zur gelieferten Version gehört und ob sie überhaupt bis zu den Abhängigkeiten der Abhängigkeiten reicht.

Hier steht, was du in wenigen Minuten prüfst, bevor eine SBOM abgelegt wird, und was diese Prüfung ausdrücklich nicht leistet. Grundlage ist der NTIA-Bericht The Minimum Elements For a Software Bill of Materials (SBOM) vom 12. Juli 2021, live gelesen am 26.09.2026. Die Handgriffe sind an einer öffentlichen Beispiel-SBOM ausgeführt und mit Ausgabe belegt. Schlussfolgerungen und Empfehlungen sind gekennzeichnet.

Zur Abgrenzung: Wie du eine SBOM selbst erzeugst, steht in Von der Excel-Liste zum SBOM. Warum Software-Stücklisten 2026 zum Thema geworden sind, beschreibt SBOM 2026. Welche Fragen Prüfer an Software-Lieferanten stellen, behandelt Was Prüfer bei Software-Lieferanten tatsächlich fragen. Dieser Beitrag beginnt später: wenn die Datei bei dir liegt.

Das Übungsobjekt

Als Beispiel dient die SBOM SBOM/dropwizard-1.3.15/bom.json aus dem öffentlichen Repository CycloneDX/bom-examples. Sie ist im Format CycloneDX 1.2 geschrieben, beschreibt die Bezugskomponente dropwizard-parent 1.3.15 und wurde 2020 erzeugt. Sie ist ein Übungsobjekt, kein Lieferantenfall. Geprüft wurde die Datei mit jq und mit Trivy 0.73.0, beide lokal.

Prüfung 1: Lässt sich die Datei maschinell lesen?

Der NTIA-Bericht nennt unter „Automation Support“ als Formate SPDX, CycloneDX und SWID-Tags. Schlussfolgerung, keine Aussage des Berichts: Eine SBOM als PDF, Excel-Tabelle oder Screenshot erfüllt diesen Zweck nicht, weil du sie nicht in ein Werkzeug geben kannst.

Der Test ist ein Werkzeug, nicht ein Blick auf die Datei:

jq -r '.bomFormat + " " + .specVersion' bom.json
trivy sbom --skip-db-update --format json --output out.json bom.json

Ergebnis an der Beispieldatei: CycloneDX 1.2. Trivy liest die Datei ohne Fehler, erkennt den Typ cyclonedx und listet 168 Pakete. Dazu gibt Trivy Warnungen zu Hash-Algorithmen aus, die es nicht unterstützt (SHA3 und SHA-384); das Lesen bricht deshalb nicht ab. Bricht dein Werkzeug hier mit einem Parse-Fehler ab, gehört die Datei zurück an den Lieferanten, bevor du inhaltlich weiterprüfst.

Prüfung 2: Mindestfelder der Lieferanten-SBOM

Der Bericht nennt sieben Datenfelder pro Komponente, hier im Wortlaut: Supplier Name, Component Name, Version of the Component, Other Unique Identifiers, Dependency Relationship, Author of SBOM Data und Timestamp.

Die Zuordnung zu CycloneDX-Feldern ist eine Zuordnung, keine Aussage des Berichts: supplier, name, version, purl oder cpe, dependencies, metadata.authors und metadata.timestamp. In der CycloneDX-Dokumentation steht supplier als „The organization that supplied the component“ und authors als „The person(s) who created the BOM“. Ein Feld publisher gibt es zusätzlich, es ist als „The person(s) or organization(s) that published the component“ beschrieben und damit nicht dasselbe wie supplier.

Ein Skript zählt die Felder:

.components as $c
| { format: (.bomFormat + " " + .specVersion),
    zeitstempel: .metadata.timestamp,
    bezugskomponente: (.metadata.component | "\(.name) \(.version)"),
    komponenten: ($c | length),
    name_und_version: ($c | map(select(.name and .version)) | length),
    supplier: ($c | map(select(.supplier)) | length),
    publisher: ($c | map(select(.publisher)) | length),
    purl: ($c | map(select(.purl)) | length),
    autor_metadaten: (.metadata.authors // .metadata.supplier // "fehlt"),
    abhaengigkeits_eintraege: (.dependencies | length),
    davon_leer: (.dependencies | map(select((.dependsOn // []) | length == 0)) | length),
    ohne_eintrag: (($c | map(."bom-ref")) - (.dependencies | map(.ref)) | length) }

Aufruf: jq -f ntia_check.jq bom.json. Ergebnis an der Beispieldatei:

• 167 Komponenten, alle 167 mit Name, Version und purl.
• supplier bei 0 Komponenten, publisher bei 90. Ob publisher als Supplier Name durchgeht, ist Auslegung. Für 77 Komponenten steht keines von beiden da.
• Autor der SBOM-Daten: fehlt. In den Metadaten steht nur ein Werkzeug (CycloneDX Maven plugin 2.0.2). Der Bericht lässt zu, dass der Autor ein Analysewerkzeug sein kann. Dass er damit auch den Namen der Stelle meint, die die Daten erzeugt hat, ist eine Auslegung.

Empfehlung: Ein fehlendes Feld ist eine Rückfrage an den Lieferanten, kein Grund zur Verwerfung. Der Bericht selbst rät Empfängern, gelegentliche unbeabsichtigte Fehler zu tolerieren und Nachbesserungen zu begrüßen. Ausgenommen sind absichtliche Verschleierung und vorsätzliches Wegsehen.

Prüfung 3: Gehört die SBOM zur gelieferten Version?

Der Timestamp hält laut Bericht fest, wann die SBOM-Daten zusammengestellt wurden. Er hilft, aktualisierte Fassungen zu erkennen. Zur Frequenz sagt der Bericht: Bei jedem neuen Build oder Release muss eine neue SBOM erstellt werden. Eine neue Fassung soll es außerdem geben, wenn der Lieferant neue Details zu den Komponenten erfährt oder einen Fehler korrigiert.

Zwei Handgriffe:

1. Vergleiche die Bezugskomponente (metadata.component, Name und Version) mit dem, was du tatsächlich erhalten hast. Die Beispieldatei nennt dropwizard-parent 1.3.15. Eine SBOM für die Vorversion ist keine SBOM für deine Lieferung.
2. Vergleiche den Zeitstempel mit dem Datum des Builds. Die Beispieldatei trägt 2020-08-02T21:27:04Z. Empfehlung: Liegt der Zeitstempel deutlich vor dem Build der gelieferten Version, frag nach.

Ob eine Datei eine überarbeitete Fassung ist, zeigen in CycloneDX serialNumber und version: Laut Spezifikation soll version bei jeder Änderung um 1 erhöht werden, und bei gleicher Seriennummer gilt die neueste Version (so die CycloneDX-Spezifikation 1.6; die Beispieldatei ist im Format 1.2 geschrieben).

Wie schnell eine SBOM altert, lässt sich sofort zeigen: Trivy meldet gegen die Schwachstellendatenbank vom 26.09.2026 für die Beispieldatei 120 Einträge. Das sagt etwas über diese Datei aus, nicht über heutige Software. Die Datei bleibt ein Schnappschuss, die Datenbank nicht. Wie sich zwei Fassungen einer SBOM inhaltlich vergleichen lassen, zeigt SBOM-Diffing.

Prüfung 4: Wie tief reicht sie, und was fehlt ausdrücklich?

Beim Thema Tiefe verlangt der Bericht mindestens alle Komponenten der obersten Ebene, mit genug Angaben, um die transitiven Abhängigkeiten zu finden. Vollständig wäre der ganze Graph. Der Bericht nennt außerdem „Known Unknowns“: Wo der Graph nicht vollständig aufgelistet ist, muss der Autor das ausdrücklich angeben. Die Standardannahme soll sein, dass die Daten unvollständig sind.

In CycloneDX ist das laut Dokumentation so umgesetzt: Komponenten ohne eigene Abhängigkeiten müssen als leere Einträge im Graph stehen. Komponenten, die im Graph fehlen, können unbekannte Abhängigkeiten haben.

An der Beispieldatei: 167 Abhängigkeitseinträge, davon 106 leer (ausdrücklich ohne Abhängigkeiten) und 61 mit Abhängigkeiten. Keine Komponente fehlt im Graph (ohne_eintrag: 0). Auffällig ist etwas anderes: Für die Bezugskomponente selbst gibt es keinen Eintrag, und 29 Komponenten werden von keiner anderen referenziert. Ob sie direkt eingebunden sind, steht damit nur implizit in der Datei. Prüfe deshalb, ob die oberste Ebene dem Produkt zugeordnet ist.

Der Bericht erlaubt dem Empfänger, die Tiefe vorzugeben, etwa als Anzahl transitiver Schritte. Wenn dir die Tiefe nicht reicht, sag es dem Lieferanten so konkret.

Was die Prüfung nicht hergibt

Diese vier Prüfungen sagen, ob die Datei auswertbar ist. Sie sagen nicht:

• Dass die Angaben stimmen. Die Felder prüfen die Form. Ob jede eingebundene Komponente in der Liste steht, siehst du nur, wenn du sie gegen ein Lockfile oder den Build vergleichst.
• Dass die Software sicher ist. Eine vollständige SBOM sagt, was drinsteckt, nicht, ob es ein Problem gibt.
• Dass du sie weitergeben darfst. Nach dem Bericht können Lieferanten den Zugang beschränken. Die Bedingungen legen Lizenzen, Verträge oder andere bestehende Regelungen fest. Lies, was für diese Datei gilt, bevor du sie an Dritte schickst.

Ablegen: was in den Ordner gehört

Empfehlung, keine Vorgabe des Berichts: Neben der Datei liegen ihr SHA-256 (sha256sum bom.json), das Eingangsdatum, die gelieferte Produktversion, das Prüfergebnis mit den fehlenden Feldern und die Rückfragen samt Antwort. Ergebnis für die Beispieldatei: e0eb128b9d081444e76d5b71089f94db16d889e37a77ca869e2645a70eb29f4b. Mit dem Hash kannst du später belegen, welche Fassung du geprüft hast.

Was du damit tust

Die SBOM liefert die Liste, ein Scanner vergleicht sie mit einer Schwachstellendatenbank. Welche der Treffer in deiner Umgebung tatsächlich greifen, ist eine eigene Frage. Sie ist in VEX: Nicht jede CVE im SBOM ist ein echtes Risiko beschrieben.

Wo Unterstützung ansetzt

Das Leistungsspektrum ist gestaffelt und baut auf Delivery-Transparenz auf. Es läuft über drei Felder: Implementation (Delivery- und Nachweiskontrollen in die Pipeline einziehen), AI Governance (Nachvollziehbarkeit dort schaffen, wo KI-gestützte Schritte in Build und Deployment Freigaben und Verantwortung verwischen) und Maintenance (die Übergabefrage: wem ein System nach dem Go-Live gehört und woran man merkt, dass es niemandem gehört). Ein festes Angebot daraus entsteht erst, wenn klar ist, was du wirklich brauchst. Kontakt: mm@mhm-dl.de.

Über das Anmeldeformular für den Newsletter trägst du deine E-Mail-Adresse ein, kreuzt die Einwilligung an und bestätigst die Anmeldung danach per Mail. Mit der Anmeldung willigst du ein, dass der Newsletter unter anderem folgende Themen behandelt: Schulungen zu Docker, Kubernetes, CI/CD, Git-Workflows und DevSecOps-Werkzeugen sowie die Anforderungen aus NIS2, CRA und DORA und deren technische Umsetzung.