SBOM für Bestandssoftware: Was eine Software Bill of Materials bringt

Was ist eine SBOM?

Eine SBOM ist im Grunde eine strukturierte Stückliste für Software. Sie kann unter anderem enthalten:

• verwendete Bibliotheken und Frameworks
• direkte und indirekte Abhängigkeiten
• Versionsstände
• Paket- oder Komponentenkennungen
• Lizenzinformationen
• Beziehungen zwischen einzelnen Komponenten

Gängige Formate sind zum Beispiel CycloneDX und SPDX. Der entscheidende Vorteil gegenüber einer normalen Dokumentation besteht darin, dass diese Formate maschinenlesbar sind. Eine SBOM kann dadurch nicht nur von Menschen gelesen, sondern auch automatisiert weiterverarbeitet werden.

Warum ist eine SBOM auch für kleine Projekte sinnvoll?

Eine SBOM ist nicht erst dann interessant, wenn ein großes Unternehmen oder eine gesetzliche Vorgabe dahintersteht. Auch für interne Anwendungen, kleinere Kundenprojekte oder gewachsene Plugins kann sie einen praktischen Nutzen haben.

Der aktuelle Softwarebestand bleibt sichtbar

Eine SBOM zeigt, welche Komponenten ein Projekt tatsächlich verwendet. Das ist besonders hilfreich, wenn eine Software über mehrere Jahre gewachsen ist oder verschiedene Entwickler daran gearbeitet haben.

Statt sich durch Konfigurationsdateien, Paketmanager und alte Projektdokumentation zu arbeiten, existiert eine strukturierte Übersicht. Dadurch lässt sich schneller nachvollziehen, worauf eine Anwendung technisch aufbaut.

Vorteile im laufenden Betrieb

Sicherheitsmeldungen lassen sich schneller einordnen

Wird eine Schwachstelle in einer Bibliothek bekannt, muss zunächst geprüft werden, ob das eigene Projekt diese Komponente überhaupt verwendet. Eine gepflegte SBOM kann diese Suche deutlich erleichtern.

Sie ersetzt zwar keinen vollständigen Sicherheitscheck. Sie schafft aber eine belastbare Grundlage für die Frage: Sind wir betroffen oder nicht?

Die Dokumentation wächst von Anfang an mit

Bei kleinen Projekten wird eine SBOM oft aufgeschoben, weil die Software zunächst überschaubar wirkt. Genau dort liegt aber ein Vorteil: Wird der Softwarebestand früh dokumentiert, muss die Übersicht später nicht mühsam rekonstruiert werden.

Wenn das Projekt wächst, wächst die Dokumentation im besten Fall einfach mit.

Übergaben werden einfacher

Bei einem Entwicklerwechsel, einer Übernahme oder einer späteren Weiterentwicklung ist eine SBOM ebenfalls hilfreich. Neue Beteiligte können schneller verstehen, welche Komponenten vorhanden sind und welche technischen Abhängigkeiten berücksichtigt werden müssen.

Die Daten können weiterverarbeitet werden

Eine maschinenlesbare SBOM eignet sich für automatisierte Prüfungen, Abgleiche mit Schwachstellendatenbanken, Lizenzprüfungen und interne Dokumentationsprozesse. Sie ist damit mehr als eine PDF-Datei oder eine manuell gepflegte Tabelle.

Eine SBOM ist keine Sicherheitsgarantie

Eine SBOM zeigt, welche Komponenten vorhanden sind. Sie beseitigt jedoch keine Schwachstellen und ersetzt auch keinen Penetrationstest, keinen Code-Review und keine vollständige Sicherheitsprüfung.

Außerdem ist eine SBOM immer eine Momentaufnahme. Wenn sich Abhängigkeiten ändern, muss sie neu erzeugt oder aktualisiert werden. Eine veraltete SBOM kann ein falsches Sicherheitsgefühl vermitteln.

Ihr Wert hängt deshalb davon ab, dass sie regelmäßig aktualisiert und in einen sinnvollen Wartungsprozess eingebunden wird.

SBOM und Cyber Resilience Act

Seit dem 11. September 2026 gelten im Rahmen des Cyber Resilience Act erste konkrete Pflichten, insbesondere im Zusammenhang mit der Meldung aktiv ausgenutzter Schwachstellen und schwerwiegender Sicherheitsvorfälle.

Der CRA betrifft nicht automatisch jede Software und nicht jede Organisation in gleicher Weise. Entscheidend sind unter anderem das konkrete Produkt, seine Einordnung und die Rolle des jeweiligen Herstellers oder Anbieters.

Für bestimmte Produkte und größere Softwareprojekte kann eine SBOM dabei eine wichtige technische Grundlage sein. Sie hilft, den eigenen Softwarebestand zu kennen und bei Sicherheitsmeldungen schneller reagieren zu können.

Der praktische Nutzen einer SBOM reicht aber deutlich weiter als eine mögliche gesetzliche Verpflichtung. Auch interne Projekte und kleinere Anwendungen können von einer verlässlichen Komponentenübersicht profitieren.

Warum eine öffentliche SBOM problematisch sein kann

Eine vollständige SBOM sollte nicht automatisch öffentlich veröffentlicht werden.

Sie enthält je nach Umfang genaue Informationen über verwendete Bibliotheken, Frameworks und Versionsstände. Diese Informationen können bei einer unkontrollierten Weitergabe die technische Angriffsrecherche erleichtern. Bekannte Schwachstellen lassen sich dann schneller mit einem konkreten Softwarebestand in Verbindung bringen.

Die SBOM selbst erzeugt keine neue Schwachstelle. Sie macht den vorhandenen Softwarebestand zunächst sichtbar und besser beherrschbar. Wird sie jedoch zusammen mit öffentlich erreichbaren Systemen und exakten Versionsständen frei zugänglich, kann diese Transparenz auch gegen den Betreiber verwendet werden.

Angreifer suchen nicht nur nach Fehlern im eigenen Anwendungscode. Sie nutzen auch bekannte Schwachstellen in Frameworks, Bibliotheken, Laufzeitumgebungen oder Betriebssystemkomponenten. Sind die konkret eingesetzten Versionen bekannt, lässt sich schneller prüfen, ob ein Projekt von bekannten Schwachstellen betroffen ist.

Ein klassisches Beispiel sind veraltete PHP-Laufzeitumgebungen. Wird über eine SBOM sichtbar, dass eine Anwendung noch auf einer nicht mehr unterstützten PHP-Version oder alten Erweiterungen basiert, ist das ein deutliches Signal für eine technische Prüfung. Bekannte Schwachstellen und problematische Verarbeitungspfade lassen sich dann gezielter bewerten. Die SBOM verursacht die Schwachstelle nicht, sie kann bei öffentlicher Zugänglichkeit aber die technische Aufklärung erleichtern.

Weitergedacht: „SBOM-light“ als kontrollierte Übersicht

Für bestimmte Zwecke kann zusätzlich eine reduzierte SBOM-Zusammenfassung sinnvoll sein. Eine solche SBOM-light ist keine vollständige SBOM und ersetzt sie auch nicht. Sie kann aber Informationen bereitstellen, ohne den gesamten technischen Softwarebestand offenzulegen.

Sie könnte zum Beispiel enthalten:

• verwendete Haupttechnologien
• größere Komponentenfamilien
• grobe Abhängigkeitskategorien
• Lizenzgruppen
• Anzahl der erfassten Komponenten
• Zeitpunkt des letzten Scans

Auf exakte Versionsstände, interne Paketnamen, Pfade und die vollständige transitive Abhängigkeitskette könnte dabei verzichtet werden.

Auch eine SBOM-light ist nicht vollkommen risikofrei. Sie reduziert jedoch die Detailtiefe und kann sich für allgemeine Transparenz, interne Abstimmungen oder weniger sensible Empfänger eignen.

Wichtig ist die klare Trennung: Die vollständige SBOM bleibt die technische Quelle. Die SBOM-light ist lediglich eine kontrollierte Zusammenfassung für einen anderen Zweck.

Wie sollte eine SBOM gespeichert und übertragen werden?

Die sichere Erstellung einer SBOM ist nur der erste Schritt. Danach stellt sich die Frage, wo sie gespeichert wird und wer sie einsehen darf.

Ein geeignetes Bereitstellungskonzept sollte mindestens folgende Punkte berücksichtigen:

• geschützte Speicherung
• verschlüsselte Übertragung
• persönliche Benutzerkonten statt gemeinsam genutzter Zugangsdaten
• Zugriff nur für berechtigte Personen oder Organisationen
• Ablaufdatum für Freigaben
• Möglichkeit, Zugriffe jederzeit zu widerrufen
• Protokollierung der Zugriffe
• regelmäßige Aktualisierung der SBOM

Eine normale E-Mail mit angehängter SBOM ist dafür meist keine gute Lösung. Auch ein ungeschützter Downloadlink bietet keinen ausreichenden Zugriffsschutz. Ein zeitlich begrenzter Link zu einem abgesicherten Portal kann sinnvoller sein, sollte aber nicht als alleinige Sicherheitsmaßnahme verstanden werden.

Für kleinere Fälle kann ein verschlüsseltes Archiv mit getrennter Übermittlung des Passworts eine pragmatische Lösung sein. Für wiederkehrende oder umfangreichere Bereitstellungen ist ein Portal mit individuellen Konten, Ablaufzeiten und Protokollierung besser geeignet.

SBOM für bestehende Plugins und Projekte erstellen lassen

Gerade bei bestehender Software fehlt häufig eine aktuelle Übersicht über die verwendeten Komponenten. Das betrifft einzelne Plugins ebenso wie gewachsene PHP- oder Laravel-Projekte.

Eine technische SBOM-Bestandsaufnahme kann dabei helfen, zunächst Klarheit über den aktuellen Stand zu schaffen. Je nach Projekt werden Abhängigkeiten analysiert, in einem geeigneten Format erfasst und die Ergebnisse nachvollziehbar dokumentiert.

Für kleine und überschaubare Softwareprojekte gibt es bei Webdesign Oderland ein passendes Angebot zur SBOM-Erstellung ab 79 Euro. Größere Projekte, mehrere Repositories oder weitergehende Prüfungen werden nach einer kurzen Einschätzung individuell bewertet.

Mehr Informationen gibt es auf der Technik-Seite von Webdesign Oderland:
https://webdesign-oderland.de/technik/

Fazit

Eine SBOM ist eine strukturierte und maschinenlesbare Übersicht über die Bestandteile einer Software. Sie kann Wartung, Sicherheitsreaktionen, Übergaben und interne Dokumentation deutlich erleichtern.

Dafür muss sie nicht erst für ein großes, reguliertes Softwareprodukt interessant werden. Auch kleine und rein interne Projekte profitieren davon, wenn ihre technischen Abhängigkeiten frühzeitig erfasst werden.

Gleichzeitig sollte eine SBOM nicht unkontrolliert veröffentlicht oder per normaler E-Mail verteilt werden. Erstellung, Speicherung, Berechtigungsvergabe und Übertragung gehören zusammen.

Eine gute SBOM-Lösung beantwortet deshalb nicht nur die Frage „Was steckt in unserer Software?“, sondern auch: „Wer darf diese Informationen sehen und wie stellen wir sie sicher bereit?“