SBOM Software Lieferkette ist ein wichtiges Thema für IT-Verantwortliche, Geschäftsführung und technische Teams. Dieser ausführliche GORTNET-Fachbeitrag erklärt die Hintergründe, konkrete Maßnahmen, typische Fehlentscheidungen und einen umsetzbaren Weg für mittelständische Unternehmen.
Stand: 21. Oktober 2026 · GORTNET Fachredaktion
Warum Software-Abhängigkeiten zum Geschäftsrisiko werden
Moderne Anwendungen bestehen selten vollständig aus selbst geschriebenem Code. Bibliotheken, Container-Basisimages, Frameworks und Build-Werkzeuge bilden komplexe Lieferketten. Wird eine verbreitete Komponente kompromittiert oder erhält eine kritische Schwachstelle, müssen Unternehmen schnell wissen, welche Produkte und Versionen betroffen sind.
Eine Software Bill of Materials (SBOM) stellt die Bestandteile einer Software strukturiert dar. Sie ist weder ein Qualitätszertifikat noch ein Ersatz für Penetrationstests. Ihr Nutzen entsteht erst, wenn das Inventar mit Schwachstelleninformationen und dem tatsächlichen Einsatz verbunden wird.
CycloneDX und SPDX: Geeignete Formate wählen
CycloneDX und SPDX sind verbreitete maschinenlesbare Formate. Beide können Softwarekomponenten, Versionen und Beziehungen darstellen, setzen aber unterschiedliche Schwerpunkte. Entscheidend ist, ob die eingesetzten Build- und Scanning-Werkzeuge verlässliche und reproduzierbare Daten erzeugen.
Starten Sie mit einem Format, das in Ihre CI/CD-Pipeline passt. Eine automatisch erzeugte, aktuelle SBOM pro Release ist in der Praxis nützlicher als ein einmal jährlich manuell gepflegtes Tabellenblatt.
SBOM in den Entwicklungsprozess integrieren
Erzeugen Sie die SBOM möglichst aus den tatsächlich gebauten Artefakten und nicht nur aus einer unverbindlichen Entwicklerliste. Dokumentieren Sie Paketquellen, Versionsnummern, direkte und transitive Abhängigkeiten sowie Zuordnung zur freigegebenen Produktversion.
Ergänzen Sie Hashes, Release-Signaturen und nachvollziehbare Build-Informationen. Bei Container-Anwendungen müssen auch Basisimage, Betriebssystempakete und Laufzeitabhängigkeiten beachtet werden.
Vulnerability Matching ohne Alarmflut
Ein Abgleich mit CVE-Datenbanken allein führt häufig zu False Positives. Nicht jede angezeigte Komponente ist im betroffenen Codepfad erreichbar, und nicht jede betroffene Version ist im Produkt tatsächlich aktiv. Kombinieren Sie SBOM-Treffer deshalb mit Erreichbarkeit, Konfiguration, Exponierung und möglichen Gegenmaßnahmen.
Dokumentieren Sie jede Risikoentscheidung mit Quellen, betroffenen Artefakten, zeitlichem Horizont und Verantwortlichem. Besonders nützlich sind nachvollziehbare VEX-Informationen, die erklären, ob eine Schwachstelle ein konkretes Produkt betrifft.
Softwarelieferanten nach belastbaren Daten fragen
Auch eingekaufte Software und Managed-Dienste können kritische Abhängigkeiten enthalten. Fragen Sie bei besonders wichtigen Produkten nach Schwachstellenmanagement, Update-Strategie, Sicherheitskontakt und verfügbaren SBOM- oder VEX-Daten.
Nicht jeder Anbieter stellt vollständige Komponentenlisten öffentlich bereit. Sensible technische Informationen können vertraglich geschützt geteilt werden. Wichtig ist, dass Ihr Unternehmen bei einer kritischen Warnung einen schnellen und überprüfbaren Auskunftsweg besitzt.
Zusammenhang mit dem Cyber Resilience Act
Der Cyber Resilience Act erhöht für betroffene Hersteller die Anforderungen an das Schwachstellenmanagement über den Produktlebenszyklus. Eine verlässliche Komponentenübersicht hilft, Sicherheitsupdates, Vulnerability Handling und Kommunikation mit Kunden vorzubereiten. Die konkreten rechtlichen Vorgaben sind anhand der eigenen Herstellerrolle zu prüfen.
Nutzen Sie die Übergangszeit zur Integration in Entwicklungsprozesse, statt vor dem vollständigen Wirksamwerden der Produktanforderungen große manuelle Inventarprojekte aufzubauen.
Implementierungsplan und Fragen aus der Praxis
In den ersten zwei Wochen identifizieren Sie Builds, Paketmanager und Verantwortliche. Danach generieren Sie eine SBOM für einen Pilotservice und gleichen kritische Komponenten ab. Anschließend ergänzen Sie Release-Zuordnung, Freigabeprozess und Lieferantenschnittstellen. Prüfen Sie monatlich, ob alle produktiven Versionen erfasst werden.
Braucht jede kleine Anwendung eine SBOM? Das hängt von Risiko und rechtlicher Einordnung ab; für geschäftskritische Software ist sie meist sinnvoll. Reicht ein SBOM-Scanner? Nein. Erst der anschließende Entscheidungs- und Update-Prozess macht sie operativ wertvoll.
SBOM Software Lieferkette: Beispiel eines Vorfalls
Stellen Sie sich vor, eine weit verbreitete Bibliothek erhält eine Sicherheitswarnung. Ohne Komponenteninventar müssen Teams alle Anwendungen manuell durchsuchen und Entwickler befragen. Mit einer gepflegten SBOM können sie zunächst potenziell betroffene Artefakte und Versionen identifizieren. Anschließend wird geprüft, ob der gefährdete Funktionsbereich überhaupt verwendet wird, ob das Produkt von außen erreichbar ist und welche schnelle Kompensation möglich wäre. Dadurch reduziert sich die Zeit zwischen Warnung und belastbarer Entscheidung.
SBOM-Daten aktuell und vertrauenswürdig halten
Erzeugen Sie eine neue Komponentenliste bei jedem freigegebenen Build, archivieren Sie sie mit der passenden Release-ID und überwachen Sie Fehler beim Export. Ein veraltetes Inventar vermittelt eine falsche Sicherheit. Verantwortliche sollten außerdem prüfen, ob Build-Artefakte und Listen tatsächlich zusammengehören. Digitale Signaturen und nachvollziehbare Build-Provenienz können Manipulationen erschweren. Das Inventar selbst muss kontrolliert verteilt werden, da es sensible technische Details über Anwendungen enthalten kann.
Lieferanten und Management in den Prozess einbeziehen
Produktverantwortliche sollten wissen, welche kritischen Softwarebestandteile von externen Anbietern stammen und wie schnell ein Patch geliefert werden kann. Fragen Sie bei wichtigen Herstellern nach Sicherheitskontakt, Supportende und einer dokumentierten Vulnerability-Disclosure-Policy. Für die Geschäftsführung reichen drei Kennzahlen: Anteil produktiver Releases mit aktueller SBOM, offene kritische Risiken und durchschnittliche Zeit bis zur Bewertung einer neuen Schwachstelle. Diese Werte machen Softwarelieferkettensicherheit messbar.
Weiterführende Informationen und Beratung
Passende GORTNET-Leistungen: Technische Umsetzung sowie Weitere IT-Beratung. Nutzen Sie eine strukturierte Bestandsaufnahme, bevor Sie technische und organisatorische Maßnahmen priorisieren. Kontakt zu GORTNET aufnehmen.
Quellen: Fachquelle 1 · Fachquelle 2 · Fachquelle 3. Externe Quellen dienen der Orientierung; produktspezifische Vorgaben sind anhand der aktuellen Herstellerunterlagen zu prüfen.