A-R-C Consulting

Product Security Governance

SBOM-Governance: Warum eine Komponentenliste allein nicht reicht

Ein kritischer Fehler in einer verbreiteten Bibliothek wird bekannt. Product Security fragt, welche Produktversionen betroffen sind. Einkauf fragt, welcher Lieferant reagieren muss. Entwicklung zeigt auf ein Repository mit mehreren SBOM-Dateien. Niemand kann jedoch sicher sagen, welche Fassung zu welchem Release gehört, ob transitive Abhängigkeiten enthalten sind oder wer einen Treffer bewertet. Die Liste existiert. Die Entscheidung fehlt.

Von Andreas Rühl · 1. August 2026 · Quellen geprüft am 2. August 2026

Hinweis: Allgemeine fachliche Einordnung; keine Rechtsberatung, Zertifizierungs- oder Auditgarantie.

Genau hier liegt die Managementaufgabe. Eine Software Bill of Materials (SBOM) kann Transparenz über Softwarekomponenten schaffen. Sie ist aber kein eigenständiger Compliance-Beweis und kein Ersatz für Schwachstellenmanagement, sichere Produktentwicklung oder Lieferantensteuerung. CISA, das BSI und weitere internationale Partner veröffentlichten am 29. Juli 2026 überarbeitete Minimum Elements für SBOMs. Die Ausgabe 2026 ersetzt die NTIA-Mindestfelder von 2021; das CISA-Dokument von 2025 war ein Entwurf für die öffentliche Kommentierung, nicht der nun maßgebliche Endstand. Das BSI nennt seine bestehende Technische Richtlinie TR-03183-2 als weiterführende Handreichung, meldet für diesen Termin aber keine Aktualisierung der Richtlinie. Der Cyber Resilience Act (CRA), Verordnung (EU) 2024/2847, verstärkt zugleich den Bedarf an beherrschbaren Produkt- und Schwachstelleninformationen. Daraus folgt kein magischer Listenstandard, sondern ein Betriebsmodell.

Dieses Betriebsmodell muss eine einfache Frage unter Zeitdruck beantworten können: Welche belastbare Entscheidung lässt sich aus welchen Produktdaten ableiten, wer trifft sie und wie bleibt sie nachvollziehbar? Der Export einer Datei ist dabei nur der Beginn. Wenn Identität, Qualität, Triage und Übergaben fehlen, produziert die SBOM vor allem eine präzise wirkende Form von Unsicherheit.

Die SBOM ist ein Datenprodukt, kein Ablageartefakt

Eine belastbare SBOM beschreibt Komponenten eines konkreten Softwareprodukts in einer konkreten Version. Damit sie Entscheidungen unterstützt, braucht sie Identitäten, Beziehungen, Versionen, Ersteller, Zeitbezug und ein maschinenlesbares Format. Die CISA Minimum Elements 2026 ordnen Anforderungen den Bereichen Datenfelder, Automatisierungsunterstützung sowie Praktiken und Prozesse zu. Gegenüber dem Ausgangsstand von 2021 kommen unter anderem Signatur des Autors, Name und Version des Datenformats, Erzeugungskontext, Name und Version des Werkzeugs, SBOM-Version, Hashwert und Hashalgorithmus einer Komponente sowie die Komponentenlizenz hinzu. Das ist ein wichtiger Hinweis: Schon die Mindestlogik endet nicht bei einer Sammlung von Paketnamen.

CISA formuliert die Minimum Elements für Software allgemein, einschließlich Open-Source-Software, KI-Systemen und Software as a Service. Für KI und SaaS können nach dem Dokument zusätzliche Elemente erforderlich sein, um ihre besonderen Transparenz- und Betriebsmerkmale abzubilden. Die Mindestfelder sind deshalb eine gemeinsame Basis, kein Versprechen, dass jeder Produkttyp mit genau demselben Datensatz hinreichend beschrieben ist.

Organisationen sollten eine SBOM deshalb wie ein kontrolliertes Datenprodukt behandeln. Für jede veröffentlichte Produktversion muss feststehen, an welchem Punkt der Build- oder Release-Kette sie erzeugt wird, welche Komponentenarten sie erfasst und wie Produkt, Version, Build und SBOM eindeutig verbunden sind. Ebenso braucht es Verantwortung für Qualität, Freigabe, Aufbewahrung, zulässige Weitergabe und nachvollziehbare Korrekturen.

Das Wort „Datenprodukt“ ist dabei keine kosmetische Aufwertung. Es verschiebt die Perspektive von der Datei auf ihren Lebenszyklus. Ein Datenprodukt hat einen definierten Zweck, einen Owner, Qualitätsregeln, bekannte Grenzen und Verbraucher. Bei einer SBOM sind diese Verbraucher beispielsweise Product Security, Engineering, Einkauf, Legal/Compliance oder Support. Sie nutzen dieselben Grunddaten, stellen aber unterschiedliche Fragen. Der Support will wissen, welche Kundenversion betroffen sein könnte. Engineering braucht den technischen Pfad. Der Einkauf benötigt den zuständigen Lieferanten und eine Frist. Ohne gemeinsame Identität sprechen alle über denselben Fall und meinen möglicherweise verschiedene Releases.

Ein Ordner namens „final_sbom_v7_neu“ löst diese Anforderungen nur dem Namen nach. Dateinamen besitzen leider keinen eingebauten Governance-Ausschuss.

Produkt und Release müssen dieselbe Identität teilen

Der erste Kontrollpunkt ist die Zuordnung. Eine SBOM ohne eindeutigen Produkt-, Versions- und Buildbezug kann bei einer Schwachstellenmeldung mehr Verwirrung als Transparenz erzeugen. Ein Product Security Identifier oder Release-Schlüssel sollte Binärartefakt, Quellstand, Build-Provenienz, SBOM, Freigabe und spätere Advisories verbinden.

Diese Verbindung muss Varianten berücksichtigen. Betriebssystempakete, Container-Images, Firmware, White-Label-Produkte und kundenspezifische Builds können unterschiedliche Komponenten enthalten. Eine pauschale „Produkt-SBOM“ verdeckt solche Unterschiede. Entscheidend ist nicht, möglichst viele Identifikatoren zu erfinden, sondern eine stabile Referenz zu schaffen, die über Werkzeuge und Rollen hinweg funktioniert.

Ein klar als hypothetisch zu verstehendes Beispiel: Ein Hersteller betreibt für dieselbe Produktversion ein Standard-Image und eine Kundenvariante mit zusätzlichem Treiber. Nach einer Schwachstellenmeldung findet das Monitoring die betroffene Bibliothek in der SBOM des Standard-Images. Der Kunden-Support übernimmt die Bewertung ungeprüft für beide Varianten. Später zeigt sich, dass nur die Kundenvariante eine abweichende, tatsächlich relevante Komponentenversion enthielt. Die technische Analyse war nicht grundsätzlich falsch. Ihr fehlte der saubere Releasebezug, und dadurch wurde die falsche Entscheidung auf den falschen Bestand übertragen.

Die Folge einer unscharfen Identität ist operativ erheblich: Teams untersuchen doppelt, Kunden erhalten widersprüchliche Aussagen oder eine Maßnahme wird am falschen Build getestet. Governance beginnt daher nicht bei einem Dashboard, sondern bei der verlässlichen Frage: „Worüber entscheiden wir gerade?“

Datenqualität ist mehr als syntaktische Gültigkeit

Vollständigkeit ist nicht binär. Ein Scanner erkennt nicht jede statisch eingebundene, vendorte oder zur Laufzeit nachgeladene Komponente. Deshalb braucht die Organisation Qualitätskriterien und bekannte Grenzen. Sinnvolle Kennzahlen sind beispielsweise der Anteil automatisch aufgelöster Komponentenidentitäten, nicht bestimmbarer Versionen, verwaister Beziehungen und Releases ohne freigegebene SBOM.

Qualität umfasst außerdem Aktualität, syntaktische Validität, semantische Plausibilität und Reproduzierbarkeit. Eine Datei kann formal valide sein und trotzdem nicht zum ausgelieferten Build passen. Sie kann alle Pflichtfelder enthalten, während eine kritische Beziehung zwischen Hauptprodukt und eingebetteter Komponente fehlt. Die richtige Frage lautet daher nicht nur „Haben wir eine Datei?“, sondern „Welche Entscheidungen kann diese Fassung mit welcher Sicherheit tragen?“

Dafür braucht es Qualitätsregeln mit Folgen. Ein syntaktischer Fehler kann den Release blockieren, wenn nachgelagerte Werkzeuge die SBOM sonst nicht verarbeiten. Eine unaufgelöste Identität muss nicht in jedem Fall blockieren, sollte aber sichtbar sein und abhängig von Produktkritikalität oder Exposition eine Freigabe erfordern. Die Entscheidung über Schwellenwerte ist organisationsspezifisch; ihr Mechanismus sollte es nicht sein. Fehler müssen erkannt, einem Owner zugeordnet und entweder korrigiert oder bewusst akzeptiert werden.

In einer zweiten hypothetischen Betriebsszene erzeugt die Pipeline eine valide SBOM, meldet aber zwölf Komponenten ohne bestimmbaren Versionsbezug. Weil der Build grün ist, wird das Release freigegeben. Wochen später trifft eine Meldung zu einer dieser Komponenten ein. Product Security kann nicht entscheiden, ob die ausgelieferte Fassung betroffen ist, und muss den Build rekonstruieren. Der Mangel war bereits beim Release sichtbar. Ohne Schwelle und Eskalationsweg blieb er lediglich folgenlos dokumentiert. Ein grüner Pipeline-Schritt ist eben ein technischer Status, kein Urteil über Restunsicherheit.

Ein CVE-Match ist ein Startsignal, keine fertige Antwort

Eine Komponente in der SBOM und ein CVE-Match beweisen noch keine Ausnutzbarkeit im Produkt. Umgekehrt darf ein unvollständiger Match nicht als Entwarnung gelten. Product Security muss Treffer mit Produktkontext, Komponentennutzung, erreichbarer Angriffsfläche, vorhandenen Gegenmaßnahmen und belastbarer Ausnutzungsinformation bewerten.

Der Triageprozess braucht eine gemeinsame Fallreferenz und ein begrenztes Set möglicher Ergebnisse. Bewährt ist eine strukturierte Bewertung wie betroffen, nicht betroffen, Untersuchung offen oder kompensiert. Jede Aussage benötigt Begründung, Evidenz, Owner und nächsten Prüftermin. Formate für Vulnerability Exploitability eXchange (VEX) können solche Bewertungen transportieren. Auch VEX ist jedoch nur so gut wie die zugrunde liegende Analyse. „Not affected“ ist kein Beruhigungscode, sondern eine begründungspflichtige Aussage.

Der Mechanismus ist besonders wichtig, wenn Informationen unvollständig sind. Eine offene Untersuchung ist kein Prozessversagen, solange Unsicherheit sichtbar bleibt, Verantwortlichkeit geklärt ist und ein Termin für die nächste Entscheidung existiert. Gefährlicher ist eine vorschnelle Entwarnung, die aus einem fehlenden Match eine fehlende Betroffenheit ableitet. Maschinen korrelieren Daten. Die fachliche Aussage über ein Produkt bleibt eine verantwortete Entscheidung.

Hypothetisch meldet das Monitoring einen Treffer in einer Bibliothek, die zwar im Image vorhanden ist, aber vom Produktpfad nicht aufgerufen wird. Engineering dokumentiert den nicht erreichbaren Codepfad und vorhandene Gegenmaßnahmen. Product Security bewertet die Fassung als nicht betroffen und setzt einen Prüftermin, falls neue Ausnutzungsinformationen erscheinen. Monate später wird eine Funktion aktiviert, die denselben Pfad nutzt. Eine gute Governance behandelt diese Produktänderung als Auslöser für eine Neubewertung. Eine statische VEX-Aussage ohne Änderungsbezug würde dagegen weiter beruhigend wirken, obwohl ihre Annahme nicht mehr gilt. Ruhe ist im Schwachstellenmanagement angenehm, aber kein Qualitätsmerkmal an sich.

Lieferanten gehören in denselben Regelkreis

Bei Drittsoftware muss vertraglich und operativ geklärt sein, welche SBOM-Informationen ein Lieferant wann, in welchem Format und für welche Version bereitstellt. Dazu gehören Aktualisierungen, Korrekturen, Schwachstelleninformationen, Eskalationswege und Fristen. Der Einkauf allein kann die technische Qualität nicht bewerten; Product Security allein kann keine Lieferverpflichtung durchsetzen.

Die Übergabe funktioniert nur, wenn beide Seiten denselben Fall referenzieren. Eine Vertragsklausel ohne operativen Kontakt hilft wenig, wenn bei einer Meldung unklar ist, welche Produktversion gemeint ist oder wer die technische Rückfrage beantwortet. Umgekehrt bleibt ein informeller Draht zwischen Entwicklern fragil, wenn Fristen, Korrekturen und Eskalation nicht vereinbart sind.

Eine risikobasierte Steuerung unterscheidet nach Produktkritikalität, Änderungsfrequenz, Exposition und Austauschbarkeit. Nicht jeder Lieferant braucht denselben Datensatz oder dieselbe Frequenz. Jede Ausnahme braucht aber einen verantwortlichen Entscheider und eine sichtbare Restunsicherheit. Das Management muss nicht jede Lieferanten-SBOM lesen. Es sollte jedoch erkennen können, bei welchen kritischen Abhängigkeiten die Datenlage schwach ist und welche Handlungsoptionen daraus folgen.

Wie die SBOM CRA-relevante Prozesse unterstützt

Der CRA verlangt von Herstellern Prozesse für Schwachstellenbehandlung und technische Dokumentation über den Produktlebenszyklus. Eine SBOM kann dafür ein wichtiger Input sein: Sie unterstützt die Bestandsaufnahme, die Bewertung betroffener Versionen, die Koordination mit Lieferanten, die Vorbereitung von Sicherheitsupdates und die Nachvollziehbarkeit technischer Entscheidungen.

Sie erfüllt diese Aufgaben nicht automatisch. Verantwortlichkeiten, Risikoanalyse, sichere Entwicklung, Monitoring, Meldung, Behebung und Nutzerkommunikation bleiben eigenständige Prozesse. Wer eine SBOM als alleinigen CRA-Nachweis behandelt, verwechselt eine Landkarte mit der Reiseleitung – und gelegentlich auch mit dem Fahrzeug.

Der praktische Governance-Punkt liegt in den Übergaben. Aus einem Schwachstellentreffer muss ein bewerteter Produktfall werden. Aus der Bewertung muss je nach Ergebnis eine technische Maßnahme, Lieferanteneskalation, Dokumentation oder Kommunikation folgen. Die SBOM liefert dafür Struktur und Referenz, aber nicht die Entscheidung selbst. Auch die Rechts- und Herstellerrolle lässt sich nicht aus einer Komponentenliste herauslesen. Sie muss für das konkrete Produkt und den jeweiligen Kontext geklärt werden.

Ein schlankes SBOM-Betriebsmodell

Ein tragfähiger Regelkreis beginnt mit dem Scope: Welche Produkte, Versionen, Komponentenarten und Lieferketten sind erfasst? Danach wird festgelegt, welcher Build-Schritt die SBOM erzeugt und welche Qualitätsfehler ein Release blockieren oder eskalieren. Die freigegebene Fassung wird mit Produktbezug, Zugriff und Aufbewahrung registriert. Monitoring korreliert Schwachstellen- oder Ausnutzungssignale mit diesem Bestand. Product Security triagiert Treffer, dokumentiert Unsicherheit und veranlasst Maßnahmen. Reaktion und Kommunikation greifen auf dieselbe Fallreferenz zurück. Erkenntnisse aus Fehlzuordnungen, blinden Flecken und verspäteten Reaktionen verändern anschließend Tooling und Prozess.

Das klingt linear, läuft aber als Regelkreis. Eine korrigierte Komponentenidentität kann frühere Matches verändern. Eine neue Produktfunktion kann eine alte „nicht betroffen“-Bewertung entwerten. Eine Lieferantenantwort kann die Datenqualität verbessern oder weitere Unsicherheit sichtbar machen. Deshalb braucht das Modell nicht nur einen Erzeugungszeitpunkt, sondern definierte Auslöser für Neubewertung.

Eine stichprobenbasierte Prüfung sollte den kompletten Weg für wenige Releases verfolgen: vom Build über die SBOM und einen simulierten Schwachstellentreffer bis zur freigegebenen Entscheidung. Dabei wird nicht nur geprüft, ob Werkzeuge Daten austauschen. Relevant ist, ob Rollen dieselbe Produktfassung referenzieren, Qualitätsgrenzen erkennen, Unsicherheit dokumentieren und eine Maßnahme nachvollziehbar freigeben.

Ein solcher Vertical Slice zeigt schneller als eine Tool-Demo, ob das Modell lebt. Die Demo beweist, dass ein Export möglich ist. Der Slice zeigt, ob unter Zeitdruck eine belastbare Entscheidung entsteht. Das sind zwei verschiedene Leistungen, auch wenn beide auf demselben Bildschirm stattfinden.

Die Managementsicht verbindet Kriterien mit klaren Folgen

Für das Management zählt zunächst die kontrollierte Zuordnung. Produkte, Herstellerrolle, Versionen und Builds müssen eindeutig mit ihren SBOM-Fassungen verbunden sein. Verbindliche Qualitätskriterien, bekannte Grenzen und Release-Eskalationen machen sichtbar, welche direkten, transitiven, eingebetteten und gelieferten Komponenten risikobasiert berücksichtigt werden. Erzeugung und Validierung gehören reproduzierbar in den Build- oder Releaseprozess.

Danach folgt die Entscheidungsfähigkeit. Jeder Schwachstellentreffer benötigt einen dokumentierten Triageweg mit Evidenz und Frist. Lieferantenpflichten regeln Formate, Aktualisierungen, Korrekturen und Eskalationskontakte. Product Security, Engineering, Einkauf, Legal/Compliance und Support referenzieren denselben Fall. Die Organisation legt außerdem fest, welche SBOM-Informationen intern bleiben, gezielt geteilt oder veröffentlicht werden.

Schließlich braucht das Management einen ehrlichen Blick auf die Grenzen. Das Modell unterstützt CRA-relevante Prozesse, ohne die SBOM als alleinigen Compliance-Beweis darzustellen. Berichtet werden Datenqualität, offene Untersuchungen, Reaktionszeit und Restunsicherheit. Eine gute Kennzahl zeigt nicht nur Aktivität, sondern eine mögliche Entscheidung. Hundert erzeugte SBOMs können Fortschritt bedeuten. Wenn fünf kritische Releases keiner freigegebenen Fassung zugeordnet sind, liegt die wichtigere Information wahrscheinlich dort.

Fazit und A-R-C-Impuls

Der Wert einer SBOM entsteht nicht beim Export, sondern bei der nächsten belastbaren Entscheidung. Product Security braucht dafür einen beherrschten Produktbezug, messbare Datenqualität, fachliche Triage, Lieferantenübergaben und nachvollziehbare Maßnahmen. Der CRA macht diese Fähigkeiten dringlicher, ersetzt aber nicht die notwendige Governance.

Ein sinnvoller A-R-C-Einstieg ist ein SBOM Governance Vertical Slice: Ein relevantes Produkt und ein aktueller Release werden vom Build bis zu einem simulierten Schwachstellentreffer verfolgt. Das Ergebnis ist kein Konformitätsversprechen, sondern ein priorisiertes Bild aus Daten-, Prozess-, Rollen- und Evidenzlücken.

Abgrenzung

Dieser Beitrag ist eine fachliche Einordnung zu Product Security und Governance. Er ersetzt keine Rechtsberatung, individuelle CRA-Bewertung, Konformitätsbewertung, Auditierung oder Zertifizierung. Er gibt keine Rechtskonformitäts-, Audit- oder Zertifizierungsgarantie. Konkrete Anforderungen sind anhand von Produkt, Herstellerrolle, Rechtsraum und anwendbaren technischen Spezifikationen zu prüfen.

Primärquellen

Über den Autor

Andreas Rühl unterstützt Unternehmen als Interim CISO und ISMS/GRC-Berater. Sein Schwerpunkt liegt darauf, Informationssicherheit steuerbar, prüfbar und managementfähig zu machen.

Passende A-R-C-Leistung: Security Governance