Software ist zum Herz von Fahrzeugen geworden und damit auch zum zentralen Einfallstor für Cyberrisiken. Darauf wird mit regulatorischen Vorgaben wie dem Cyber Resilience Act reagiert. Höchste Zeit, dass Hersteller ihre Software-Lieferketten transparent machen.
Chris Löwer Chris Löwer
2 min
Mit dem softwaredefinierten Fahrzeug wächst die Bedeutung sicherer und transparenter Software-Lieferketten: SBOMs helfen Herstellern dabei, Schwachstellen frühzeitig zu erkennen, regulatorische Vorgaben zu erfüllen und Cyberrisiken systematisch zu managen.Adobe Stock / TechLens
Anzeige
automotiveIT Kongress 2026
Der automotiveIT Kongress 2026 ist der Treffpunkt für CIOs und IT-Entscheider, die Digitalisierung in der Automobilindustrie nicht nur begleiten, sondern steuern. Am 12. Oktober in Ingolstadt treffen Sie die Automotive-IT-Community für klare Perspektiven, belastbare best Practices und Diskussionen entlang der gesamten Wertschöpfungskette – von Engineering über Produktion bis zur Cloud. Freuen Sie sich auf Keynotes und Panels, Deep Dives im Silent-Conferencing-Format sowie die IT Awards und IT Team Awards und auf Networking, das Sie fachlich weiterbringt. Jetzt Ticket sichern!
In
modernen Fahrzeugen arbeiten mitunter mehr als hundert Steuergeräte, in jedem
Fall aber Millionen Zeilen Code. Tendenz steigend. Mit d em Übergang zum
softwaredefinierten Fahrzeug wächst nicht nur die Funktionalität, sondern auch die Angriffsfläche für Cyberangriffe . Gleichzeitig verschärfen Regulierungen
weltweit die Anforderungen an die Automobilindustrie. Kurzum: Hersteller kommen
nicht umhin, ihre Software-Lieferketten transparent zu machen. Software Bills
of Materials (SBOM) werden dabei zum Schlüssel für Sicherheit, Compliance und
Wettbewerbsfähigkeit.
Die
Bedeutung von „Software Supply Chain Security“ steigt vor allem durch neue
regulatorische Anforderungen, die von Herstellern ein systematisches Management
von Cyberrisiken einfordern. Einschließlich Schwachstellenanalyse,
Meldepflichten und der schnellen Behebung kritischer Sicherheitslücken. „Für
das Fahrzeug gilt die UN EVE WP.29, die die Hersteller zu Cybersicherheit
verpflichtet, während für die Produktion die europäische NIS2-Richtlinie und
der Cyber Resilience Act gelten“, erklärt Mirko Ross, CEO des Stuttgarter
Risikoanalyse-Spezialisten asvin. „Alle diese Regelwerke verpflichten zum
Management von Cyberrisiken.“
Anzeige
In
diesem Kontext gewinnt die Software Bill of Materials an Bedeutung. „Sie
ermöglicht es, innerhalb einer Software nach bekannten Schwachstellen zu
suchen, da diese den ‚Bauplan‘ und die ‚Zutatenliste‘ einer Software abbildet“,
verdeutlicht Ross, womit die SBOM zu einem essenziellen Baustein im
Cybersicherheitsmanagement werde.
Was sind Software Bills of Materials (SBOM)?
Eine Software Bill of Materials, kurz SBOM, ist eine maschinenlesbare Stückliste aller Bestandteile einer Software. Sie dokumentiert, welche Komponenten, Bibliotheken und Module in einem Produkt enthalten sind, von wem sie stammen und in welchen Abhängigkeitsverhältnissen sie zueinander stehen. Damit schafft sie Transparenz über die Software-Lieferkette – ähnlich wie eine Zutatenliste bei Lebensmitteln. Typische Inhalte einer SBOM sind der Name und die Version einer Komponente, der Hersteller, eindeutige Identifikatoren, kryptografische Hashes, Lizenzinformationen sowie direkte und transitive Abhängigkeiten. In der Praxis werden SBOMs idealerweise automatisiert in Entwicklungs- und CI/CD-Prozesse eingebunden und in standardisierten Formaten wie SPDX oder CycloneDX erzeugt.
Komplexe
Lieferketten als Sicherheitsrisiko
Keine
triviale Aufgabe: Denn die Automobilindustrie verfügt über eine der
komplexesten Lieferketten der Welt. Fahrzeuge bestehen aus tausenden
Komponenten und Softwaremodulen verschiedener Lieferanten. OEMs entwickeln oft
nur einen Teil der Software selbst – große Teile stammen von Tier-1- und
Tier-2-Zulieferern oder aus Open-Source-Bibliotheken. Diese Struktur erschwert
den Überblick über Abhängigkeiten und Risiken erheblich. Zudem werden Fahrzeuge
zunehmend über Over-the-Air-Updates aktualisiert, wodurch sich Softwarestände
kontinuierlich verändern.
Anzeige
„Softwareprodukte
sind komplexe Gebilde mit zahlreichen Komponenten von Zulieferern,
Schnittstellen zu Cloud-Diensten und zunehmend auch KI-Anwendungen“, unterstreicht
Ross. „Hier die Übersicht zu behalten und ein aktuelles Lagebild zu bekommen,
ist eine enorme Herausforderung.“ Hinzu
kommt ein strukturelles Problem: Änderungen an der Software müssen entlang der
gesamten Lieferkette dokumentiert werden. „Das funktioniert nur, wenn OEM und
Zulieferer Hand in Hand arbeiten. Doch oft fehlen automatisierte Prozesse und
standardisierte Schnittstellen“, weiß der Experte.
Um
diese Risiken zu adressieren, fahren Hersteller zweigleisig: „Organisatorisch
geben die OEMs die Verpflichtung zur Cybersicherheit und die Stellung von SBOMs
über Liefer- und Einkaufsbedingungen weiter“, berichtet Ross. So werden
Cybersicherheitsanforderungen immer häufiger in Lieferantenverträge integriert.
Zulieferer müssen beispielsweise SBOMs bereitstellen oder nachweisen, wie sie
Schwachstellen überwachen und beheben. Gleichzeitig verlangen regulatorische
Vorgaben eine kontinuierliche Risikoanalyse über den gesamten Lebenszyklus
eines Fahrzeugs. „Technisch
ist es allerdings komplexer“, weiß Ross. Hier steht vor allem die Integration
von SBOM-Standards und automatisierten Toolchains im Fokus. Branchenweit
verbreitet sind Formate wie SPDX oder CycloneDX, die maschinenlesbare
Informationen über Softwarekomponenten liefern. Ross: „Es gibt mehrere
SBOM-Standards, und diese müssen zwischen Zulieferern und OEMs verlustfrei
konvertiert werden“, erklärt Ross. „Gehen dabei Daten verloren, leidet die
gesamte Toolchain zum Scannen von Schwachstellen.“
Die
Einführung von SBOM-basierten Sicherheitsprozessen ist jedoch nicht nur eine
technische Herausforderung. Sie erfordert auch organisatorische Veränderungen
in Entwicklungsprozessen und Zusammenarbeit. „Es geht sowohl um
Standardisierung als auch um kulturellen Wandel“, sagt Ross. „Mit einer SBOM
legen Zulieferer den Bauplan ihrer Software gegenüber dem OEM offen.“ Diese
Transparenz stößt in der Praxis teilweise auf Vorbehalte, etwa aus Sorge um
geistiges Eigentum. Gleichzeitig verlangt ein effektives SBOM-Management, dass
die Dokumentation mit jeder Softwareänderung aktualisiert wird. „Das erfordert
einen Secure Software Development Lifecycle bei OEMs und Zulieferern, der eng
verzahnt ist. Produktentwicklung und Softwareentwicklung müssen hier enger
zusammenarbeiten.“
Eine
zentrale Rolle spielt die Integration von SBOM-Erstellung und
Schwachstellenanalyse in DevSecOps- und CI/CD-Pipelines. Dabei greifen SBOMs
laut Ross an zwei Stellen: Erstens im Qualitätsmanagement der CI/CD-Pipeline.
Vor dem Deployment wird die Software automatisch auf bekannte Schwachstellen
geprüft. Zweitens dienen SBOMs als Dokumentation der tatsächlich ausgelieferten
Softwareversion. Dieser
Ansatz ermöglicht eine kontinuierliche Überwachung der Software-Lieferkette und
eine schnellere Reaktion auf neu entdeckte Schwachstellen. Automatisierte
SBOM-Analysen können beispielsweise erkennen, wenn eine veraltete
Open-Source-Bibliothek in einer Fahrzeugsoftware enthalten ist und ein
Sicherheitsrisiko darstellt.
SBOM als Wettbewerbsfaktor
Angesichts wachsender regulatorischer Anforderungen wird SBOM-Management für alle Marktteilnehmer verpflichtend. Doch der Reifegrad der Umsetzung unterscheidet sich deutlich. „Wer hier den höchsten Automatisierungsgrad erreicht, wird einen direkten Wettbewerbsvorteil haben“, sagt Ross. Man sieht: Das Thema Lieferkette ist um eine wichtige Variante reicher geworden, die niemand ignorieren kann.
