OpenChain Automotive SBOM Framework 1.0: Die Anforderungen 2026
| Interlynk
Das OpenChain Automotive SBOM Framework 1.0 der Linux Foundation definiert einen gemeinsamen Informationssatz für die Übergabe zwischen Automobilzulieferern. Hier steht, was das Rahmenwerk verlangt, was es offenlässt und warum korrekte Generierung weiterhin entscheidend ist.
Überblick
Am 7. Oktober 2026 kündigte die Linux Foundation die Version 1.0 des OpenChain Automotive SBOM Framework an, vorgestellt auf dem Open Source Summit Europe in Prag. Das Rahmenwerk soll Automobilherstellern und Zulieferern einen gemeinsamen Weg geben, Informationen zu Softwarekomponenten entlang der automobilen Lieferkette zu beschreiben und auszutauschen.
Es ist kein Ersatz für SPDX oder CycloneDX. Stattdessen definiert es einen gemeinsamen Informationssatz und zeigt, wie sich diese Informationen in etablierten SBOM-Formaten abbilden lassen.
Diese Unterscheidung ist wichtig. Ein SBOM-Rahmenwerk kann Zulieferern vorgeben, welche Informationen sie liefern sollen. Es kann diese Informationen jedoch nicht von sich aus korrekt machen. Die Qualität des fertigen Inventars hängt weiterhin davon ab, wie es erzeugt wird und welche Nachweise jedes Feld belegen.
Rahmenwerk: Umfang und Aufbau
Die Spezifikation des Rahmenwerks gliedert ihre Arbeit in drei Bereiche: Datenfelder, Automatisierungsunterstützung sowie Praxis und Prozess. Der Bereich der Datenfelder ist der konkreteste Teil von Version 1.0. Er definiert einen Mindestsatz an Informationen zur Identifikation von Komponenten, zum Verständnis von Beziehungen und zur Unterstützung späterer Arbeiten zu Lizenzen, Schwachstellen und Rückverfolgbarkeit.
Jedes Feld ist entweder verpflichtend (Required) oder optional (Optional). Die Spezifikation führt keine gesonderte Kategorie „empfohlen" ein. Verpflichtende Felder werden in jeder Umsetzung erwartet. Optionale Felder können entfallen, sofern nicht ein Vertrag, eine Organisationsrichtlinie oder eine Branchenvorgabe sie erforderlich macht.
Der verpflichtende Feldsatz
Die erforderlichen Informationen fallen in zwei große Gruppen: Metadaten auf SBOM-Ebene und Komponentenattribute.
Auf SBOM-Ebene verlangt das Rahmenwerk den Autorennamen, den Zeitstempel, den SBOM-Typ und die primäre Komponente. Der Zeitstempel gibt an, wann das SBOM erstellt wurde, während der SBOM-Typ beschreibt, an welcher Stelle im Software-Lebenszyklus das Inventar steht. Das Rahmenwerk nutzt die sechs Typen aus der CISA-Leitlinie: Design, Source, Build, Analyzed, Deployed und Runtime.
Für jede Komponente verlangt das Rahmenwerk einen Namen, eine Version, den Lieferantennamen, die Beziehung, einen eindeutigen Bezeichner, den Dateinamen, die festgestellte Lizenz, den Urheberrechtsvermerk und externe Dokumentverweise.
Die Unterscheidung zwischen deklarierter und festgestellter Lizenz ist bedeutsam. Eine deklarierte Lizenz ist das, was der Urheber oder Herausgeber der Komponente angibt. Eine festgestellte Lizenz ist die Lizenz, die der SBOM-Ersteller nach Prüfung für maßgeblich hält. Beide können übereinstimmen, müssen es aber nicht. In Version 1.0 ist die deklarierte Lizenz optional, während die festgestellte Lizenz verpflichtend ist.
Download-Speicherort und kryptografischer Hash sind in der Feldtabelle des Rahmenwerks optional. Wird ein Hash angegeben, verwenden die Beispiele der Spezifikation SHA-256.
Die anspruchsvollsten Anforderungen sind nicht unbedingt die sichtbarsten. Ein Zulieferer kann Komponentenname und Version meist leicht befüllen, doch ein verlässlicher eindeutiger Bezeichner, der verantwortliche Lieferant und die festgestellte Lizenz können Nachforschungen erfordern, besonders wenn die Software als Binärdatei geliefert, in einen Quellbaum kopiert oder in einem SDK gebündelt wurde.
Formatneutralität und Standardbezug
Das Rahmenwerk schreibt kein einzelnes SBOM-Format und keine einzelne Formatversion vor. Es besagt, dass jedes Format verwendet werden darf, sofern es die verpflichtenden Datenfelder ausdrücken kann und die Organisation zugleich der jeweiligen Formatspezifikation folgt. Zum Zeitpunkt der Veröffentlichung genannte Beispiele sind SPDX 2.x und 3.x sowie CycloneDX 1.4, 1.5, 1.6 und 1.7.
Die Spezifikation enthält eine Abdeckungstabelle für drei konkrete Fälle: SPDX Lite gemäß SPDX 2.3, ISO/IEC 5962:2021 (SPDX 2.2.1) und CycloneDX 1.6. ISO/IEC 5962:2021 ist die veröffentlichte ISO-Norm für das SPDX-Datenformat.
Diese Tabelle legt ein praktisches Interoperabilitätsproblem offen. SPDX Lite bietet keinen direkten Platz für mehrere Anforderungen des Automotive SBOM, darunter SBOM-Typ, primäre Komponente, Komponentenbeziehung, kryptografischer Hash und externe Dokumentverweise. Ein Zulieferer kann das Datenmodell des Rahmenwerks weiterhin nutzen, doch SPDX Lite allein kann nicht jedes verpflichtende Feld der Tabelle abbilden.
Für die Felder, die sich zuordnen lassen, liefert die Spezifikation konkrete Beispiele. Der SBOM-Typ wird in der SPDX-2.2.1-Zuordnung über CreatorComment und in CycloneDX über metadata.lifecycles dargestellt. Die primäre Komponente wird einer SPDX-DESCRIBES-Beziehung und in CycloneDX metadata.component zugeordnet. Hashes werden SPDX-Package-Checksums und CycloneDX-Komponenten-Hashes zugeordnet.
Verknüpfte SBOMs und Fahrzeug-Rückverfolgbarkeit
Das Automobilmodell ist keine einzelne Anwendung, die in einem Repository entsteht. Ein Fahrzeug kann Software von vielen Zulieferern und Ebenen enthalten, deren Komponenten nach unterschiedlichen Releaseplänen gepflegt werden. Das Rahmenwerk beschreibt daher ein hierarchisches Modell statt einer einzigen riesigen Datei auf Fahrzeugebene.
In diesem Modell lassen sich SBOMs einzelner Komponenten getrennt verwalten und über externe Dokumentverweise verbinden. Die Spezifikation beschreibt die Rückverfolgbarkeit von einer Fahrzeug-Identifizierungsnummer über die zugehörige Software-Teilenummer bis zum entsprechenden SBOM. Sie weist zudem darauf hin, dass sich die Softwarekonfiguration eines Fahrzeugs nach der Auslieferung durch Nachbearbeitung oder Over-the-Air-Updates ändern kann, sodass sich auch die zugehörigen SBOM-Informationen ändern müssen.
Das ist mehr als eine Vorliebe für ein Dateiformat. Es ist ein Weg, Verantwortung und Aktualisierungen handhabbar zu halten und zugleich die für Untersuchungen nötigen Verknüpfungen zu bewahren. Wird Jahre nach Auslieferung eines Fahrzeugs eine Schwachstelle bekannt, lautet die nützliche Frage nicht einfach „Was war im ursprünglichen SBOM enthalten?". Sie lautet „Welche Softwarekonfiguration war diesem Fahrzeug zum fraglichen Zeitpunkt zugeordnet?".
Das Rahmenwerk bietet eine Struktur für diese Rückverfolgbarkeit. Es definiert jedoch nicht von sich aus die Produktlebenszyklus-Datenbank, die Update-Richtlinie oder den Schwachstellen-Reaktionsprozess eines OEM.
Grenzen von Version 1.0
Version 1.0 hält bewusst einige Informationen außerhalb ihres Kern-Feldsatzes. Dynamische Informationen wie Schwachstellenbefunde gehören nicht zum SBOM-Feldsatz. Stattdessen soll das SBOM genügend Identitäts- und Beziehungsinformationen liefern, damit Komponenten mit externen Schwachstellen- und Lizenzquellen abgeglichen werden können. Auch organisationsspezifische Geschäftsinformationen wie Fahrzeugmodelldetails liegen außerhalb des Rahmenwerks und sollten über separate, umsetzungsspezifische Schemata behandelt werden.
Das Rahmenwerk nennt zudem mehrere Punkte, die außerhalb des Umfangs von Version 1.0 liegen oder üblicherweise vom zugrunde liegenden SBOM-Format geliefert werden. Dazu zählen die Signatur des Autors, Name und Version des SBOM-Tools, die SBOM-Version sowie Name und Version des Datenformats.
Diese Abgrenzung ist sinnvoll, hat aber eine betriebliche Folge: Die Konformität mit dem Automotive-SBOM-Feldsatz ist nicht dasselbe wie ein vollständiges Governance- oder Schwachstellenmanagement-Programm. Organisationen benötigen weiterhin Prozesse zum Erzeugen von SBOMs, zum sicheren Austausch, zur Bewertung von Befunden und zur Dokumentation von Entscheidungen.
Das Generierungsproblem
Die verpflichtenden Felder setzen voraus, dass ein Zulieferer erkennen kann, was in die Software eingeflossen ist und wer dafür verantwortlich ist. Bei einem sauberen Paket aus einer öffentlichen Registry ist das unkompliziert. Bei eingebetteter und automobiler Firmware ist es weniger unkompliziert.
Firmware-Builds kombinieren häufig eingebundenen C- oder C++-Quellcode, als Binärdateien gelieferte statische Bibliotheken und SDKs von Chip-Herstellern. Manche Komponenten kommen ohne Manifest, ohne stabilen Paketbezeichner und ohne klare Lizenzmetadaten an. Ein Dateisystem-Scan findet vielleicht die Artefakte, belegt aber möglicherweise nicht deren Herkunft oder den verantwortlichen Lieferanten.
Genau hier kann ein konformes SBOM dennoch unvollständig oder irreführend sein. Jedes verpflichtende Feld mit Vermutungen zu befüllen, schafft kein vertrauenswürdiges Inventar. Der bessere Ansatz verknüpft Komponenteneinträge wo möglich mit Nachweisen aus dem Entwicklungs- und Build-Prozess. Build-bewusste Generierung kann helfen, indem sie Compiler- und Linker-Eingaben beobachtet, einschließlich Quelldateien, Archiven und SDK-Objekten, die ein rein manifestbasierter Prozess übersehen kann.
Für Interlynk beschreibt das Unternehmen genau diese Rolle für lynkctl: SBOM-Daten aus der Build-Aktivität für eingebettete und Firmware-Software zu erzeugen und anschließend mit der Interlynk-Plattform SBOM-Vollständigkeit und -Qualität zu bewerten und Änderungen zu überwachen. Das sind Produktfähigkeiten, keine Anforderungen des OpenChain-Rahmenwerks. Der übergeordnete Punkt ist unabhängig von einem einzelnen Werkzeug: Das Rahmenwerk definiert die auszutauschenden Informationen, während der Generator bestimmt, ob die gelieferten Informationen durch Nachweise gestützt sind.
Erste Schritte für Zulieferer
Ein Zulieferer, der Version 1.0 bewertet, kann mit vier Prüfungen beginnen:
Die aktuelle SBOM-Ausgabe mit den verpflichtenden Feldern des Rahmenwerks vergleichen.
Bestätigen, dass das gewählte Dokumentformat jedes verpflichtende Feld ausdrücken kann; SPDX Lite reicht allein möglicherweise nicht aus.
Prüfen, wie der Prozess mit eingebundenem Quellcode, Binärbibliotheken, SDK-Inhalten und Komponenten mit unklarer Lizenz- oder Lieferantenangabe umgeht.
Festlegen, wie SBOMs auf Komponentenebene miteinander und mit den Produktdatensätzen für die Rückverfolgbarkeit nach Auslieferung verknüpft werden.
Das Ziel ist nicht bloß, eine Datei zu erzeugen, die eine Schemaprüfung besteht. Es geht darum, Komponenteneinträge zu erzeugen, die eine andere Organisation identifizieren, interpretieren und der richtigen Softwarekonfiguration zuordnen kann.
Fazit
Das OpenChain Automotive SBOM Framework 1.0 ist nützlich, weil es eine Zuliefererübergabe konkreter macht. Es definiert einen gemeinsamen Feldsatz, unterstützt ein Modell verknüpfter SBOMs und bleibt mit etablierten Formaten kompatibel, statt einen weiteren proprietären Dokumenttyp zu schaffen.
Seine Grenzen sind ebenso wichtig. Es wählt kein einzelnes Format, klärt nicht jede Prozessfrage und liefert keine Schwachstellenbefunde. Vor allem löst es nicht das Nachweisproblem für Komponenten, die in Firmware-Builds vergraben sind oder ohne nützliche Metadaten geliefert werden.
Das Rahmenwerk gibt der Branche eine klarere Definition dessen, was ausgetauscht werden sollte. Die nächste Herausforderung besteht darin, sicherzustellen, dass das Ausgetauschte auch korrekt ist.
Quellen
Linux Foundation: Ankündigung zur Veröffentlichung des OpenChain Automotive SBOM Framework 1.0
OpenChain Automotive SBOM Framework – Spezifikation (GitHub)
Über Interlynk. Interlynk bietet Werkzeuge zum Erzeugen, Verwalten und Operationalisieren von SBOMs entlang der Software-Lieferkette. Das Produkt lynkctl ist auf die build-bewusste SBOM-Generierung für eingebettete und Firmware-Software ausgerichtet, während die Interlynk-Plattform die Aufnahme von SBOMs und CBOMs, die Qualitätsbewertung, die Risikobewertung und Änderungsbenachrichtigungen unterstützt.
Demo buchen · Kostenlos starten
Dieser Artikel dient der Information und stellt keine Rechts- oder Compliance-Beratung dar. Konformitätsanforderungen von Rahmenwerken, regulatorische Pflichten und Branchenvorgaben entwickeln sich weiter; prüfen Sie die aktuellen Anforderungen anhand der Primärquellen und mit Ihrer eigenen Rechtsberatung.