Ihre SBOM ist nicht für das Compliance-Team

Was Entwickler mir immer wieder sagen

Das Muster ist immer gleich. Ein Kundenfragebogen oder ein Audit verlangt eine SBOM. Jemand baut einen Generator in den Build ein oder lässt ihn kurz vor der Frist von Hand laufen. Die Datei wird übergeben, und aus Sicht des Entwicklungsteams ist die Sache damit erledigt. Niemand kommt mit einer Frage zurück, bei deren Antwort die SBOM geholfen hätte, also wird sie nie Teil der Arbeitsweise des Teams. Sie landet auf der Liste der Artefakte, die für jemand anderen existieren.

Wer das so erlebt hat, ist zu Recht skeptisch. Eine Datei, die niemand nutzt, ist lästige Pflicht. Das Problem ist nicht die SBOM, sondern dass die Frage, die sie beantwortet, selten unter Zeitdruck gestellt wurde. Genau das ändert sich gerade.

Die Frage, die eine SBOM tatsächlich beantwortet

Entwickler wissen, was heute in ihrem Produkt steckt. Lockfile und Abhängigkeitsbaum auf main sagen es ihnen. Aber Kunden betreiben nicht main. Sie betreiben die Version vom letzten Frühjahr oder die von vor zwei Jahren, die noch im Unterstützungszeitraum ist. Wenn eine Schwachstelle veröffentlicht wird, zählt nicht die Frage „wovon hängen wir jetzt ab?“, sondern „welche der ausgelieferten Versionen enthalten diese Komponente, in welcher Version, und wo laufen sie?“

Das im Nachhinein zu rekonstruieren dauert. Tags müssen ausgecheckt, Builds nachgestellt, transitive und gebündelte Abhängigkeiten verfolgt, Container-Basis-Images untersucht werden. Eine SBOM, die für jedes Release erzeugt und mit ihm aufbewahrt wird, ist eine Aufzeichnung, die die Frage direkt beantwortet, für alle Versionen auf einmal.

Warum die Meldefrist des CRA das Gespräch verändert

Seit dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen in ihren Produkten melden. Die Frühwarnung ist innerhalb von 24 Stunden fällig, nachdem sie davon Kenntnis erlangt haben. Der CRA verlangt die SBOM auch für sich genommen: Anhang I Teil II fordert eine in einem maschinenlesbaren Format, das mindestens die Abhängigkeiten der obersten Ebene erfasst. Aber in meinen Gesprächen ist es die Frist, nicht diese Zeile im Anhang, die die SBOM real macht.

Denken Sie an die erste Stunde, nachdem ein Advisory meldet, dass eine Komponente ausgenutzt wird. Die erste Frage ist keine Compliance-Frage. Es ist die Entwicklerfrage von oben: Sind wir betroffen, in welchen Releases, und ist der verwundbare Code in unserem Produkt überhaupt erreichbar? Das Compliance-Team kann sie nicht beantworten. Die Build-Aufzeichnungen können es. Wie der Rest des Prozesses funktioniert, vom Eingang bis zur Korrektur beim Kunden, habe ich in Warum Schwachstellenmanagement der Motor eines sicheren Produkts ist beschrieben. Hier möchte ich bei dieser ersten Stunde bleiben.

Wie es aussieht, wenn es funktioniert

Um das Teams zu zeigen, habe ich ein kleines Demo-Produkt gebaut: das Demo IoT Gateway, eine fiktive Java-Anwendung mit absichtlich veralteten Bibliotheken. Seine Build-Pipeline erzeugt für jedes Release eine CycloneDX-SBOM und lädt sie in OWASP Dependency-Track hoch, das jede Komponente mit öffentlichen Schwachstellendatenbanken abgleicht und auch nach dem Release weiter beobachtet.

Release 1.0.0 enthält neun Komponenten und rund 33 bekannte Schwachstellen. Zwei davon stehen auf der CISA-Liste bekannter ausgenutzter Schwachstellen: Log4Shell (CVE-2021-44228) und die Folgeschwachstelle CVE-2021-45046. Die Frage „welche unserer Versionen enthalten sie?“ ist in Sekunden beantwortet: 1.0.0. Die Triage-Entscheidung wird im Werkzeug festgehalten, die Prüfung der Meldepflicht ergibt, dass dies bei einem echten Produkt die 24-Stunden-Frist auslösen würde, und Release 1.0.1, das nur die log4j-Version ändert, beseitigt beide Befunde.

Dieselbe SBOM zeigt auch die andere Seite, die Entwickler meist mehr überzeugt. Apache Commons Text 1.9 wird ebenfalls gemeldet, wegen CVE-2022-42889. Aber die verwundbare String-Interpolation wird in diesem Produkt nie aufgerufen. Diese Entscheidung wird einmal festgehalten, als VEX-Aussage: nicht betroffen, Code nicht erreichbar. Keine Meldung, kein Notfall-Release, und eine schriftliche Begründung, wenn das nächste Mal jemand fragt.

Was eine nützliche SBOM von einem Compliance-Export unterscheidet

• Vom Build erzeugt, für jedes Release — nicht vor einem Audit von Hand zusammengestellt, damit sie beschreibt, was tatsächlich ausgeliefert wurde.
• Exakte Versionen und Paketkennungen (Package URLs), damit eine Schwachstellendatenbank jede Komponente ohne Raten zuordnen kann.
• Beim Release aufbewahrt, das sie beschreibt, solange diese Version unterstützt wird und im Einsatz ist.
• Laufend beobachtet, weil jeden Tag Schwachstellen für Komponenten veröffentlicht werden, die Sie vor Jahren ausgeliefert haben.
• Ergänzt um VEX-Entscheidungen, damit „nicht betroffen“ einmal entschieden wird, mit Begründung, und mit dem Produkt mitgeht.

Es gibt auch eine ehrliche Lücke. Komponenten in Lieferanten-Firmware und eingebettete Bibliotheken fehlen oft in öffentlichen Datenbanken und manchmal sogar in der SBOM selbst. Dort ist die SBOM nur so gut wie das, was Ihre Lieferanten liefern, und dieses Gespräch beginnt man besser jetzt als in der ersten Stunde eines Falls.

Was ich daraus mitnehme

Mit einem haben die Entwickler, mit denen ich spreche, recht: Eine SBOM, die für jemand anderen erzeugt wird, ist lästige Pflicht. Die Regulierung besser zu erklären, ändert daran nichts. Was es ändert, ist das erste Mal, dass ein Team „sind wir betroffen?“ in Minuten beantwortet, aus den eigenen SBOMs, während die Frist läuft. Danach muss niemandem mehr erklärt werden, warum es sich lohnt, sie zu erzeugen. Die SBOM war nie wirklich für das Compliance-Team. Sie ist für die Menschen, die die Frage beantworten müssen.