SBOM Delivery: Methoden, Anforderungen und Setup

Eine SBOM zu erstellen ist nur der erste Schritt. Sie müssen die richtige SBOM auch beim richtigen Empfänger abliefern, im passenden Format und für genau die Produkt- und Firmware-Version, die dort im Einsatz ist. Bei vernetzten und embedded Produkten muss dieser Prozess lange Lebenszyklen, Zulieferabhängigkeiten, Kundenanfragen und regulatorische Vorgaben tragen, etwa aus dem Cyber Resilience Act (CRA) und den Regeln der US-Behörde FDA. Auch Common-Criteria-Evaluierungen stützen sich auf detaillierte Konfigurations- und Schwachstellennachweise. Eine kontrollierte SBOM Delivery wird damit zu einem festen Teil von Produktsicherheit und Compliance.

Die SBOM Definition, die verschiedenen SBOM-Typen und die typischen Anwendungsfälle stehen im eigenen Artikel. Dieser Beitrag setzt danach an: Er behandelt den Weg der fertigen SBOM zum Empfänger.

Was bedeutet SBOM Delivery?

SBOM Delivery ist der kontrollierte Prozess, eine freigegebene SBOM einem vorgesehenen Empfänger oder System verfügbar zu machen. Die SBOM selbst ist ein strukturiertes Inventar von Softwarekomponenten und Abhängigkeiten. Die Delivery regelt, wohin die Datei geht, wer darauf zugreifen darf, welche Version sie abbildet und wie Aktualisierungen den Empfänger erreichen. Die CISA behandelt Verteilung und Austausch einer SBOM als eigenen Teil des SBOM-Lebenszyklus und nicht als dieselbe Aufgabe wie das Erstellen des Inventars.

Diese Unterscheidung zählt für die Produktsicherheit. Eine korrekte SBOM kann in der Praxis versagen, wenn Kunden eine veraltete Datei erhalten, die zugehörige Produktversion nicht erkennen oder das Format nicht importieren können. In einem SBOM-Cybersecurity-Prozess sollte die Delivery die Nachvollziehbarkeit zwischen SBOM, Produkt-Release und späteren Schwachstelleninformationen erhalten.

SBOM Delivery und SBOM-Erstellung: Wo der Unterschied liegt

Beim Erstellen einer SBOM entsteht das Inventar. Die SBOM Delivery macht dieses Inventar außerhalb des erstellenden Systems nutzbar. Eine SBOM erstellen können Sie beim Build, aus einer Quellcode-Analyse, aus einem Binär- oder Firmware-Scan oder durch den Import von Zulieferdaten. Die Delivery beginnt, sobald Sie die freigegebene SBOM verpacken, veröffentlichen, übertragen, zugänglich machen oder auf andere Weise einem Kunden, einer Behörde, einem Prüfer, einem Partner, einem internen Team oder einer automatisierten Plattform übergeben.

Die beiden Prozesse brauchen getrennte Kontrollen, weil sie unterschiedlich scheitern. Eine vollständige SBOM kann beim falschen Kunden landen, während eine gut entworfene API ein unvollständiges Inventar tadellos verteilt. Das SBOM Management Tool von ONEKEY erstellt, importiert, führt zusammen, überwacht und exportiert SBOM-Daten in Standardformaten wie CycloneDX und SPDX. Das verbindet die Inventarstufe mit einer wiederholbaren Weiterverwendung.

Warum SBOM Delivery stärker geprüft wird

Behörden und Einkäufer erwarten Softwaretransparenz zunehmend als laufenden Prozess und nicht als einmaliges Dokument. Der CRA verlangt von Herstellern, Schwachstellen und Komponenten ihrer Produkte zu identifizieren und zu dokumentieren, unter anderem durch eine SBOM in einem gängigen maschinenlesbaren Format, die mindestens die Abhängigkeiten der obersten Ebene abdeckt. Die FDA-Anforderungen für sogenannte Cyber Devices gehen in einem anderen Kontext weiter und verlangen eine SBOM als Teil bestimmter Zulassungsunterlagen.

Auch das Lieferkettenrisiko verändert sich nach dem Release, denn neue CVEs können Komponenten betreffen, die zum Auslieferungszeitpunkt als unbedenklich galten. Ihr Delivery-Modell sollte aktualisierte Daten und, wo sinnvoll, den Schwachstellenstatus neben dem Komponenteninventar tragen. Der SBOM-VEX-Workflow trennt die Frage „Was steckt in diesem Produkt?“ von der Frage „Betrifft diese Schwachstelle dieses Produkt?“. Das ist wichtig, wenn Kunden SBOMs für laufende Risikoentscheidungen nutzen.

Die NIS-2-Richtlinie liefert einen weiteren Grund, den Prozess zu verbessern, auch wenn sie keine pauschale Pflicht zur SBOM Delivery schafft. Artikel 21 verlangt von wesentlichen und wichtigen Einrichtungen, Cybersicherheitsrisiken zu steuern, einschließlich Lieferkettensicherheit und Beziehungen zu direkten Zulieferern und Dienstleistern. Ein verlässlicher SBOM-Austausch unterstützt diese Arbeit, weil er eine versionsspezifische Sicht auf Softwareabhängigkeiten gibt. Die weiteren NIS-2-Maßnahmen ersetzt er jedoch nicht.

4 Fragen, die Sie vor jeder SBOM Delivery klären sollten

Ein Delivery-Prozess beginnt mit vier Entscheidungen und nicht mit einem E-Mail-Anhang oder einem Export-Button. Diese Entscheidungen verhindern die typischen Konflikte über Umfang, Zugriff, Format und Zeitpunkt. Sie geben Produkt-, PSIRT-, Entwicklungs-, Compliance- und Kundenteams zudem eine gemeinsame Definition davon, was „ausgeliefert“ bedeutet.

1. Wer ist der Empfänger? Klären Sie, ob die SBOM für eine Behörde, eine Zertifizierungsstelle, einen Prüfer, einen Unternehmenskunden, einen Distributor, ein internes Sicherheitsteam oder eine automatisierte Plattform bestimmt ist. Der Empfänger bestimmt Zugriffskontrollen, erforderliche Metadaten, vertragliche Pflichten und die Frage, ob neben der maschinenlesbaren Datei ein menschenlesbarer Kontext nötig ist.
2. Welches Produkt beschreibt sie genau? Binden Sie die SBOM an eine Produktkennung, die Firmware- oder Softwareversion, das Release-Datum, wo relevant die Hardwarevariante und den Erstellungszeitpunkt. Vernetzte Produkte haben oft mehrere Zweige im Feld, deshalb genügt „die neueste SBOM“ nicht, wenn Kunden ältere unterstützte Versionen betreiben.
3. Welches Format und welche Datenfelder sind gefordert? Vereinbaren Sie Schema, Version, erforderliche Komponentenfelder, Tiefe der Abhängigkeiten, Kennungen und gewünschte Anreicherungen vor der Auslieferung. CycloneDX und SPDX sind verbreitete maschinenlesbare Formate, eine gültige Datei braucht aber genug Daten für die Werkzeuge und Richtlinien des Empfängers.
4. Wie funktionieren Updates und Zugriff? Legen Sie fest, ob die Auslieferung einmalig, releasebezogen, geplant oder dauerhaft über ein Portal oder eine API erfolgt. Regeln Sie Authentifizierung, Aufbewahrung, ersetzte Versionen, Benachrichtigungen und den Nachweis, dass ein Empfänger das richtige Artefakt erhalten hat oder abrufen konnte.

Methoden der SBOM Delivery im Vergleich

Es gibt keinen Kanal, der zu jedem Produkt und jedem Kunden passt. Eine Medizinprodukt-Einreichung, ein OEM-Zulieferaustausch, eine öffentliche Open-Source-Veröffentlichung und ein interner PSIRT-Prozess brauchen unterschiedliche Kontrollen. Die beste Methode gibt dem Empfänger verlässlichen Zugriff, ohne die Nachvollziehbarkeit zur Produktversion zu verlieren oder Informationen offenzulegen, die Ihre Richtlinie als geschützt behandelt.

Eine öffentliche Auslieferung ist nicht automatisch falsch, eine private nicht automatisch sicher. Ihre Entscheidung sollte die Sensibilität der Komponentendaten, regulatorische Pflichten, Kundenverträge und den Zweck der SBOM abbilden. Eine öffentliche URL funktioniert gut, wenn Transparenz gewollt ist. Authentifizierter Zugriff ist oft besser, wenn die Datei Produktdetails enthält, die nur freigegebene Empfänger sehen sollen.

Maschinenbasierte Methoden gewinnen an Wert, je breiter Ihr Produktportfolio wird. APIs und Repositories reduzieren manuelle Arbeit, brauchen aber starke Identitäten, Autorisierung, Protokollierung und Versionskontrolle, damit Automatisierung nicht das falsche Artefakt schneller verteilt. Die Methode sollte außerdem ältere SBOMs für unterstützte Firmware-Versionen erhalten, statt die Historie zu überschreiben.

So richten Sie eine automatisierte SBOM Delivery ein

Automatisierung wirkt am besten, wenn die Auslieferung an ein Produktereignis gebunden ist, etwa ein Release, einen freigegebenen Firmware-Build, eine behördliche Einreichung oder eine Kundenberechtigung. Der Ablauf sollte die SBOM vor der Veröffentlichung validieren und genug Nachweise erhalten, um belegen zu können, was genau ausgeliefert wurde. Aus einem Ad-hoc-Anfrageprozess wird damit eine wiederholbare Kontrolle der Produktsicherheit.

Ein praktikabler automatisierter Ablauf kann diese Schritte nutzen:

5. SBOM erstellen oder importieren. Erstellen Sie das Inventar aus dem betreffenden Build oder analysieren Sie das Firmware-Binary und führen Sie geprüfte Zulieferdaten bei Bedarf zusammen.
6. Struktur und Umfang validieren. Prüfen Sie Schema, erforderliche Felder, Komponentenbeziehungen, Produktkennung, Firmware-Version und Zeitstempel vor der Freigabe.
7. Release-Richtlinie anwenden. Bestätigen Sie, dass die SBOM zu einer freigegebenen Produktversion gehört und Format sowie Offenlegungsregeln des Empfängers erfüllt.
8. Über den freigegebenen Kanal veröffentlichen. Exportieren Sie in das Portal, das Repository, den API-Endpunkt, den sicheren Transferort oder das Einreichungspaket, das für diesen Empfänger vorgesehen ist.
9. Benachrichtigen oder Status maschinenlesbar bereitstellen. Informieren Sie menschliche Empfänger über eine neue Version oder lassen Sie nachgelagerte Werkzeuge das neue Artefakt über eine API oder ein Repository-Ereignis erkennen.
10. Nachweise dokumentieren. Bewahren Sie SBOM-Version, Produktzuordnung, Veröffentlichungszeitpunkt, Ziel, Zugriffsstatus und die von Ihrem Prozess genutzte Prüfsumme oder Release-Kennung auf.
11. Überwachen und bei Bedarf erneut ausliefern. Erstellen Sie eine neue SBOM, wenn sich die Softwarezusammensetzung ändert, und halten Sie den Schwachstellenstatus in einem getrennten, aber verbundenen Prozess, sobald neue Sicherheitsinformationen auftreten.

ONEKEY erstellt SBOMs aus kompilierten Binaries ohne Quellcode, führt SBOM-Eingaben zusammen, exportiert Standardformate und überwacht das entstehende Produktinventar laufend auf Schwachstellen. Das hilft in Embedded-Umgebungen, in denen die ausgelieferte Firmware von dem abweichen kann, was Repositories allein nahelegen. Die Automatisierung sollte dennoch Ihrer Freigabe- und Offenlegungsrichtlinie folgen, besonders wenn Kunden oder Behörden unterschiedliche Anforderungen stellen.

Anforderungen je Regulierung

Die SBOM-Anforderungen von CRA, NIS-2-Richtlinie und FDA sind nicht identisch. Manche Vorschriften verlangen die Erstellung, manche die Einreichung in einem definierten Verfahren, andere schaffen breitere Lieferkettenpflichten, in denen eine SBOM als nützlicher Nachweis dient und nicht als ausdrücklich benannte Pflichtlieferung. Ihre Compliance-Prozesse, von der UNR 155 Compliance im Automotive-Bereich bis zum CRA, sollten jedes Produkt und jeden Markt der tatsächlich geltenden Anforderung zuordnen, statt jede SBOM-Anfrage als dieselbe Pflicht zu behandeln.

Der CRA-Punkt wird leicht falsch gelesen. Anhang I verpflichtet Hersteller, die SBOM zu erstellen, während Anhang II den Nutzerzugriff nur für den Fall regelt, dass der Hersteller die SBOM zugänglich machen will. Die Verordnung verlangt außerdem, technische Dokumentation zu führen und Konformität nachzuweisen. Ihre interne SBOM muss also kontrolliert, aktuell und abrufbar sein, auch wenn Sie sie nicht öffentlich bereitstellen.

Die FDA schafft ein klareres Einreichungsereignis für Cyber Devices. Section 524B(b)(3) verlangt eine SBOM für die betroffenen Zulassungsunterlagen, und die aktuelle FDA-Leitlinie von 2026 empfiehlt maschinenlesbare SBOMs im Einklang mit den anerkannten Mindestangaben sowie Angaben zur Komponentenunterstützung. Produktteams sollten diese behördliche Einreichung vom laufenden Kundenzugriff trennen, denn die FDA empfiehlt zusätzlich, Nutzern aktuelle SBOM-Informationen zu geben und Online-Links bei Portalnutzung korrekt zu halten.

Common Criteria (ISO/IEC 15408) verlangt keine SBOM Delivery. Die Evaluierungsnachweise richten sich nach dem Security Target, dem geltenden Protection Profile und den Regeln des Zertifizierungsschemas. Die Assurance-Familie ALC_DEL regelt zwar Auslieferungsverfahren, betrifft aber den Schutz des evaluierten Produkts auf dem Weg zum Anwender und nicht die Weitergabe einer SBOM. Eine gut kontrollierte SBOM kann trotzdem als Nachweis für Softwarezusammensetzung und Schwachstellenanalyse dienen und damit dieselbe Datenbasis nutzen wie Ihre CRA-Dokumentation.

Typische Fehler bei der SBOM Delivery

Die meisten Probleme entstehen nicht durch das SBOM-Format allein. Sie kommen von schwacher Produktzuordnung, unklarer Verantwortung und Prozessen, die mit dem Export enden. Ein guter SBOM-Cybersecurity-Prozess macht es schwer, eine veraltete oder falsch zugeordnete SBOM zu versenden, und leicht, das zu jedem Release gehörende Artefakt nachzuweisen.

Typische Fehler sind:

• „Die neueste SBOM“ ohne Versionsabgleich senden. Ein Kunde betreibt möglicherweise eine Firmware, die zwei Releases zurückliegt. Das neueste Inventar zeichnet dann ein falsches Bild der Exposition.
• Eine SBOM als Schwachstellenbericht behandeln. Eine SBOM listet Komponenten und Abhängigkeiten. Schwachstellenfunde und Aussagen zur Ausnutzbarkeit brauchen verbundene Daten und werden häufig über VEX oder andere Sicherheitsdokumente kommuniziert.
• Alte SBOMs überschreiben. Langlebige Geräte brauchen historische Inventare, denn ältere unterstützte oder ausgelieferte Firmware bleibt jahrelang im Feld.
• E-Mail als Standardkanal nutzen. Anhänge lassen sich schwer widerrufen, aktualisieren und über viele Kunden hinweg verfolgen, auch wenn E-Mail für eine Einzelübergabe akzeptabel ist.
• Ohne Offenlegungsrichtlinie veröffentlichen. Öffentlicher SBOM-Zugriff kann sinnvoll sein, die Entscheidung sollte aber bewusst fallen und zu Verträgen, Produktsicherheitsrichtlinie und den enthaltenen Daten passen.
• Einmal erstellen und nie aktualisieren. Die Zusammensetzung ändert sich mit Abhängigkeiten, Firmware oder Zulieferkomponenten. Die Delivery muss deshalb an Release- und Lebenszyklusprozesse gekoppelt sein.
• Die Qualität von Zulieferer-SBOMs ignorieren. Importierte Dateien nutzen unterschiedliche Kennungen, Abhängigkeitstiefen oder Namenskonventionen. Beim Zusammenführen in Produktinventare entstehen daraus Lücken.
• Regulatorische Nachweise mit Kundenauslieferung verwechseln. Eine Datei für eine FDA-Einreichung oder ein Evaluierungspaket ist nicht zwingend dasselbe Artefakt, Zugriffsmodell oder Kontext, den ein Kunde braucht.

Die letzte Kontrolle ist Verantwortung. Produktteams sollten wissen, wer die Freigabe einer SBOM erteilt, wer den Delivery-Kanal betreibt, wer Rückfragen von Empfängern beantwortet und wer einen Austausch auslöst, wenn sich die Produktzusammensetzung ändert. Ohne diese Rollen werden auch technisch einwandfreie SBOM-Dateien zu veralteten Compliance-Artefakten statt zu nützlichen Sicherheitsdaten.