Software Bill of Materials (SBOM): Was KMU jetzt wissen müssen

Seit Kurzem gilt im Rahmen des Cyber Resilience Act eine Meldepflicht: Hersteller digitaler Produkte müssen aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle binnen 24 Stunden melden. Wer das leisten will, muss zuerst eine grundlegendere Frage beantworten können: Welche Software-Komponenten stecken überhaupt in den eigenen Produkten und Systemen? Genau hier setzt die Software Bill of Materials an – ein Werkzeug, das für viele ostdeutsche KMU bisher kaum eine Rolle gespielt hat, aber zunehmend zur Pflichtübung wird.

Was ist eine Software Bill of Materials?

Eine Software Bill of Materials, kurz SBOM, ist eine strukturierte Stückliste aller Software-Komponenten, aus denen eine Anwendung oder ein System besteht – vergleichbar mit der Zutatenliste auf einem Lebensmittel. Sie listet nicht nur den eigenen Code auf, sondern auch sämtliche eingebundenen Bibliotheken, Open-Source-Pakete und Abhängigkeiten samt Versionsnummer und Herkunft.

Der Grund, warum das wichtig ist: Moderne Software besteht selten aus komplett selbst geschriebenem Code. Ein einzelnes Webanwendungs-Projekt kann Dutzende bis Hunderte fremder Bibliotheken enthalten – jede davon eine potenzielle Schwachstelle. Wird in einer weitverbreiteten Bibliothek eine kritische Lücke bekannt, entscheidet die SBOM darüber, ob ein Unternehmen innerhalb von Minuten weiß “das betrifft uns, hier, in diesem System” – oder wochenlang manuell nachforschen muss.

Warum das Thema gerade jetzt relevant wird

Der Cyber Resilience Act verpflichtet Hersteller von Produkten mit digitalen Elementen zu genau dieser Art von Transparenz. Wer eine gemeldete Schwachstelle in einer Komponente innerhalb von 24 Stunden bewerten und melden soll, kommt ohne ein aktuelles Verzeichnis der verbauten Software-Bestandteile nicht aus. Doch nicht nur direkt betroffene Hersteller sind gefragt: Auch KMU, die Software einkaufen, integrieren oder für Kunden individuell entwickeln, geraten zunehmend in die Situation, eine SBOM von Lieferanten einzufordern oder selbst bereitzustellen.

Warum SBOM für ostdeutsche KMU kein Nischenthema mehr ist

Viele mittelständische Betriebe in Sachsen und Ostdeutschland gehen davon aus, dass Lieferketten-Transparenz nur große Softwarehersteller betrifft. Das greift zu kurz. Auch ein regionaler Maschinenbauer mit smarter Steuerungssoftware, ein Software-Dienstleister mit Kundenprojekten oder ein Handelsunternehmen mit eigenem Online-Shop bewegen sich im Anwendungsbereich: Sobald ein digitales Produkt oder eine digitale Dienstleistung an Kunden ausgeliefert wird, kann eine Nachfrage nach Komponenten-Transparenz kommen – sei es vertraglich von einem Großkunden, sei es regulatorisch.

Die konkreten Vorteile über die Compliance hinaus

• Schnellere Reaktion auf neue Schwachstellen: Bei einer neu bekannt gewordenen Sicherheitslücke lässt sich in Minuten prüfen, ob und wo die betroffene Komponente im eigenen Bestand eingesetzt wird.
• Bessere Verhandlungsposition gegenüber Lieferanten: Wer weiß, welche Komponenten ein Softwareprodukt enthält, kann gezielter nach Update-Zusagen und Support-Zeiträumen fragen.
• Nachvollziehbarkeit bei Audits: Ob Kundenanfrage, Versicherung oder Zertifizierung – eine gepflegte SBOM beantwortet Transparenzfragen, ohne dass jedes Mal eine manuelle Bestandsaufnahme nötig wird.
• Frühwarnung bei End-of-Life-Komponenten: Eine SBOM zeigt auf einen Blick, welche Bibliotheken bald nicht mehr gepflegt werden – ein häufig übersehenes Risiko in gewachsenen Software-Landschaften.

Praxisteil: SBOM-Prozess in KMU einführen

1. Bestandsaufnahme der eigenen Software-Landschaft

Erstellen Sie zunächst eine Übersicht: Welche selbst entwickelten Anwendungen, welche eingekaufte Software und welche zentralen Systeme (ERP, CRM, Webshop) sind im Einsatz? Diese Liste bildet den Rahmen, für den SBOMs später erstellt oder eingefordert werden.

2. Werkzeuge zur automatisierten SBOM-Erstellung nutzen

Für selbst entwickelte Software lassen sich SBOMs mit etablierten Open-Source-Werkzeugen wie Syft oder CycloneDX weitgehend automatisiert erzeugen. Diese Tools scannen ein Projekt und erstellen eine maschinenlesbare Stückliste im Standardformat SPDX oder CycloneDX – ganz ohne manuelle Pflege einer Excel-Liste.

3. SBOM in die CI/CD-Pipeline integrieren

Damit die SBOM nicht nach kurzer Zeit veraltet, sollte ihre Erstellung fester Bestandteil des Build-Prozesses werden. Bei jeder neuen Version einer Anwendung entsteht so automatisch eine aktuelle Stückliste – ohne zusätzlichen manuellen Aufwand im Tagesgeschäft.

4. SBOMs von Lieferanten aktiv einfordern

Bei zugekaufter Software oder Fremdentwicklungen sollte die Bereitstellung einer SBOM Teil der vertraglichen Anforderungen werden. Viele größere Anbieter stellen diese inzwischen auf Anfrage oder sogar standardmäßig zur Verfügung.

5. Abgleich mit Schwachstellendatenbanken automatisieren

Eine SBOM entfaltet ihren vollen Nutzen erst in Kombination mit einem automatisierten Abgleich gegen Schwachstellendatenbanken. Tools wie Grype oder Dependency-Track prüfen die Komponentenliste kontinuierlich gegen bekannt gewordene Sicherheitslücken und schlagen bei Treffern Alarm.

6. Verantwortlichkeiten und Meldewege festlegen

Legen Sie fest, wer im Unternehmen SBOM-Warnungen auswertet und wer im Ernstfall eine Meldung – etwa im Rahmen der CRA-Pflichten – vorbereitet. Ohne klare Zuständigkeit verpufft selbst die beste technische Grundlage.

Rexoma unterstützt KMU in Dresden beim Einstieg in SBOM-Prozesse

Sie wissen nicht genau, welche Software-Komponenten in Ihren Systemen stecken, und wollen sich auf kommende Transparenzanforderungen vorbereiten? Rexoma unterstützt KMU in Dresden, Sachsen und ganz Ostdeutschland dabei, SBOM-Prozesse aufzubauen, passende Werkzeuge einzuführen und automatisierte Schwachstellen-Abgleiche in bestehende Abläufe zu integrieren. Sprechen Sie uns an, wenn Sie Transparenz über Ihre Software-Lieferkette schaffen möchten.

FAQ

Ist eine SBOM für uns als kleines Unternehmen überhaupt verpflichtend? Eine direkte gesetzliche Pflicht besteht aktuell vor allem für Hersteller digitaler Produkte im Anwendungsbereich des Cyber Resilience Act. Viele KMU geraten aber indirekt in die Pflicht, etwa weil Großkunden oder Partner eine SBOM vertraglich verlangen.

Wie unterscheidet sich eine SBOM von einem klassischen IT-Asset-Inventar? Ein IT-Asset-Inventar erfasst meist Hardware und eingesetzte Softwareprodukte auf oberster Ebene. Eine SBOM geht deutlich tiefer und listet einzelne Programmbibliotheken und Abhängigkeiten innerhalb einer Anwendung auf – bis auf Versionsebene.

Welches Format sollten wir für unsere SBOM verwenden? Die beiden gängigen Standards sind SPDX und CycloneDX. Beide sind maschinenlesbar und werden von den meisten gängigen Scan-Werkzeugen unterstützt – die Wahl richtet sich meist danach, welches Format nachgelagerte Tools oder Kunden erwarten.

Reicht eine einmalig erstellte SBOM aus? Nein. Da sich Software-Abhängigkeiten mit jedem Update ändern können, muss die SBOM regelmäßig, idealerweise automatisiert bei jedem Build, aktualisiert werden. Eine veraltete SBOM vermittelt eine falsche Sicherheit.

Was passiert, wenn wir eine kritische Schwachstelle in einer eigenen Komponente entdecken? Betroffene Hersteller im Anwendungsbereich des Cyber Resilience Act müssen aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle innerhalb von 24 Stunden den zuständigen Behörden melden. Eine aktuelle SBOM ist die Voraussetzung, um überhaupt schnell genug feststellen zu können, ob und wo eine Lücke betroffen ist.