Ihr Kunde will eine SBOM: ein Leitfaden für Komponenten- und Softwarelieferanten

Dieser Leitfaden richtet sich an Lieferanten in einer Fertigungslieferkette: Steuergeräte (ECUs), Displays, Steuerungen, Gateways, Antriebe, Embedded-Linux-Stacks und Firmware-Module. Wenn Sie Software verkaufen und ein Kunde eine einmalige Anfrage geschickt hat, beginnen Sie mit So beantworten Sie eine SBOM-Anfrage eines Kunden; dort ist dieser Fall beschrieben.

Warum OEMs jetzt danach fragen

Die SBOM-Anfrage eines OEM ist meist dessen Regulierung, die über einen Vertrag bei Ihnen ankommt. Welche Regulierung das ist, entscheidet, was der OEM haben muss und wie viel davon an Sie weitergegeben wird.

Der Cyber Resilience Act

Nach dem Cyber Resilience Act (CRA), Verordnung (EU) 2024/2847, umfasst ein Produkt mit digitalen Elementen auch „Software- oder Hardwarekomponenten, die getrennt in den Verkehr gebracht werden“ (Artikel 3 Nummer 1). Eine Komponente, die Sie eigenständig in der EU verkaufen, ist ein eigenes Produkt, und Sie sind ihr Hersteller, mit eigener SBOM-Pflicht: Anhang I Teil II Nummer 1 verlangt „eine Software-Stückliste in einem gängigen maschinenlesbaren Format, aus der zumindest die obersten Abhängigkeiten der Produkte hervorgehen“. Ist die Komponente für die Integration in andere Produkte bestimmt, müssen Ihre Anleitungen außerdem angeben, „wie der Integrator die grundlegenden Cybersicherheitsanforderungen in Anhang I und die Anforderungen an die technische Dokumentation in Anhang VII erfüllen kann“ (Anhang II Nummer 8 Buchstabe f).

Auch die Pflichten des OEM reichen bis zu Ihnen. Hersteller müssen die gebotene Sorgfalt walten lassen, „wenn sie von Dritten bezogene Komponenten in ihre Produkte mit digitalen Elementen integrieren“ (Artikel 13 Absatz 5), und wenn er eine Schwachstelle in einer integrierten Komponente feststellt, „meldet er die Schwachstelle der Person oder Einrichtung, die diese Komponente herstellt oder wartet“ (Artikel 13 Absatz 6). Die CRA-Leitlinien der Kommission vom Juli 2026 sagen, dass Nachweise der Sorgfalt aus Unterlagen bestehen können, die vom Hersteller der Komponente stammen, und erwähnen SBOMs nicht; in der Praxis ist eine SBOM oft genau die Unterlage, die OEMs verlangen. Die Meldepflichten gelten ab dem 11. September 2026, die Verordnung insgesamt ab dem 11. Dezember 2027. Ersatzteile, die nach denselben Spezifikationen hergestellt werden wie die Komponenten, die sie ersetzen, sind ausgenommen (Artikel 2 Absatz 6). Zum Rest der Verordnung siehe Was ist der CRA? und den CRA-Leitfaden.

Fahrzeuge

Der CRA gilt nicht für Produkte, die unter die Verordnung (EU) 2019/2144 fallen, die Verordnung über die Typgenehmigung von Fahrzeugen (Artikel 2 Absatz 2 Buchstabe c). Komponenten für typgenehmigte Fahrzeuge kommen stattdessen nach Fahrzeugvorschriften auf den Markt, und diese erwähnen nie eine SBOM.

• UN-Regelung Nr. 155 (Cybersicherheit) verlangt vom Hersteller, Informationen über die Lieferkette zu sammeln und zu prüfen, um zu zeigen, dass lieferantenbezogene Risiken erkannt und gesteuert werden (5.1.1(a)), darzulegen, wie sein Cybersicherheits-Managementsystem Abhängigkeiten von beauftragten Lieferanten, Dienstleistern oder Unterorganisationen des Herstellers steuert (7.2.2.5), und für den zu genehmigenden Fahrzeugtyp lieferantenbezogene Risiken zu erkennen und zu steuern (7.3.2).
• UN-Regelung Nr. 156 (Software-Updates) verlangt, dass alle ursprünglichen und aktualisierten Softwareversionen eindeutig identifizierbar sind (7.1.1.2), und für jede RX Software Identification Number (RXSWIN) ein prüfbares Verzeichnis, das die gesamte für die RXSWIN relevante Software beschreibt (7.1.2.3).
• ISO/SAE 21434 organisiert die Cybersicherheitsarbeit zwischen OEM und Lieferant als verteilte Aktivitäten, deren Aufteilung in einer Cybersecurity Interface Agreement vereinbart wird.
• Der Auto-ISAC SBOM Informational Report (Februar 2025) enthält die Leitlinien der Branche selbst.

Im Automobilbereich kommt eine SBOM als vertragliche Anforderung, nicht als gesetzliche.

Industrieautomatisierung

IEC 62443-4-1 gilt für Lieferanten von Produkten für industrielle Automatisierungs- und Steuerungssysteme. Die Norm nennt SBOMs nicht, aber Practice 6, das Management sicherheitsrelevanter Probleme (DM-1 bis DM-6), und Practice 7, das Management von Sicherheitsupdates (SUM-1 bis SUM-5, darunter SUM-3, „Dependent component or operating system security update documentation“), sind die Stellen, an denen eine SBOM als Nachweis dient.

Maschinen

Die Maschinenverordnung (EU) 2023/1230 gilt ab dem 20. Januar 2027 und erwähnt SBOMs nicht. Ihre grundlegenden Anforderungen zum Schutz gegen Korrumpierung (Anhang III, 1.1.9) verlangen, dass für die Konformität entscheidende Software kenntlich gemacht und geschützt wird, dass die Maschine „die installierte Software, die für den sicheren Betrieb erforderlich ist, identifizieren“ kann und dass Nachweise für Eingriffe in diese Software gesammelt werden. Maschinen mit digitalen Elementen fallen außerdem unter den CRA, anders als typgenehmigte Fahrzeuge, und deshalb fragen Maschinenbauer ihre Lieferanten schon jetzt nach SBOMs. Siehe CRACI für Maschinenbauer und Industrial IoT.

NIS2 und zertifizierte Kunden

Wenn Sie wesentliche oder wichtige Einrichtungen beliefern, etwa in der Halbleiterbranche, verpflichtet NIS2 Artikel 21 Absatz 2 Buchstabe d Ihren Kunden, die Sicherheit der Lieferkette zu adressieren. SBOMs nennt der Artikel nicht. Kunden machen daraus Fragebögen, und die Maßnahmen 5.21 und 8.8 aus Anhang A von ISO/IEC 27001 sind die Stellen, an denen eine SBOM als Nachweis dient. Siehe SBOMs als Nachweis für ISO 27001, SOC 2 und NIS2.

Die Regelwerke im Vergleich

Regelwerk	Gilt für	Nennt es eine SBOM?	Was beim Lieferanten ankommt
Cyber Resilience Act	Produkte mit digitalen Elementen auf dem EU-Markt, einschließlich getrennt verkaufter Komponenten	Ja, Anhang I Teil II Nummer 1	Direkt, wenn Sie die Komponente in Verkehr bringen; über die Sorgfaltspflicht des OEM (Art. 13 Abs. 5) und seine Schwachstellenmeldungen (Art. 13 Abs. 6)
UN R155 und R156	Fahrzeughersteller, die eine Typgenehmigung anstreben	Nein	Lieferantenrisikomanagement (R155 7.2.2.5, 7.3.2) und Software-Identifikation (R156), über Verträge
ISO/SAE 21434	Cybersecurity Engineering für Straßenfahrzeuge, OEMs und Lieferanten	Nicht in ihrer öffentlichen Beschreibung	Verteilte Aktivitäten und eine Cybersecurity Interface Agreement
IEC 62443-4-1	Lieferanten von Produkten für industrielle Automatisierungs- und Steuerungssysteme	Nein	Direkt, wenn Sie der Produktlieferant sind; SBOMs dienen als Nachweis für DM und SUM
Maschinenverordnung	Maschinen und dazugehörige Produkte auf dem EU-Markt	Nein	Identifikation und Schutz der Software (Anhang III 1.1.9); der CRA gilt daneben
NIS2	Wesentliche und wichtige Einrichtungen	Nein	Fragebögen zur Lieferkettensicherheit und Vertragsklauseln (Art. 21 Abs. 2 Buchst. d, Art. 21 Abs. 3)

Welcher Weg es auch ist, der Kunde braucht dasselbe: eine genaue SBOM für jede Softwareversion, die Sie liefern.

Was OEMs typischerweise verlangen

Die Anforderungen unterscheiden sich je nach OEM, laufen aber auf dieselbe Liste hinaus. Prüfen Sie Ihre SBOM vor der ersten Lieferung dagegen.

Anforderung	Typische Erwartung
Format	CycloneDX oder SPDX, JSON oder XML, mit einer Mindestversion der Spezifikation. BSI TR-03183-2 legt CycloneDX 1.6 oder neuer oder SPDX 3.0.1 oder neuer fest.
Felder	Ausgerichtet an den CISA 2026 Minimum Elements oder an BSI TR-03183-2: Autor, Zeitstempel und für jede Komponente Name, Version, Hersteller und Kennungen
Kennungen	Eine Package URL überall, wo das Ökosystem eine hat, sonst eine CPE, damit sich Komponenten mit Schwachstellendatenbanken abgleichen lassen
Lizenzen	SPDX-Lizenzkennungen. Die Lizenzfachleute des OEM beurteilen daran das Copyleft- und sonstige Lizenzrisiko.
Hashes	Ein Hash jedes gelieferten Binarys, damit der OEM bestätigen kann, dass die SBOM die erhaltene Datei beschreibt. Das BSI verlangt SHA-512.
Tiefe	Transitive Abhängigkeiten, nicht nur die oberste Ebene
Granularität	Eine SBOM pro gelieferter Softwareversion oder Teilenummer
Lieferung und Reaktion	Ein Lieferweg und Reaktionszeiten für Fragen zu Schwachstellen

Viele OEMs prüfen das beim Eingang automatisch. Was Ihr Kunde prüft und mit welchen Tools, zeigt die SBOM-Qualitäts-Checkliste; wie die Felder in einer Datei aussehen, zeigen die SBOM-Beispiele.

Ihre SBOM bei wenig oder gar keinem Open Source

Ein Bare-Metal-Steuergerät oder eine Steuerung mit proprietärer Firmware aus modellbasierter Codegenerierung hat eine ehrliche SBOM, die kurz sein kann: die proprietäre Anwendung, Ihr Bootloader, Bibliotheken oder die Kalibrierung eines Halbleiterherstellers und Open Source wie eine Kryptografie-Bibliothek. Das ist eine gültige Antwort. Die Regeln:

• Führen Sie proprietäre Komponenten mit eigenen Kennungen auf: Name, Version und Sie selbst als Hersteller.
• Nennen Sie die bekannten Unbekannten, etwa eine Herstellerbibliothek, in die Sie nicht hineinsehen können.
• Blähen Sie die SBOM nie auf, damit sie gründlich wirkt, und lassen Sie nie eine Open-Source-Bibliothek weg, weil sie klein ist.

Für Linux-basierte Displays und Gateways gilt das Gegenteil: Hunderte oder Tausende Komponenten, darunter Kernel, Bootloader und Basissystempakete (siehe vernetzte Geräte). Eine SBOM, die nur Ihre Anwendung und ein paar Bibliotheken listet, ist das Erste, was ein empfangendes Team beanstandet. Wenn Sie mit Yocto bauen, siehe warum Scanner übersehen, was in Yocto-Builds steckt.

Verträge: was Sie vor der ersten Lieferung vereinbaren

Klausel	Warum sie wichtig ist
Abgedeckte Produkte und Softwareversionen	Damit später niemand darüber streitet, ob eine Variante oder ein Service-Release eine SBOM brauchte
Format und Spezifikationsversion	Die Eingangspipeline des Kunden weist womöglich alles andere ab
Felder und das Framework, dem sie folgen	„BSI TR-03183-2 v2.1.0“ oder „CISA 2026 Minimum Elements“ ist prüfbar; „eine vollständige SBOM“ nicht
Auslöser der Lieferung	Jedes Release, jede an den OEM gelieferte Softwareversion und jede Korrektur
Lieferweg	Das Lieferantenportal des OEM, ein sicherer Dateiaustausch oder E-Mail unter NDA
Vertraulichkeit	Ein NDA oder der bestehende Liefervertrag, der die SBOM als vertrauliche Information benennt
Nutzungsbeschränkungen	Nur für Schwachstellenmanagement und Compliance, keine Weitergabe ohne Zustimmung
Meldung von Schwachstellen, in beide Richtungen	Der OEM meldet Schwachstellen, die er in Ihrer Komponente findet (CRA Art. 13 Abs. 6); Sie melden ihm Ihre
Erwartungen an VEX	Welches Format und wie schnell Sie eine neue CVE bewerten
Aufbewahrung	Wie lange Sie die SBOM jeder Version aufbewahren, abgestimmt auf den Unterstützungszeitraum des Produkts
Genauigkeit und bekannte Unbekannte	Eine ehrliche Klausel dazu, was die SBOM abdecken kann und was nicht, schützt beide Seiten

Der SBOM Sharing Primer der CISA beschreibt den Automobilfall genauso: SBOM-Anfragen würden in die üblichen Vereinbarungen zum Informationsaustausch aufgenommen, etwa ein NDA, eine Cybersecurity Interface Agreement oder eine Development Interface Agreement.

Teilen, ohne IP preiszugeben

Eine SBOM ist nicht Ihr Quellcode. Sie listet Namen, Versionen, Hersteller, Lizenzen, Hashes und Beziehungen der Komponenten. Ihren Code, Ihre Algorithmen, Ihre Kalibrierdaten oder Ihr Design enthält sie nicht.

• Der CRA verpflichtet Hersteller nicht, die SBOM zu veröffentlichen (Erwägungsgrund 77). Sie geht auf begründetes Verlangen an eine Marktüberwachungsbehörde (Anhang VII Nummer 8).
• Die Leitlinien der CISA zum Teilen beschreiben die üblichen Wege für proprietäre Software: E-Mail unter NDA, das Lieferantenportal des Kunden oder ein sicherer Dokumentenaustausch oder ein eigenes Portal mit Zugriffskontrolle, wobei Verträge Vertraulichkeit und Zugriff regeln.
• Praktische Optionen: eine vollständige SBOM pro OEM unter Vertrag; Kennungen für proprietäre Teile, die keine internen Projektnamen verraten; und ein separates VEX-Dokument, damit Sie den Status einer Schwachstelle aktualisieren können, ohne die SBOM erneut zu senden.

Wie oft, und was nach der Lieferung geschieht

• Eine neue SBOM für jede Softwareversion, die Sie liefern, unter derselben Kennung, die der OEM flasht oder registriert. Bei Fahrzeugen knüpft das an die Software-Identifikation nach R156 an.
• Eine korrigierte SBOM, wenn Sie in einer gesendeten einen Fehler finden.
• Eine VEX-Aussage oder ein Advisory, wenn Sie eine Schwachstelle bewertet haben.

Die Folgefrage „Sind Sie von CVE-X betroffen?“ kommt mit der nächsten großen Schwachstelle. Seien Sie bereit, sie pro gelieferter Version zu beantworten; das geht nur, wenn Sie die SBOM jeder Version aufbewahrt haben.

VEX: was Ihr Kunde als Nächstes erwartet

Ein VEX-Dokument sagt, ob ein Produkt von einer Schwachstelle betroffen ist. Die Minimum Requirements for VEX der CISA (April 2023) definieren vier Status: not_affected, affected, fixed und under_investigation. Eine Aussage not_affected sollte eine von fünf Begründungen angeben oder andernfalls ein Impact Statement:

• component_not_present
• vulnerable_code_not_present
• vulnerable_code_not_in_execute_path
• vulnerable_code_cannot_be_controlled_by_adversary
• inline_mitigations_already_exist

Eine Aussage affected braucht ein Action Statement: was der Kunde tun soll. VEX gibt es in drei Formaten: das VEX-Profil von CSAF 2.0, CycloneDX VEX und OpenVEX. Die SPDX-3.0-Ausgabe von Yocto enthält standardmäßig VEX-Daten (die Variable SPDX_INCLUDE_VEX).

Beispiel aus der Praxis. Ein Linux-basiertes Display wird mit OpenSSL 3.0.8 ausgeliefert. CVE-2023-0464 beschreibt übermäßigen Ressourcenverbrauch beim Prüfen von X.509-Zertifikatsketten mit Policy Constraints. Die Policy-Verarbeitung ist standardmäßig deaktiviert, und die Software des Displays aktiviert sie nie. Der Lieferant sendet eine beispielhafte OpenVEX-Aussage:

{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "@id": "https://example.com/vex/display-fw-5.3.0-2023-0464",
  "author": "Example Displays Product Security",
  "timestamp": "2026-11-11T09:00:00Z",
  "version": 1,
  "statements": [
    {
      "vulnerability": { "name": "CVE-2023-0464" },
      "products": [{ "@id": "pkg:generic/example/[email protected]" }],
      "status": "not_affected",
      "justification": "vulnerable_code_not_in_execute_path",
      "impact_statement": "X.509 policy processing is disabled by default and the firmware never enables it."
    }
  ]
}

SBOMs wiederholbar erzeugen

Wie Sie bauen	Realistischer Weg zur SBOM
In CI gebaute Software	Die SBOM in dem Build erzeugen, der die gelieferte Software herstellt, und beim Release aufbewahren
Yocto-basiertes Embedded Linux	Die eigene SPDX-Ausgabe von Yocto (create-spdx), geprüft auf das, was sie auslässt, oder eine Aufzeichnung des Yocto-Builds
Bare-Metal-Firmware aus modellbasierten Tools	Eine Generator-Bibliothek oder ein Tool, nie ein Texteditor, mit jedem Release gepflegt und vor dem Versand validiert
Integrierte Binaries von Dritten	Fragen Sie Ihren eigenen Lieferanten nach seiner SBOM; bis sie kommt, dient eine Binäranalyse als Ersatz

Welcher Weg es auch ist, validieren Sie die Datei vor dem Versand. Die SBOM-Qualitäts-Checkliste listet die Validatoren, die Ihr Kunde voraussichtlich ausführt, CycloneDX vs SPDX hilft beim Format, und SBOM-Generierung standardisieren zeigt, wie sie über Teams hinweg einheitlich wird.

Wo CRACI passt

Für Lieferanten, die auf GitHub Actions bauen, ersetzt CRACI die GitHub-gehosteten Runner und zeichnet aus jedem Build eine SBOM auf. Jede gelieferte Version hat also bereits eine.

• Die SBOM listet, was der Build tatsächlich geladen hat, einschließlich transitiver Abhängigkeiten, mit einer Package URL pro Paket und der deklarierten Lizenz jeder Komponente.
• Die SBOM jedes Jobs trägt einen Vollständigkeitsstatus, sodass Sie wissen, was Sie senden, bevor Sie es senden.
• SBOMs lassen sich als CycloneDX oder SPDX exportieren, und CRACI unterstützt VEX.
• Überwachte SBOMs werden neu bewertet, sobald neue Schwachstellen veröffentlicht werden, und die Build-Historie zeigt, welche Builds eine verwundbare Abhängigkeit enthielten, innerhalb Ihrer Aufbewahrungsfrist.
• Yocto-Builds laufen auf CRACI-Runnern und sind dokumentiert.
• SBOMs von Drittanbietern lassen sich hinzufügen, sodass zugekaufte Komponenten zusammen mit Ihren eigenen Builds überwacht werden.

Wann CRACI nicht die Antwort ist

• Sie haben kein CI, oder Sie bauen auf GitLab, Jenkins oder einem Build-Server. CRACI unterstützt derzeit nur GitHub Actions; weitere CI-Systeme sind auf der Roadmap.
• Ihre Firmware wird von modellbasierten Tools ohne Paketabrufe erzeugt. Ein Build-Recorder bringt dort wenig.
• Sie müssen SBOMs für viele OEMs in einem Sharing-Portal bereitstellen oder SBOMs signieren. CRACI bietet beides nicht.
• Ihre Builds müssen auf Ihrer eigenen Infrastruktur laufen. Vom Kunden gehostete Runner sind auf der Roadmap.
• Ihr Kunde will einen Nachweis für das Sicherheitsmanagement Ihrer Organisation, etwa ein ISO-27001-Zertifikat oder Antworten auf einen NIS2-Fragebogen. Eine SBOM ist ein Nachweis für einen Teil davon, keine Zertifizierung. CRACIs eigenes ISO-27001-Zertifikat deckt CRACIs Dienst ab, nicht Ihren.

SBOMs für Lieferanten: häufig gestellte Fragen

Mein Kunde, ein OEM, verlangt eine SBOM. Bin ich verpflichtet, eine zu liefern?

Oft verlangt es eher der Vertrag als das Gesetz. Wenn Sie eine Komponente mit digitalen Elementen selbst auf dem EU-Markt in Verkehr bringen, verlangt der Cyber Resilience Act Ihre eigene SBOM. Andernfalls liegt die Pflicht beim OEM, der sie über seine Sorgfaltspflicht und den Liefervertrag an Sie weitergibt.

Gilt der CRA für Komponenten, die ich an einen Hersteller verkaufe?

Wenn Sie die Komponente getrennt auf dem EU-Markt in Verkehr bringen, ja: Artikel 3 Nummer 1 schließt getrennt in Verkehr gebrachte Software- oder Hardwarekomponenten ein. Gelangt sie nur im Produkt des OEM auf den Markt, ist der OEM der Hersteller und muss bei Ihrer Komponente die gebotene Sorgfalt walten lassen (Artikel 13 Absatz 5). Komponenten typgenehmigter Fahrzeuge fallen nicht unter den CRA (Artikel 2 Absatz 2 Buchstabe c).

Verlangt UN R155 oder ISO/SAE 21434 eine SBOM?

Nein. R155 erwähnt nie eine SBOM; sie verlangt vom Fahrzeughersteller, lieferantenbezogene Risiken zu steuern. ISO/SAE 21434 organisiert die Cybersicherheitsarbeit mit Lieferanten über Interface Agreements. Im Automobilbereich kommen SBOMs als vertragliche Anforderung.

Welches Format und welche Felder erwartet ein OEM?

Meist CycloneDX oder SPDX in JSON oder XML, ausgerichtet an den CISA 2026 Minimum Elements oder an BSI TR-03183-2: Autor und Zeitstempel und pro Komponente Name, Version, Hersteller, Package URL oder CPE, Lizenz und Hash, mit transitiven Abhängigkeiten.

Wie oft muss ich eine aktualisierte SBOM senden?

Für jede Softwareversion, die Sie liefern, bei jeder Fehlerkorrektur und mit einer VEX-Aussage oder einem Advisory, wenn Sie eine Schwachstelle bewertet haben. Vereinbaren Sie den Auslöser im Vertrag.

Legt das Teilen einer SBOM unser geistiges Eigentum offen?

Nein. Eine SBOM listet Namen, Versionen, Hersteller, Lizenzen, Hashes und Beziehungen von Komponenten, keinen Quellcode, keine Algorithmen und keine Kalibrierdaten. Teilen Sie sie unter einem NDA oder dem Liefervertrag, mit Nutzung nur für Schwachstellenmanagement und Compliance. Der CRA verlangt nicht, sie zu veröffentlichen.

Was ist VEX, und wird mein Kunde danach fragen?

VEX sagt, ob ein Produkt von einer Schwachstelle betroffen ist: not_affected, affected, fixed oder under_investigation, mit einer Begründung bei not_affected. Rechnen Sie damit, nach der nächsten breit gemeldeten Schwachstelle in einer Komponente, die Sie ausliefern, danach gefragt zu werden.

Unsere ECU-Firmware enthält kein Open Source. Wie sieht unsere SBOM aus?

Kurz und ehrlich: die proprietäre Anwendung, der Bootloader, Bibliotheken oder Kalibrierung eines Halbleiterherstellers und Open Source wie eine Kryptografie-Bibliothek, jeweils mit Ihren eigenen Kennungen, dazu die bekannten Unbekannten. Blähen Sie sie nicht auf.