„Schicken Sie uns Ihre Software-Stückliste“ — was hinter der neuen Kundenfrage steckt

Was ist eine SBOM überhaupt?

Eine Software Bill of Materials ist genau das, was der Name sagt: eine Stückliste. Sie beantwortet für ein Stück Software die Frage, aus welchen fremden Bausteinen es zusammengesetzt ist — mit Name, Hersteller und vor allem Version.

Der Vergleich, der am besten trägt, kommt aus dem Lebensmittelregal: Eine SBOM ist die Zutatenliste. Man braucht sie nicht täglich. Man braucht sie an dem Tag, an dem irgendwo ein Rückruf läuft und die Frage lautet: Ist das bei uns drin?

Genau dieser Tag war zuletzt mehrfach da. Beim Shai-Hulud-Wurm und beim Bitwarden-Vorfall entschied allein die Frage „Setzen wir das ein?“ darüber, ob ein Betrieb in Minuten oder in Tagen reagieren konnte. Wer keine Stückliste hatte, hat geraten.

Wer muss eine SBOM liefern — und ab wann?

Die Pflicht kommt aus dem Cyber Resilience Act, nicht aus der BSI-Richtlinie. Und sie trifft Hersteller von Produkten mit digitalen Elementen, nicht jeden Betrieb mit einem Computer.

• Seit 11. September 2026: die Meldepflichten für aktiv ausgenutzte Schwachstellen und schwere Vorfälle — beschrieben in unserem Beitrag zum Cyber Resilience Act.
• Ab 11. Dezember 2027: der CRA gilt vollständig. Dann greifen auch die Anforderungen an die technische Dokumentation, zu der die Software-Stückliste gehört.

Wichtig für die Einordnung: Veröffentlichen muss man die SBOM nicht. Der CRA verlangt, dass sie existiert und auf Verlangen der Marktüberwachungsbehörde vorgelegt werden kann — nicht, dass sie auf der Website steht. Wer befürchtet, mit einer SBOM sein Innenleben offenzulegen, kann beruhigt sein; wer hofft, sie deshalb gar nicht erst erstellen zu müssen, irrt.

Was genau ist die TR-03183 — und was nicht?

Die BSI TR-03183 ist die technische Richtlinie, die beschreibt, wie Hersteller die CRA-Anforderungen umsetzen können. Teil 2 behandelt speziell die Software-Stückliste: welche Felder hineingehören, in welchem Format, mit welcher Tiefe.

Und jetzt der Teil, den die meisten Beiträge dazu unterschlagen: Die TR-03183 ist nicht verbindlich. Sie ist eine Orientierungshilfe. Sie begründet keine Konformitätsvermutung — wer sie befolgt, hat damit also nicht automatisch den CRA erfüllt, und wer sie nicht befolgt, verstößt gegen nichts.

Das ist keine Spitzfindigkeit, sondern praktisch relevant. Es heißt: Sie können die Richtlinie als brauchbare Vorlage nehmen, ohne sich an jedem Detail abzuarbeiten. Verbindlich wird erst, was am Ende in den harmonisierten Normen zum CRA steht.

Und wenn wir gar kein Produkt herstellen?

Dann trifft Sie der CRA nicht direkt — und trotzdem steht die Frage im Raum. Sie kommt dann nicht von der Behörde, sondern von Ihrem Auftraggeber.

Das Muster ist dasselbe wie bei NIS2: Wer selbst unter die Regulierung fällt, muss die Sicherheit seiner Lieferkette berücksichtigen — und reicht die Anforderung nach unten durch. Ein Maschinenbauer, der CRA-pflichtig wird, fragt seinen Softwaredienstleister. Der fragt seine Zulieferer. So landet die Frage bei Betrieben, die vom CRA nie gehört haben.

Für Sie heißt das zweierlei:

• Nach unten fragen: Wer Software für Sie entwickelt oder betreibt, sollte eine Stückliste liefern können. Das ist inzwischen eine faire Vertragsfrage, keine Zumutung — und genau die Sorgfalt, die wir im Datenleck beim Dienstleister beschrieben haben.
• Nach oben antworten können: Wenn ein Kunde fragt, sollte die Antwort nicht „Das haben wir nicht“ lauten, sondern „Hier ist sie“ — oder wenigstens „Bis wann brauchen Sie sie?“.

Was ist der erste sinnvolle Schritt?

Nicht der Kauf eines SBOM-Werkzeugs. Der erste Schritt ist unspektakulärer und trägt auch ohne CRA: zu wissen, welche Software überhaupt im Haus läuft.

Denn die Software-Stückliste ist nur die feinste Auflösungsstufe einer Frage, die eine Ebene höher genauso unbeantwortet ist. Die meisten Betriebe könnten heute nicht sagen, welche Programme auf welchen Geräten installiert sind — das ist dieselbe Lücke, die wir in Schatten-IT beschrieben haben.

Deshalb in dieser Reihenfolge:

• Geräte- und Software-Inventar aufbauen. Das erledigt eine zentrale Geräteverwaltung nebenbei und beantwortet im Ernstfall die Rückruf-Frage.
• Eigenentwicklungen identifizieren. Gibt es ein Kundenportal, eine App, eine Maschinensteuerung mit eigener Software? Nur dort stellt sich die SBOM-Frage wirklich.
• Beim Dienstleister anfragen, ob er eine Stückliste erzeugen kann. Bei modernen Werkzeugketten ist das ein Konfigurationsschalter, kein Projekt.

Was sollten Sie als Nächstes tun?

Stellen Sie die eine Frage, die den Handlungsbedarf klärt: Bringen wir ein Produkt mit digitalen Elementen in Verkehr — auch als Integrator unter eigenem Namen?

Nein? Dann ist die SBOM für Sie eine Einkaufsfrage. Nehmen Sie sie in die Liste der Dinge auf, die Sie von Software-Lieferanten verlangen — mehr nicht. Der Dezember 2027 ist nicht Ihr Stichtag.

Ja? Dann haben Sie bis Dezember 2027 Zeit, und die brauchen Sie auch. Fangen Sie mit der Bestandsaufnahme an, nicht mit dem Werkzeug.

Wo genau Ihr Betrieb in dieser Kette steht, ordnen wir im IT-Sicherheitskonzept ein — zusammen mit der Frage, welche Nachweise Ihre Auftraggeber realistisch verlangen werden. Den laufenden Betrieb inklusive gepflegtem Inventar übernehmen wir als Managed Service.