SBOM-Pflicht: Was eine Software-Stückliste ist und wer sie braucht

Wer entwickelt eigentlich diesen Teil Ihrer Software? Viele Unternehmen können das nicht beantworten. Genau das wird mit dem Cyber Resilience Act zum Problem. Die SBOM-Pflicht trifft fast jeden, der Software verkauft. Auch wer das noch nicht weiß.

Eine SBOM steht für Software Bill of Materials. Auf Deutsch: Software-Stückliste. Sie listet alle Bauteile einer Anwendung auf. Dieser Artikel erklärt, was eine SBOM genau ist. Er zeigt, warum sie faktisch zur Pflicht wird. Außerdem geht es um gängige Formate. Und um den tatsächlichen Aufwand bei der eigenen Erstellung.

Was ist eine SBOM genau?

Eine SBOM ist eine vollständige Liste aller Komponenten einer Software. Dazu zählen Bibliotheken, Module und Abhängigkeiten. Vergleichbar ist das mit der Zutatenliste auf einer Lebensmittelverpackung. Nur steht auf der SBOM nicht Zucker oder Salz. Dort stehen Name und Versionsnummer jeder verwendeten Bibliothek.

Jede moderne Anwendung nutzt fremden Code. Ein Framework hier, eine Login-Bibliothek dort, dazu Dutzende kleinere Pakete im Hintergrund. Ohne SBOM weiß oft niemand im Unternehmen, was davon im eigenen Produkt steckt. Genau das macht die SBOM-Pflicht so praxisrelevant. Sie zwingt Hersteller, diesen blinden Fleck zu schließen.

Für den Begriff selbst gibt es im Deutschen keine feste Übersetzung. Software-Stückliste trifft die Bedeutung am besten. Gemeint ist in jedem Fall dasselbe Dokument.

Wer ist von der SBOM-Pflicht betroffen?

Der Cyber Resilience Act unterscheidet Hersteller, Importeure und Händler. Die Pflichten der Hersteller sind dabei am umfangreichsten. Eine SBOM gehört genau zu diesen Pflichten.

Betroffen ist jedes Unternehmen, das Software selbst entwickelt. Das gilt auch für vernetzte Produkte auf dem EU-Markt. Das betrifft große Softwarehäuser genauso wie eine kleine Agentur. Auch ein eigenes Buchungssystem zählt bereits dazu. Selbst ein zehn Jahre altes PHP-System fällt darunter. Vorausgesetzt, es wird noch aktiv an Kunden ausgeliefert.

Nicht betroffen ist reine Individualsoftware, die ein Unternehmen nur intern nutzt. Sobald sie verkauft oder lizenziert wird, ändert sich das sofort. Wer unsicher ist, sollte das frühzeitig prüfen. Die konkreten Kriterien erklären wir ausführlich in unserem Artikel zum Cyber Resilience Act.

Auch kleine Softwarehäuser unterschätzen das oft. Die Unternehmensgröße spielt für die Einordnung keine Rolle. Entscheidend ist allein, ob ein Produkt auf dem Markt ist.

Warum wird die SBOM zur faktischen Pflicht?

Der Cyber Resilience Act ist die EU-Verordnung 2024/2847. Sie legt Mindeststandards für die Cybersicherheit digitaler Produkte fest. Ab dem 11. Dezember 2027 gelten die vollständigen Anforderungen. Ohne sie darf ein betroffenes Produkt dann nicht mehr auf den EU-Markt gebracht werden.

Eine zentrale Anforderung ist genau diese Stückliste. Hersteller müssen dokumentieren, aus welchen Komponenten ihre Software besteht. Wer das nicht kann, erfüllt die Vorgaben nicht.

Die Verordnung verpflichtet nicht jedes Unternehmen einzeln per Namen. Aber wer ab Dezember 2027 weiter verkaufen will, kommt an der SBOM praktisch nicht vorbei. Genau deshalb sprechen viele von einer faktischen Pflicht, auch ohne eine wörtliche Einzelverpflichtung im Gesetzestext.

Welche Konsequenzen drohen ohne SBOM?

Ohne SBOM fehlt der Überblick über Abhängigkeiten im eigenen Code. Das ist ein Compliance-Problem. Es ist auch ein konkretes Sicherheitsrisiko.

Wird eine neue Sicherheitslücke in einer verbreiteten Bibliothek bekannt, muss ein Unternehmen schnell reagieren. Zuerst muss es wissen, ob es betroffen ist. Ohne SBOM beginnt die Suche bei null. Mit SBOM ist die Antwort oft eine Frage von Minuten.

Dazu kommt das regulatorische Risiko. Verstöße gegen den Cyber Resilience Act können teuer werden. Die Bußgelder reichen bis zu 15 Millionen Euro. Oder bis zu 2,5 Prozent des weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher liegt. Eine fehlende SBOM ist dabei keine Kleinigkeit. Sie ist eine nachweisbare Lücke in der Dokumentation.

Auch Kunden und Geschäftspartner fragen zunehmend danach. Wer Software liefert, bekommt die Frage nach der SBOM öfter im Angebotsprozess gestellt. Nicht erst bei einer Behördenprüfung. Wer darauf keine Antwort hat, wirkt im Ausschreibungsprozess schnell unprofessionell.

Welche Formate und Standards gibt es?

Für SBOMs haben sich zwei Formate durchgesetzt. SPDX steht für Software Package Data Exchange. Es stammt aus einem Projekt der Linux Foundation. CycloneDX kommt aus dem Umfeld von OWASP. Das ist die Organisation hinter vielen Sicherheitsstandards für Webanwendungen.

Beide Formate sind maschinenlesbar. Beide lassen sich mit gängigen Werkzeugen automatisch erzeugen. Für PHP-Projekte mit Composer gibt es dafür fertige Werkzeuge. Für JavaScript-Projekte mit npm ebenfalls. Sie lesen die vorhandenen Abhängigkeitsdateien aus. Daraus erzeugen sie direkt die fertige SBOM. Wie Sie diese Abhängigkeiten grundsätzlich prüfen, beschreiben wir in unserem Artikel über Software-Supply-Chain-Angriffe.

Welches Format Sie wählen, hängt oft von Kunden oder Partnern ab. Manche Branchen bevorzugen eines der beiden Formate. Für den Einstieg reicht grundsätzlich jedes davon.

Was gehört mindestens in eine SBOM?

Eine brauchbare SBOM nennt für jede Komponente den Namen und die genaue Version. Dazu kommt der Hersteller oder die Herkunft der Bibliothek. Wichtig ist auch, welche Komponente von welcher anderen abhängt. Diese Beziehungen zeigen, wie tief ein Risiko im System verborgen sein kann. Fehlt eine dieser Angaben, bleibt die SBOM unvollständig und damit wenig nützlich im Ernstfall. Auch bei einer Behördenprüfung zeigt sich das sehr schnell. Die Dokumentation wirkt dann lückenhaft und unvollständig. Besser ist es, diese Lücken früh zu schließen, lange bevor Zeitdruck entsteht.

Wie aufwendig ist die Erstellung einer SBOM wirklich?

Die ehrliche, kurze Antwort: Es kommt stark auf das jeweilige System an.

Für eine neue Anwendung mit modernem Paketmanager ist eine erste SBOM schnell fertig. Oft genügen dafür wenige Stunden. Composer und npm kennen die Abhängigkeiten bereits. Ein Werkzeug liest diese Liste aus. Daraus erzeugt es automatisch die fertige SBOM.

Für gewachsene Legacy-Systeme sieht das anders aus. Bibliotheken wurden dort oft manuell eingebunden. Ohne Paketmanager, ohne zentrale Liste. Niemand im Unternehmen weiß dann mehr genau, was im Code steckt. Aus einer kurzen Aufgabe wird so schnell ein mehrtägiges Projekt. Code sichten, Abhängigkeiten identifizieren, Versionen klären, das braucht Zeit.

Das ist kein Grund, alte Systeme schlechtzumachen. Viele davon laufen zuverlässig seit Jahren. Aber genau diese Systeme brauchen jetzt besondere Aufmerksamkeit. Nur so sind sie rechtzeitig bereit, bevor die vollständigen Anforderungen greifen.

Einmal erstellt, hält sich eine SBOM fast automatisch aktuell. Die richtigen Werkzeuge übernehmen die laufende Pflege. Der größte Aufwand liegt im ersten Durchgang, nicht danach. Wer diesen Durchgang jetzt plant, vermeidet den Stress kurz vor Dezember 2027.

Fazit: Jetzt klären, nicht erst 2027

Die Pflicht zur Software-Stückliste ist kein bürokratisches Randthema. Sie ist eine direkte Folge des Cyber Resilience Act. Sie betrifft praktisch jeden, der Software verkauft oder vertreibt.

Wer heute beginnt, hat bis Dezember 2027 genug Zeit. Zeit für eine saubere, vollständige Stückliste. Wer wartet, muss später unter Zeitdruck nachholen, was in Ruhe deutlich einfacher gewesen wäre.

Sprechen Sie uns an. Das Erstgespräch ist kostenlos. Wir erstellen für Sie eine erste SBOM. Und wir zeigen Ihnen ehrlich, wo Sie heute stehen. Auch, wie groß der Abstand zu den Anforderungen des Cyber Resilience Act noch wirklich ist.