SBOMS FÜR MEHR TRANSPARENZ UND CYBERSICHERHEIT
Software Bill of Materials:
Anforderungen, Erstellung und Nutzen
Moderne Software besteht meist aus zahlreichen externen Bibliotheken und Paketen. Die daraus entstehenden Abhängigkeiten werden schnell unübersichtlich und bergen Sicherheitsrisiken, sobald einzelne Komponenten bekannte Schwachstellen aufweisen.
Eine Software Bill of Materials (SBOM) dokumentiert – meist im Format CycloneDX oder SPDX – sämtliche direkten und transitiven Abhängigkeiten eines Produkts. Sie schafft damit Transparenz, ermöglicht automatisiertes Schwachstellen-Scanning gegen Datenbanken wie die NVD oder die EUVD und gewinnt im Kontext von Cyber Resilience Act (CRA) und BSI-Vorgaben zunehmend an Bedeutung und verpflichtendem Charakter.
WAS STEHT IN EINER SBOM?
Viele Softwareprodukte besitzen eine Manifest-Datei, beispielsweise eine pom.xml oder package.json, in der bestehende Abhängigkeiten vermerkt sind. Diese Dateien werden in der Regel automatisch aktualisiert, sobald eine neue Bibliothek oder ein neues Paket vom Softwareprodukt verwendet wird. Allerdings erfassen sie meist nur die direkten Abhängigkeiten und enthalten wenig zusätzliche Informationen zu den verwendeten Komponenten.
Eine SBOM geht weiter: Sie bildet – meist als JSON- oder XML-Datei – den vollständigen Abhängigkeitsgraphen ab, inklusive relevanter Zusatzinformationen zu jeder Komponente.
SBOMS ALS TEIL DER CYBERSECURITY
Auch die EU hat diesen Nutzen von SBOMs erkannt: Der Cyber Resilience Act (CRA) verpflichtet Hersteller zur Dokumentation von Softwarekomponenten, wobei SBOMs eine zentrale Rolle spielen, und macht Cybersicherheitsanforderungen damit zu einem verpflichtenden Bestandteil der CE-Kennzeichnung für Produkte mit digitalen Elementen.
Für NutzerInnen bestätigt die CE-Kennzeichnung, dass Softwareprodukte die CRA-Konformität erfüllen, nicht jedoch die individuelle Risikohöhe. Gerade in Bereichen, in denen vertrauliche Daten verarbeitet und verwaltet werden, bleibt Transparenz über eingesetzte Softwarekomponenten entscheidend, um Sicherheitsrisiken und den unbefugten Zugriff auf diese Daten zu reduzieren.
WELCHE ANFORDERUNGEN GIBT ES AN SBOMS?
Der CRA und das Bundesamt für Sicherheit in der Informationstechnik (BSI) stellen eine Reihe von Anforderungen an SBOMs, um deren Qualität zu sichern. Die wichtigsten sind:
- Versionsbezogene SBOMs
Jede neue Version eines Softwareprodukts benötigt eine eigene SBOM. - Standardisierte Formate
Die SBOM sollte in einem gängigen, maschinenlesbaren Format vorliegen. In der Praxis haben sich insbesondere CycloneDX und SPDX etabliert. - Mindestens Top-Level
Die SBOM sollte mindestens alle direkten Abhängigkeiten enthalten. - Delivery-Item-Level
Idealerweise werden alle direkten und transitiven Abhängigkeiten erfasst, die tatsächlich mit dem Softwareprodukt ausgeliefert werden.
WIE KANN EINE SBOM ERSTELLT WERDEN?
Eine SBOM lässt sich manuell oder automatisiert erstellen. Da moderne Softwareprodukte oft zahlreiche Abhängigkeiten haben, ist eine manuelle Erstellung fehleranfällig und aus sicherheitstechnischer Sicht nicht zu empfehlen. Stattdessen kommen überwiegend automatisierte SBOM-Generations-Tools zum Einsatz. Diese nutzen unterschiedliche Ansätze, um die Abhängigkeiten zu ermitteln und die SBOM zu erstellen:
- Analyse von Metadaten-Dateien wie pom.xml oder package.json
- Analyse des Quellcodes
- Nutzung von Paketmanagern zum Bauen des Projekts
Diese Vorgehensweisen unterscheiden sich nicht nur methodisch, sondern liefern auch unterschiedliche Mengen und Arten an Informationen. Da der CRA derzeit keine konkreten Anforderungen an die Datenfelder der SBOM stellt, haben Softwarehersteller viel Spielraum beim genauen Inhalt. Orientierung bietet Teil 2 der BSI-Richtlinie TR-03183, die festlegt, welche Datenfelder das BSI in SBOMs erwartet.
BEISPIEL: OSS REVIEW TOOLKIT (ORT)
Ein Beispiel für ein SBOM-Generations-Tool ist das OSS Review Toolkit (ORT). Es scannt das Projekt nach bestimmten Dateien wie package.json und bestimmt anhand dieser, welche Paketmanager zum Bauen des Projekts benötigt werden. Mit diesen Paketmanagern rekonstruiert ORT den Abhängigkeitsgraphen des Softwareprodukts und dokumentiert alle gefundenen Softwarekomponenten in einer SBOM.
Diese SBOM enthält unter anderem Informationen zu Lizenzen, Herstellern und Autoren der Softwarekomponenten und deckt damit bereits den Großteil der vom BSI gewünschten Datenfelder ab. In Bezug auf die Konformität mit der TR-03183 ist jedoch zu beachten, dass weder das CycloneDX- noch das SPDX-Format – unabhängig vom verwendeten Tool – die Vorgaben der Richtlinie vollständig abbilden.
WIE LÄSST SICH DIE SBOM FÜR SCHWACHSTELLEN-SCANS NUTZEN?
Die SBOM allein liefert noch keine Aussage zur Cybersicherheit – sie dokumentiert nur die Abhängigkeiten eines Softwareprodukts. Da der CRA jedoch verlangt, dass Produkte bei Markteinführung frei von bekannten, ausnutzbaren Schwachstellen sind, liegt es nahe, die SBOM für einen Schwachstellen-Scan zu nutzen: SBOM-basierte Scanner gleichen die in der SBOM enthaltenen – oder bei Bedarf selbst daraus abgeleiteten – Komponenten-Kennungen mit Schwachstellen-Datenbanken wie der NVD oder der EUVD ab und dokumentieren Treffer im Scan-Ergebnis.
WO LIEGEN DIE GRENZEN VON SBOMS?
SBOMs bieten zwar viele Vorteile. Jedoch sollten auch die damit verbundenen Einschränkungen nicht übersehen werden.
- Paket-Ebene
SBOMs bilden Abhängigkeiten nur auf Paket-Ebene ab. Daher lässt sich oft nicht feststellen, ob eine Bibliothek oder ein Paket im Softwareprodukt tatsächlich genutzt wird. - False Positives
Im Verlauf der Entwicklung werden einzelne Abhängigkeiten manchmal nicht mehr genutzt, bleiben aber in den Metadaten verzeichnet. Das kann bei SBOM-basierten Schwachstellen-Scans zu False Positives führen. - Einzelne betroffene Funktionen
Schwachstellen betreffen teils nur einzelne Funktionen einer Bibliothek, die das jeweilige Softwareprodukt möglicherweise gar nicht nutzt. Automatisierte Scan-Ergebnisse sollten daher stets zusätzlich manuell überprüft werden.
FAZIT
Die SBOM ist kein Selbstzweck, sondern eine wesentliche Grundlage für ein kontinuierliches Schwachstellenmanagement. Sie schafft Transparenz über die in einem Softwareprodukt enthaltenen Komponenten und deren Abhängigkeiten und ermöglicht dadurch eine schnellere Bewertung neuer Sicherheitsmeldungen. Gleichzeitig ersetzt sie weder eine fundierte Risikoanalyse noch die fachliche Bewertung der tatsächlichen Auswirkung einer Schwachstelle auf das eigene Produkt.
Ihren vollen Nutzen entfaltet die SBOM erst im Zusammenspiel mit automatisierten Scans, etablierten Sicherheitsprozessen und regelmäßig gepflegten Entwicklungsabläufen. Vor dem Hintergrund steigender regulatorischer Anforderungen und zunehmend komplexer Softwarelieferketten wird sie damit zu einem zentralen Bestandteil moderner Softwareentwicklung und Compliance.
WEITERE INTERESSANTE BLOGARTIKEL
Automatisiertes
Testen
Bessere Softwarequalität und mehr Effizienz im Projekt durch automatisiertes Testen mithilfe von Cypress, Cucumber & XRay. Mehr dazu in diesem Beitrag.
Synchr. Anwendungen in der Cloud
Weltweiter Zugriff, geringe Latenzen, hohe Verfügbarkeit – mehr zu der Umsetzung synchronisierter Anwendungen in der Cloud in unserem Artikel.
OVFokus: WEBPORTAL-
entwicklung
6 Beiträge rund um das Thema Webportale – von IAM über Usability und Hosting bis zu Barrierefreiheit. Hier geht es zur Übersicht.
VergLeich: INUBIT BPM UND CAMUNDA BPM
Worin unterscheiden sich die beiden BPM Engines? Wann nutze ich welche? Antworten darauf in unserem Artikel aus der Reihe OVFacts.