xBOM: Das Vertrauen in softwaredefinierte Mobilität

Eine Regulierungsbehörde ordnet einen Over-the-Air-(OTA)-Rückruf für Millionen von Fahrzeugen an, nachdem die Fahrerüberwachung als unzureichend eingestuft wurde. Die Korrektur betrifft „nur Software“ – doch die Untersuchung legt verstreute Bestände offen, schwache Rückverfolgbarkeit über Steuergeräte (ECUs) und Cloud-Backends hinweg sowie keinen einheitlichen Nachweis darüber, welche Fahrzeugkomponenten tatsächlich von der neuen Sicherheitslücke betroffen sind. Händlernetzwerke, ohnehin belastet durch den Ausfall einer Drittanbieterplattform, kämpfen damit, zu verifizieren, welche VINs betroffen sind und was wann installiert wurde. 

Angesichts jüngster Rückrufe, Ausfälle und Untersuchungen wirkt dieses hypothetische Szenario beunruhigend real. Was fehlt: eine in Echtzeit abfragbare erweiterte Stückliste (xBOM), die Software, Firmware, Kryptografie, KI-Modelle, Daten und Cloud-Dienste umfasst, damit die Frage „Was ist wo drin?“ in wenigen Minuten statt in Wochen beantworten werden kann. 

Warum xBOM jetzt dringend erforderlich ist

Das Auto ist heute eines der komplexsten digitalen und verbraucherorientierten Produkte. Lieferketten lernen gleichermaßen aus den Erfahrungen von Krisen wie aus den Anforderungen der Regulierung. Aus beiden Perspektiven ergibt sich derselbe Auftrag: zu verstehen, was Fahrzeuge im Kern ausmacht und antreibt. Doch solange die einzelnen Komponenten im Verborgenen bleiben, lassen sie sich weder zuverlässig absichern noch verbessern.

Die Autoindustrie im Umbruch: Vom Fahrzeug zum digitalen System

Die Branche steht vor einer ihrer tiefgreifendsten Transformationen: Fahrzeuge werden zu dynamischen Softwareplattformen, OTA-Updates werden zum Standard, KI beschleunigt Entwicklung. Wie OEMs ihre Architekturen, Prozesse und Geschäfte neu ausrichten.

Nicole Ahner

Die aktualisierten Vorschriften der UNECE verlangen eine detaillierte Dokumentation von Software-Updates; der Cyber Resilience Act (CRA) der EU nutzt SBOMs zur Identifizierung von Schwachstellen und beschränkt die obligatorische Weitergabe an Marktüberwachungsbehörden auf bestimmte Umstände. Die Botschaft an die Hersteller lautet: Kennt eure Komponenten!

xBOM als Kontrollschicht

Die meisten Unternehmen haben die Phase einer rein statischen SBOM als bloße Checkliste längst hinter sich gelassen. Aktuell vollzieht sich ein Wandel: xBOM etabliert sich als normalisierte, abfragbare Struktur. Darauf aufbauend entsteht eine Kontrollschicht, die Sicherheits-, Cybersecurity- und Produktteams befähigt, das gesamte Fahrzeug‑Edge‑Cloud‑Kontinuum zu überwachen, Entscheidungen zu treffen und gezielte Maßnahmen einzuleiten:

• Beobachten: Welche Komponenten tatsächlich im Einsatz sind, pro ECU, Image, Modell, Datensatz oder Dienst.
• Entscheiden: Auf Basis klarer Richtlinien wie Kryptografie‑Baselines, Ausnutzbarkeit, Datenresidenz oder Sicherheitsgates.
• Handeln: Mit höchster Präzision, etwa OTA‑Updates nur für betroffene VINs, das Rotieren von Zertifikaten oder das gezielte Retraining ausschließlich relevanter Modelle.

Die Familie der xBOMs wächst nahezu täglich um neue Mitglieder: FBOM (Firmware BOM), Container/Image BOM, License/Attribution BOM, SaaSBOM bzw. Cloud BOM und weitere. Es empfiehlt sich, keine exotischen Kategorien zu schaffen, solange deren Verwaltung nicht gesichert ist. Häufig lässt sich jede Unter‑BOM an einen externen Standard oder ein Artefakt anbinden.

Aktuell erleben wir eine Neudefinition der xBOM als Kontrollschicht für SDV. Sie ist nicht länger eine statische Teileliste, sondern eine dynamische Ebene, die Sicherheits‑, Cybersicherheits‑ und Produktteams befähigt, über das gesamte Fahrzeug‑Edge‑Cloud‑Kontinuum hinweg zu beobachten, zu entscheiden und zu handeln. Dabei synchronisiert sie Compliance, Cybersicherheit, KI‑Governance und Lebenszyklusmaßnahmen über heterogene Assets hinweg.

Wie Software 2026 Systeme, Fahrzeuge und Sicherheit prägt

2026 verschieben sich die Grundlagen der Elektronikindustrie: Software definiert Systeme, Fahrzeuge werden zu Softwareplattformen, RISC-V und Rust verändern Toolchains und Cybersecurity wird durch neue Regularien zum Pflichtbestandteil jeder Entwicklung.

Nicole Ahner

Was befindet sich in der xBOM und weshalb ist jedes einzelne Element von Bedeutung?

Die xBOM lässt sich als eine Familie miteinander verbundener, standardkonformer Manifestdateien verstehen. Jede einzelne Datei wirkt dabei wie ein Signal innerhalb des Regelkreises und ermöglicht einen vollständigen, durchgängigen Überblick über sämtliche Bausteine aktueller Produkte und Systeme, weit über die reine Software hinaus. Eine xBOM ist somit eine Sammlung mehrerer Stücklisten:

• SBOM (Software): Komponenten, Versionen, Hashes, Lizenzen, Abhängigkeitsgraphen, Build-Herkunft → ermöglicht CVE-Auswirkungsprüfungen, Lizenzpflichten und gezieltes Patchen nach ECU/VIN.
• HBOM (Hardware): ECUs, Sensoren/Aktoren, SoC-Steppings, Sicherheitsenklaven → entscheidend für die Analyse des Ausmaßes von Errata und die Homologation.
• CBOM (Kryptografie): Algorithmen, Modi, Schlüsselgrößen, Bibliotheken, Zertifikate; wo Kryptografie in Boot, Diagnose, V2X, TLS, KMS/HSM zum Einsatz kommt → ermöglicht Krypto-Agilität und PQ-Migrationsplanung.
• ML-BOM (KI): Modellkarten, Datensatz-„Datenblätter“, Trainingspipelines, Bewertungsergebnisse, Herkunft → Überprüfbarkeit, Driftkontrolle und sichere Rollbacks für ADAS/IVI-KI.
• Plus: FBOM (Firmware) für Boot-Kette und Modul-Hashes; Container/Image-BOM für Basisbild-Risiken; Lizenz-/Attributions-BOM für Verpflichtungen; SaaSBOM für externe Dienste, Regionen, Unterauftragsverarbeiter und Datenflüsse.

Bewährte Vorgehensweise: Jede Unterstückliste sollte in einem etablierten Standard oder Artefakt verankert sein. Neue Kategorien dürfen nicht schneller entstehen, als sie auch verwaltet werden können. Im Mittelpunkt steht eine einheitliche Kontrolloberfläche, nicht ein Wettbewerb um die ausgefallenste Taxonomie.

Mehr als Compliance: xBOM erschließt strategische Resultate

Sichere Monetarisierung von Funktionen: Die genaue Kenntnis der Software‑, Kryptografie‑ und Modellkonfiguration pro Fahrzeugidentifikationsnummer (VIN) ermöglicht die Freischaltung kostenpflichtiger Funktionen, Testversionen und stufenweise Einführungen ohne regulatorische Überraschungen, da sämtliche Nachweise direkt im Fahrzeug vorliegen.

Senkung der Lebenszykluskosten: Gezielte OTA‑Updates und Nachschulungen verringern Händlerbesuche und den Umfang von Rückrufaktionen. Eine transparente Genealogie verkürzt Audits und die Reaktion auf Vorfälle.

Beschleunigte Innovationen: xBOM‑Diagramme identifizieren zentrale „Kingpins“ (gemeinsam genutzte Bibliotheken, Basis‑Images und Datensätze) sodass einmalige Verbesserungen vorgenommen und sicher über das gesamte System hinweg weitergegeben werden können.

GlobalLogic und Elektrobit stärken SDV-Plattformen

GlobalLogic und Elektrobit erweitern ihre langjährige Partnerschaft, um die Entwicklung künftiger SDV-Plattformen zu beschleunigen. Die Fahrzeugsoftwareentwicklung soll intelligenter, schneller und kosteneffizienter werden.

Der engste Verwandte der xBOM ist ihr vertrauenswürdiger digitaler Zwilling

Ein digitaler Zwilling ist nur so verlässlich wie sein Inventar. Die xBOM verleiht dem digitalen Zwilling eine überprüfbare Struktur, die exakt Auskunft darüber gibt, welche Teile, welche Software, welche Schlüssel, welche Modelle und welche Datenflüsse im System vorhanden sind. Dadurch werden Simulationen, Sicherheitsfälle und Was‑wäre‑wenn‑Analysen auditfähig. Auf diese Weise entwickeln sich vertrauenswürdige digitale Zwillinge von einer reinen Präsentationsidee zu einem operativen Werkzeug für OTAs, Diagnosen und regulatorische Nachweise.

Basierend auf branchenerprobten SDV-Implementierungen zeigt der folgende 90-Tage-Rhythmus einen praktischen Weg, wie sich eine operative xBOM-Praxis aufbauen lässt und erste messbare Ergebnisse entstehen.

Sichere Tupelverwendung in C++ für Fahrzeugsysteme

Die Verwendung von C++-Tupeln in sicherheitskritischer Fahrzeugsoftware bringt komplexe Herausforderungen bei Konstruktion und Test mit sich. SuperGuard ermöglicht eine gezielte Validierung, um funktionale Sicherheit zuverlässig abzusichern.

Minimaler Betriebsrhythmus (90 Tage bis zur Traktion)

• Tage 0–30: Festlegung der Signale: SBOM + FBOM pro ECU (Hashes, Lizenzen, Boot-Kette); CBOM-Bestandsaufnahme (Schlüssel/Zertifikate/Verschlüsselungen); SaaSBOM-Katalog (Dienste/Regionen/Datenflüsse). Standardisierung der IDs (VIN/ECU, Image-Digests, Zertifikats-IDs), damit die Grafiken aussagekräftig sind.
• Tage 31–60: Verbindung der Gates: Ergänzung von VEX; Definition der Gate‑Krypto‑Richtlinie (CBOM) sowie der Cloud‑Flows (SaaSBOM) in CI/CD; Verknüpfung von SBOM/FBOM mit VINs zur Sicherstellung der „As‑Built/As‑Updated“-Wahrheit.
• Tage 61–90: Integration von Data‑BOM/ML‑BOM für eine DT‑Funktion, beispielsweise ADAS; Durchführung einer Übung (Zertifikat widerrufen, Basis‑Image rotieren, Datensatz zurückrufen); Messung von MTTR und Reduzierung des Blast‑Radius.

Kulturwandel statt Kontrollwandel

Letztendlich markiert der Übergang von SBOM zu xBOM und von statischen Listen zu einer dynamischen Kontrollschicht sowohl einen kulturellen als auch einen technischen Wandel. Konsequente Transparenz und Sichtbarkeit fördern Disziplin, Kooperation und Sicherheitsbewusstsein. Was einst wie eine reine Bestandsaufnahme erschien, entwickelt sich zur stillen Architektur des Vertrauens in jedem Fahrzeug und jeder Dienstleistung und etabliert die Praxis, Unbekanntes in Bekanntes zu verwandeln. In der vernetzten, softwaredefinierten Mobilität wird diese Sichtbarkeit zu einem humanistischen Gebot: Klarheit vor Geschwindigkeit, damit Beschleunigung niemals Sicherheit übertrifft. (na)