SBOM-Management in Unternehmen scheitert bei Skalierung aus vorhersehbaren Gründen. Hier sind die fünf, an denen Programme zerbrechen.
Fragen Sie ein großes Unternehmen, ob es „SBOMs macht“, lautet die Antwort meist ja. Die Build-Pipelines geben CycloneDX oder SPDX aus, die Dateien landen irgendwo, ein Compliance-Häkchen wird gesetzt. Auf dem Papier funktioniert das Programm.
Dann taucht an einem Freitagnachmittag eine kritische CVE auf, jemand fragt „Wo sind wir betroffen?“, und das Programm trifft auf die Realität. Stunden vergehen. Teams durchsuchen Repositories. Niemand kann über mehr als eine Handvoll Produkte hinweg eine klare Antwort geben. Die SBOMs waren die ganze Zeit da. Sie konnten nur die eine Frage nicht beantworten, für die sie gedacht waren.
Das ist der Unterschied zwischen dem Erzeugen von SBOMs und ihrem Verwalten. Das Erzeugen ist günstig und weitgehend automatisiert. SBOM-Management ist der Teil, der die Frage nach der Betroffenheit auf Abruf beantworten muss, und es ist der Teil, der bei Skalierung scheitert.
Eine SBOM zu erzeugen ist rund zehn Prozent der Arbeit
Die Tooling-Frage ist geklärt. Open-Source-Generatoren erzeugen aus nahezu jedem Build eine standardisierte SBOM, in beiden gängigen Formaten, ohne nennenswerte Kosten. Ein Team kann das Erzeugen an einem Nachmittag aufsetzen.
Eine Datei ist kein Programm. Was ein großes Unternehmen braucht, ist die Fähigkeit, über jede jemals erzeugte oder empfangene SBOM hinweg Fragen zu beantworten: Was steckt in unserer Software, wo, in welcher Version, mit welchen bekannten Schwachstellen, und zwar jetzt. Diese Fähigkeit hat wenig damit zu tun, wie die Datei erstellt wird, und alles damit, was danach mit ihr geschieht.
Wofür Teams planen | Was die Arbeit tatsächlich verschlingt |
|---|---|
SBOMs in der CI erzeugen | Millionen davon speichern und indizieren |
Ein Format wählen | Formate, Versionen und Kennungen abgleichen, die sich widersprechen |
Die Compliance-Prüfung bestehen | Antworten aktuell halten, während neue CVEs auftauchen |
Die Pipeline eines Produkts | Hunderte Teams, Lieferanten und Zukäufe |
Die linke Spalte ist ein Wochenende. Die rechte Spalte ist das Programm. Unternehmen, die beides verwechseln, liefern das Wochenende und wundern sich, warum das Programm nicht funktioniert.
Bruchstelle 1: Volumen, das niemand eingeplant hat
Ein großes Unternehmen hat nicht eine SBOM. Es hat eine SBOM pro Build, pro Service, pro Version, pro Release, über jede Produktlinie und jeden Geschäftsbereich hinweg. Ein einzelnes mittelgroßes Produkt kann Hunderte SBOMs pro Monat ausgeben. Multiplizieren Sie das über ein Portfolio, und die Zahl erreicht die Millionen, mit täglichem Wachstum. Das ist SBOM-Wildwuchs, und er bricht als Erstes.
Er bricht lautlos, weil nichts einen Fehler wirft. Der Ordner mit JSON-Dateien, der bei zehn SBOMs funktionierte, und die Tabelle, die bei hundert funktionierte, werfen bei zehntausend keine Ausnahme. Sie hören einfach auf, brauchbar zu sein, während sie noch zu funktionieren scheinen. Die Dateien stapeln sich ungelesen.
Bruchstelle 2: Keine zwei SBOMs stimmen überein
Volumen wäre beherrschbar, wenn jede SBOM gleich aussähe. Keine tut das.
Ein Geschäftsbereich erzeugt CycloneDX 1.4. Ein anderer 1.7. Ein dritter hat sich auf SPDX festgelegt, und darin gibt ein Teil der Tools noch das ältere 2.3 aus, während neuere Pipelines 3.0.1 erzeugen. Dieselbe Komponente erscheint in der einen Datei per purl, in der anderen per CPE und in einer dritten als freier Text mit Name und Version. Ein zugekauftes Unternehmen kommt mit seiner eigenen Toolchain und seinen eigenen Konventionen, von denen keine zu Ihren passt.
Versuchen Sie nun, eine portfolioweite Frage zu beantworten. Sie können keine Dateien zusammenführen, die sich in der Struktur widersprechen, und keine Komponenten deduplizieren, die sich in der Identität widersprechen. Die Abhängigkeit, die ein Team log4j-core nennt, ein anderes org.apache.logging.log4j:log4j-core und ein drittes Apache Log4j, ist dieselbe Abhängigkeit, aber kein naives System weiß das. Ohne normalisierte Komponentenidentität wird jede übergreifende Frage zu einem manuellen Abgleichsprojekt, was bedeutet, dass sie nicht beantwortet wird.
Bruchstelle 3: Die Datei ist veraltet, sobald sie geschrieben ist
Eine SBOM ist zum Build-Zeitpunkt wahr und beginnt sofort zu verfallen. Sie hält die Komponenten so fest, wie sie im Moment des Builds waren. Sie sagt nichts über die Schwachstelle, die nächste Woche gegen eine dieser Komponenten gemeldet wird.
Das ist der grundlegende Denkfehler hinter den meisten Programmen: die SBOM als abzulegendes Dokument zu behandeln statt als zu überwachende Daten. Eine abgelegte SBOM beantwortet „Was haben wir ausgeliefert.“ Die Frage, die im Ernstfall zählt, lautet „Wovon sind wir heute betroffen“, und eine statische Datei kann sie nicht beantworten. Die Komponente, die beim Release sauber war, wird in dem Moment zum kritischen Risiko, in dem eine CVE auftaucht, und ein Programm, das auf gespeicherten Momentaufnahmen beruht, bemerkt es erst, wenn jemand nachsieht, meist zu spät.
Bruchstelle 4: Lieferanten-SBOMs kommen als Durcheinander an, falls überhaupt
Ein großes Unternehmen erzeugt nicht nur Software. Es konsumiert sie, von Hunderten Anbietern, und ein wachsender Teil von Verträgen und Vorschriften verlangt von diesen Anbietern inzwischen eine SBOM.
Was ankommt, ist ungleichmäßig. Manche Lieferanten senden eine saubere, vollständige SBOM. Manche eine spärliche, bei der die Hälfte der Komponenten fehlt. Manche das falsche Format, ein PDF oder gar nichts, bis man nachhakt. Das Drittanbieter-Inventar ist genau der Ort, an dem die gefährlichsten unbekannten Komponenten stecken, und es ist tendenziell der am schlechtesten verwaltete Teil des Programms.
Bruchstelle 5: Niemand verantwortet das Ganze
Unter jedem technischen Versagen liegt ein organisatorisches. Fragen Sie, wer das SBOM-Management im Unternehmen verantwortet, und Sie ernten meist eine Pause.
Das Engineering verantwortet das Erzeugen und hält die Aufgabe für erledigt, sobald die Datei existiert. Compliance verantwortet das Audit und erscheint einmal im Jahr, um Nachweise einzusammeln. Die Produktsicherheit verantwortet Schwachstellen, oft ohne ein vollständiges, normalisiertes Inventar, mit dem sie arbeiten kann. Jede Funktion berührt ein Stück. Keine verantwortet das Ganze, und genau unter dieser Bedingung bleibt die portfolioweite Frage unbeantwortet.
Der Test, der alles offenlegt: der nächste Zero-Day. Wenn eine Schwachstelle vom Kaliber Log4Shell zuschlägt, zählt nur, wie schnell Sie „jede Stelle, an der wir betroffen sind, über jedes Produkt und jede Version hinweg, einschließlich dessen, was wir von Lieferanten erhalten haben“ beantworten können. Ein Unternehmen mit echtem SBOM-Management antwortet in Minuten. Ein Unternehmen mit einem Haufen SBOMs antwortet in Tagen, von Hand, und ist sich nie ganz sicher, ob die Antwort vollständig ist. Beide haben SBOMs erzeugt. Nur eines hat sie verwaltet.
Eine SBOM zu erzeugen ist rund zehn Prozent der Arbeit
Keine dieser Bruchstellen wird durch bessere Dateien gelöst. Sie werden durch die Ebene gelöst, die Unternehmen selten einplanen: ein einziges System of Record, normalisierte Komponentenidentität, kontinuierliche Neubewertung, Lieferanten-Ingestion und Integration in den Security-Stack. Das ist die eigentliche Arbeit, die compliance-getriebene Programme aufschieben, weil das Erzeugen der Datei die Anforderung erfüllt und das Verwalten der Datei erst an dem Tag auf einer Audit-Checkliste auftaucht, an dem es plötzlich zählt.
Die Unternehmen, die das richtig machen, hören auf, die SBOM als Liefergegenstand zu behandeln, und beginnen, sie als lebende Betriebsdaten zu behandeln. Die anderen werden weiter SBOMs erzeugen, weiter Audits bestehen und weiter den Freitagnachmittag verlieren, an dem es darauf ankommt.
Für die konkreten Maßnahmen, die jede dieser fünf Bruchstellen in Schach halten, siehe den Begleitartikel: Die Checkliste für SBOM-Management im Unternehmen.
Interlynk gibt Sicherheits- und Compliance-Teams ein einziges System of Record für jede SBOM, intern wie von Lieferanten, mit normalisierter Komponentenidentität und integriertem kontinuierlichem Monitoring. Erzeugen Sie in CycloneDX oder SPDX, halten Sie jede Ausgabe aktuell, während sich Ihre Abhängigkeiten und die Meldungen weiterentwickeln, und beantworten Sie die portfolioweite Frage nach der Betroffenheit in Minuten statt in Tagen. Vertraut von Sicherheits- und Compliance-Teams in über 100 regulierten Unternehmen.