Eine SBOM erzeugen ist leicht. SBOM Prozesse etablieren ist die anspruchsvollere Aufgabe: Die Stückliste muss verlässlich zum ausgelieferten Artefakt passen, bei einer neuen Schwachstelle auffindbar sein und klare Entscheidungen auslösen. Andernfalls entsteht nur eine weitere Datei im Repository – mit dem beruhigenden, aber trügerischen Gefühl von Transparenz.
Für Softwareverantwortliche ist das Thema deshalb keine Frage eines einzelnen Austauschformats. Es betrifft Lieferketten, Build-Engineering, Produktverantwortung, Vulnerability Management und den Betrieb. Der sinnvolle Einstieg lautet nicht: Welches Tool erzeugt eine SBOM? Sondern: Welche Entscheidungen soll sie in welcher Situation ermöglichen?
Warum eine SBOM ohne Prozess wenig Wert hat
Eine Software Bill of Materials beschreibt Komponenten und Abhängigkeiten eines Softwareartefakts. Dazu können Open-Source-Bibliotheken, proprietäre Bestandteile, Container-Basisimages und indirekte Abhängigkeiten gehören. Je nach Format und Reifegrad enthält sie beispielsweise Versionen, eindeutige Kennungen, Prüfsummen, Lizenzinformationen und Beziehungen zwischen Komponenten.
Damit beantwortet sie zunächst eine wichtige, aber begrenzte Frage: Was steckt in dieser Version eines Produkts oder Dienstes? Bei einer kritischen Schwachstelle reicht das allein nicht. Security-Teams müssen zusätzlich wissen, ob die betroffene Komponente tatsächlich erreichbar oder aktiv genutzt wird, welches konkrete Release betroffen ist, wo es läuft und wer über ein Update oder eine Risikobehandlung entscheidet.
Genau hier scheitern viele erste Vorhaben. Ein Scanner erstellt bei jedem Build eine Liste. Die Listen landen in einem Artefakt-Repository oder werden an Kunden ausgeliefert. Aber niemand prüft ihre Qualität, niemand verknüpft sie mit der CMDB oder dem Deployment-Stand, und beim nächsten Sicherheitsvorfall beginnt die Recherche dennoch bei null.
Eine SBOM ersetzt weder Asset Management noch Schwachstellenmanagement. Sie verbessert deren Datengrundlage. Dieser Unterschied ist strategisch relevant: Wenn CISO, CTO und Produktverantwortung unterschiedliche Erwartungen an die SBOM haben, wird aus einem Transparenzprojekt schnell ein Konflikt über Zuständigkeiten.
SBOM Prozesse etablieren: Vom Anwendungsfall zurückdenken
Beginne mit wenigen, klar priorisierten Anwendungsfällen. Für die meisten Unternehmen sind das die Bewertung neu veröffentlichter Schwachstellen, die Nachweisführung gegenüber Kunden und Auditoren sowie die Steuerung von Open-Source- und Lizenzrisiken. Bei Produkten mit längeren Wartungszeiträumen kommt die Fähigkeit hinzu, Kunden gezielt über betroffene Releases zu informieren.
Jeder Anwendungsfall braucht eine definierte Entscheidung. Bei einer kritischen CVE kann das etwa bedeuten: Innerhalb einer festgelegten Frist wird festgestellt, welche freigegebenen Artefakte eine betroffene Komponente enthalten. Danach erfolgt entweder ein Patch, eine begründete Ausnahme oder die Feststellung, dass keine Ausnutzbarkeit besteht. Ohne diese Entscheidungskette bleibt die SBOM ein Reporting-Artefakt.
Setze auch den Geltungsbereich bewusst. Es ist selten klug, sofort jede historische Anwendung, jedes Skript und jede Infrastrukturkomponente abzudecken. Starte besser mit geschäftskritischen, extern bereitgestellten oder besonders regulierten Produkten. Dort sind Nutzen, Risiken und Verantwortlichkeiten meist klarer. Der Aufbau lässt sich anschließend auf weitere Softwareklassen übertragen.
Das richtige Bezugsobjekt festlegen
Eine SBOM sollte an ein auslieferbares, unveränderliches Artefakt gebunden sein – etwa an ein signiertes Paket, ein Container-Image, ein Installationsmedium oder ein Release-Bundle. Der Quellcode-Stand allein genügt nicht. Build-Parameter, transitive Abhängigkeiten und nachträglich eingebrachte Komponenten können dazu führen, dass sich Quellbestand und ausgeliefertes Ergebnis unterscheiden.
Das gilt besonders für Container. Eine Anwendung kann im eigenen Build sauber dokumentiert sein und dennoch auf einem Basisimage beruhen, dessen Komponenten und Patches sich unabhängig entwickeln. Für die Analyse musst du nachvollziehen können, welche SBOM zu welchem Image-Digest gehört. Tags wie `latest` oder manuell gepflegte Versionslisten sind dafür keine belastbare Grundlage.
Auch Betriebsmodelle unterscheiden sich. Bei selbst entwickelter Software kontrollierst du meist Build und Release. Bei eingekaufter Standardsoftware erhältst du die SBOM vom Hersteller und musst Qualität, Aktualität und sichere Übermittlung vertraglich und organisatorisch regeln. Bei SaaS ist eine vollständige Komponentenliste nicht immer erforderlich oder sinnvoll. Entscheidend ist dann eher, welche Sicherheitsinformationen der Anbieter liefert und wie du relevante Meldungen in dein Lieferantenrisikomanagement überführst.
Die Erzeugung gehört in die Lieferkette, nicht in Excel
Eine belastbare SBOM entsteht automatisiert in der CI/CD-Pipeline. Der Erzeugungsschritt sollte nach der Abhängigkeitsauflösung und so nah wie möglich am finalen Packaging liegen. Idealerweise wird die SBOM gemeinsam mit dem Artefakt versioniert, gespeichert und gegen nachträgliche Veränderung abgesichert. Signaturen und Prüfsummen helfen dabei, Herkunft und Integrität nachvollziehbar zu machen.
Die Formate SPDX und CycloneDX sind in der Praxis weit verbreitet. Welches besser passt, hängt vom Ziel ab. SPDX ist stark bei Lizenz- und Compliance-Informationen, CycloneDX ist auf die Nutzung in Software-Lieferketten und Sicherheitsprozessen ausgerichtet. Beide können sinnvoll sein. Vermeide aber parallele Formate ohne Übersetzungs- und Qualitätsstrategie: Unterschiedliche Identifier, unvollständige Beziehungen oder abweichende Versionierungslogiken erzeugen sonst neue blinde Flecken.
Automatisierung allein garantiert keine Datenqualität. Prüfe deshalb regelmäßig, ob direkte und transitive Abhängigkeiten erfasst werden, ob Komponenten eindeutig identifiziert sind und ob die SBOM tatsächlich dem ausgelieferten Artefakt entspricht. Besonders fehleranfällig sind manuell eingebundene Bibliotheken, proprietäre Binärdateien, Build-Plugins und Komponenten aus nicht zentral verwalteten Quellen.
Ein sinnvoller Qualitätsmaßstab ist nicht die maximale Zahl ausgefüllter Felder. Entscheidend ist, ob ein Security-Team eine Komponente bei einer konkreten Meldung eindeutig zuordnen kann. Eine falsche Versionsangabe ist gefährlicher als ein sichtbar fehlendes Zusatzfeld, weil sie zu einer falschen Entwarnung verleiten kann.
Schwachstellenbewertung braucht Kontext
Der größte operative Gewinn entsteht, wenn SBOM-Daten mit dem Vulnerability Management verbunden werden. Dafür müssen Komponentenkennungen zu den verwendeten Vulnerability Intelligence-Quellen passen. Das ist schwieriger, als es klingt: Paketnamen, Produktnamen und CPE-Zuordnungen sind nicht immer eindeutig. Moderne Paket-URLs und konsistente interne Normalisierung können die Trefferqualität deutlich erhöhen.
Ein Fund in der SBOM ist zudem nicht automatisch ein Sicherheitsvorfall. Eine Bibliothek kann vorhanden sein, aber der verwundbare Codepfad ist nicht erreichbar. Ein Feature kann deaktiviert sein, oder ein Patch wurde vom Hersteller rückportiert, ohne dass sich die sichtbare Upstream-Version verändert hat. Hier kommt VEX ins Spiel: Vulnerability Exploitability eXchange beschreibt, ob und warum eine bekannte Schwachstelle ein bestimmtes Produkt betrifft, nicht betrifft oder noch untersucht wird.
VEX ist kein Freifahrtschein für Ausnahmen. Es verlangt nachvollziehbare technische Begründungen, eine verantwortliche Stelle und eine erneute Bewertung, wenn sich Konfiguration oder Nutzung ändern. Für produktverantwortliche Teams kann das wertvoll sein, weil Kunden nicht nur eine Komponentenliste erhalten, sondern eine belastbare Aussage zur tatsächlichen Betroffenheit.
Verantwortlichkeiten und Übergaben sichtbar machen
SBOM-Prozesse scheitern oft an Übergaben. Entwicklung kennt die Abhängigkeiten, Platform Engineering betreibt die Pipeline, Product Security bewertet Findings und der Service Owner verantwortet den Betrieb. Keine dieser Rollen kann das Thema allein abschließen.
Lege daher fest, wer Mindestfelder und Formate definiert, wer die Pipeline betreibt, wer Freigaben bei Qualitätsfehlern erteilt und wer die Kommunikation bei kritischen Schwachstellen übernimmt. Ebenso wichtig ist der Umgang mit Ausnahmen: Eine nicht auflösbare Abhängigkeit oder ein fehlender Supplier-SBOM darf nicht stillschweigend akzeptiert werden. Sie braucht Risikoeigentümer, Ablaufdatum und einen dokumentierten nächsten Schritt.
Für die Steuerung auf Managementebene helfen wenige Kennzahlen mehr als ein Detail-Dashboard. Dazu gehören etwa der Anteil freigegebener Artefakte mit gültiger SBOM, die Zeit bis zur Betroffenheitsanalyse und die Zahl überfälliger Ausnahmen. Diese Metriken zeigen, ob der Prozess Entscheidungen beschleunigt – nicht nur, ob Dateien erzeugt werden.
Regulierung als Anlass, nicht als alleinige Begründung
Regulatorische Anforderungen erhöhen den Druck, Software-Lieferketten nachvollziehbar zu gestalten. Für Produkte mit digitalen Elementen ist der EU Cyber Resilience Act besonders relevant. Seine Pflichten gelten gestaffelt, weshalb Unternehmen die für ihr Produktportfolio und ihre Rolle einschlägigen Termine und Anforderungen konkret prüfen müssen. Eine SBOM kann dabei ein wichtiges Nachweis- und Arbeitsmittel sein, ersetzt aber weder Secure-by-Design-Praktiken noch Prozesse für Schwachstellenbehandlung und Meldepflichten.
Wer nur auf formale Erfüllung zielt, wird häufig zu spät merken, dass Lieferanteninformationen fehlen oder die eigene Release-Historie nicht abbildbar ist. Der bessere Maßstab lautet: Können wir bei einer neuen kritischen Schwachstelle faktenbasiert, reproduzierbar und innerhalb unserer Zielzeit handeln?
Plane deshalb einen ersten vollständigen Durchlauf als Übung: Wähle ein kritisches Produkt, simuliere eine relevante Abhängigkeitsschwachstelle und verfolge den Weg von der SBOM über die Betroffenheitsanalyse bis zur Entscheidung und Kundenkommunikation. Die Lücken, die dabei sichtbar werden, sind wertvoller als eine perfekte Folienarchitektur. Denn ein guter SBOM-Prozess beweist seinen Wert nicht beim Export der Datei, sondern in der nächsten unruhigen Stunde im Security-Betrieb.
