Fahrzeugvernetzung Warum ist Cyber-Resilienz für die Automobilbranche noch immer wichtig?

Das Cyber-Resilienz-Gesetz gilt grundsätzlich nicht für Fahrzeuge, die bereits speziellen EU-Cybersicherheitsvorschriften unterliegen. Die Automobilbranche nutzt dafür bereits Regelwerke wie UN R155 und R156 sowie die Norm ISO/SAE 21434. Durch die zunehmende Vernetzung und Softwareabhängigkeit von Fahrzeugen wird jedoch die Abgrenzung zwischen automobilspezifischen Vorschriften und den Anforderungen des CRA immer wichtiger.

Das EU-Gesetz zur Cyber-Resilienz (CRA) gilt möglicherweise nicht unmittelbar für Fahrzeuge, die bereits automobilspezifischen Cybersicherheitsvorschriften unterliegen. Fahrzeuge werden zunehmend Software-gesteuert, vernetzt und von einer immer umfangreicheren digitalen Lieferkette abhängig. Das führt zu komplexeren regulatorische Herausforderungen. Das CRA legt Anforderungen an die Cybersicherheit fest – von der Konzeption und Entwicklung über den Umgang mit Sicherheitslücken bis hin zu Sicherheitsupdates und Support. Für Automobilunternehmen gibt es jedoch eine wichtige Unterscheidung: Kraftfahrzeuge, die bereits unter den EU-Rahmen für die Typgenehmigung fallen, sind vom CRA ausgenommen. Die Branche arbeitet bereits innerhalb eines Cybersicherheitsrahmens, der die UN-Richtlinien R155 (Cybersicherheitsmanagement) und R156 (Software-Updates) umfasst und durch technische Normen wie ISO/SAE 21434 unterstützt wird. Weil aber das moderne Fahrzeug im Zentrum eines weitaus größeren digitalen Ökosystems steht, wird es immer wichtiger zu verstehen, wo die regulatorischen Grenzen des Fahrzeugs enden und die des CRA beginnen.

Das Fahrzeug ist Teil des digitalen Ökosystems

Software bestimmt die Funktionen, Konnektivität, Diagnose, Benutzererfahrung und die Möglichkeit, nach der Produktion neue Funktionen einzuführen. Zudem interagieren Fahrzeuge mit Cloud-Diensten und anderen digitalen Systemen sowie Technologieunternehmen. Einige Produkte unterliegen einem spezifischen Rechtsrahmen, andere sind eigenständig und potenziell der CRA unterworfen. Die CRA und die Vorschriften zur Cybersicherheit im Automobilbereich sind nicht austauschbar. Während sich die UN R155, UN R156 und ISO/SAE 21434 mit der Cybersicherheit in Straßenfahrzeugen befassen, betrachtet die CRA Cybersicherheit aus einer breiteren Perspektive. Die Zugehörigkeit zur Automobillieferkette alleine ist kein entscheidendes Kriterium dafür, ob ein digitales Produkt unter die CRA fällt. Unternehmen müssen die Cybersicherheitsverpflichtungen auf der Ebene einzelner Produkte verstehen.

Die Lieferkette verkompliziert das Gesamtbild

Nur wenige Automobilunternehmen entwickeln jede einzelne Software-Komponente selbst. Moderne Systeme können proprietären Code, kommerzielle Software, Open-Source-Komponenten, Betriebssysteme, Middleware, Kommunikations-Stacks sowie mit elektronischen Steuergeräten und anderer Hardware gelieferte Software enthalten.

Software-definierte Fahrzeuge erweitern diese Zusammenhänge. So kann sich Software unabhängig von traditionellen Fahrzeugproduktionszyklen weiterentwickeln, Zulieferer können Technologien bereitstellen und Open-Source-Komponenten können tief im Inneren von Produkten vorkommen, die von anderen Unternehmen geliefert werden.

Unternehmen benötigen einen Überblick über ihre Produkte und deren Cybersicherheitsverpflichtungen. Die Bestimmungen des CRA zur Meldung von Sicherheitslücken sind bereits am 11. September 2026 in Kraft getreten – im Dezember 2027 sollen noch umfassenderer Anforderungen folgen. Teams müssen im Falle einer Sicherheitslücke schnell ermitteln, welche Produkte und Versionen betroffen sind, den Schweregrad und das Gefährdungspotenzial bewerten, die verantwortliche Komponente identifizieren, Abhilfemaßnahmen umsetzen, die Änderung überprüfen und Nachweise über die durchgeführten Maßnahmen aufbewahren.

Eine SBOM ist der Anfang, nicht das Ende

Software-Stücklisten (SBOM) zeigen, welche Komponenten in einem Produkt integriert sind. Bei entdeckten Sicherheitslücken hilft das festzustellen, ob die betreffende Komponente vorhanden ist und welche Produkte einer Überprüfung bedürfen. Die Identifizierung einer Komponente ist jedoch nur der erste Schritt. Anschließend müssen Unternehmen feststellen, ob die Sicherheitslücke in ihrer Implementierung ausnutzbar ist, welche potenziellen Auswirkungen sie hat und ob Abhilfemaßnahmen erforderlich sind und funktionieren. Unter Umständen sind Regressionstests erforderlich, um zu überprüfen, ob durch die Abhilfemaßnahmen neue Probleme entstanden sind. Unter Umständen müssen auch die Sicherheitsanforderungen noch einmal überprüft werden. Während eine statische Analyse feststellen kann, ob die Änderung neue Schwachstellen gebracht hat, verbindet die Rückverfolgbarkeit Anforderungen, betroffene Software, Tests und Ergebnisse miteinander. Eine SBOM zeigt die vorhandenen Risiken, und die technische Verifizierung belegt die daraufhin ergriffenen Maßnahmen.

Software-definierte Fahrzeuge ermöglichen eine kontinuierliche Verifizierung

Software kann sich über den gesamten Lebenszyklus eines Fahrzeugs hinweg weiterentwickeln, sodass es möglich ist, auch Jahre nach der Produktion neue Funktionen einzuführen. Sicherheitslücken können erst Jahre nach der Entwicklung der ursprünglichen Software entdeckt werden. Zwar ermöglichen Over-the-Air-Updates die schnelle Bereitstellung von Änderungen, doch jedes Update kann den Cybersicherheitsstatus der Software verändern.

Ein Rückruf von Stellantis verdeutlichte das: Im August 2026 rief der Automobilhersteller weltweit rund 955.000 Fahrzeuge zurück, weil ein Software-Fehler im Radio dazu führen konnte, dass die Rückfahrkamera nicht korrekt angezeigt wurde. Als Abhilfe war ein drahtloses Software-Update vorgesehen. Obwohl es sich hierbei eher um einen Funktionsfehler als um eine Cybersicherheitslücke handelte, zeigte das, dass Software-Probleme nicht mit der Auslieferung des Fahrzeugs enden. Hersteller benötigen also Prozesse, um Probleme in bereits eingesetzter Software zu identifizieren, Änderungen umzusetzen, diese zu verifizieren und Updates in großem Maßstab zu verteilen. Im Bereich der Cybersicherheit muss die Verifizierung daher zu einem integralen Bestandteil der Softwarebereitstellung werden.

Automobilbranche bereits einen Schritt voraus

Unternehmen im Bereich der Automobiltechnik haben einen Vorteil: Sie kennen viele der Disziplinen für den Nachweis der Cybersicherheit aus der sicherheitskritischen Entwicklung. Die Norm ISO 26262 hat dazu beigetragen, strenge Verfahren in Bezug auf die Rückverfolgbarkeit von Anforderungen, Programmierstandards, statische Analyse, Komponententests, strukturelle Code-Abdeckung, Änderungsmanagement und objektive Nachweise zu etablieren. Zwar bringt die Cybersicherheit andere Risiken mit sich, doch lassen sich viele der technischen Prinzipien gut übertragen. Sicherheitsanforderungen können mit Tests verknüpft, Schwachstellen mit Standards (CERT, CWE) identifiziert und sicherheitsrelevante Funktionen mit Unit- und Integrationstests verifiziert werden. Regressionstests dienen zum Nachweis, dass es durch Korrekturmaßnahmen zu keinem unbeabsichtigten Verhalten gekommen ist. Die CI/CD-Automatisierung kann diese Aktivitäten kontinuierlich gestalten. Bei Softwareänderungen können statische Analysen und automatisierte Tests ausgeführt werden, während Sicherheitsrichtlinien zu Qualitätskontrollen avancieren. Das Ergebnis sind Nachweise während der Entwicklung, die sich im Falle eines Audits oder eines Sicherheitsvorfalls nachträglich rekonstruieren lassen.

Von KI generierter Code legt Messlatte für die Verifizierung höher

Generative KI eröffnet eine neue Dimension. Mithilfe von KI-Technologie können Entwickler Quellcode generieren, Tests erstellen, Implementierungen erläutern und Korrekturen vorschlagen. Auch wenn die Entwicklung so schneller erfolgt, bleibt die Verantwortung eines Unternehmens bestehen, sicherzustellen, dass die resultierende Software die Anforderungen an Sicherheit, Qualität und Konformität erfüllt. KI-generierter Code kann denselben Standards und Kontrollen unterzogen werden wie von Menschen geschriebene Software. KI bietet zudem Unterstützung bei der Verifizierung, indem sie Entwicklern hilft, Ergebnisse zu verstehen, Programmierprobleme zu beheben, Tests zu generieren, Randfälle zu identifizieren und Lücken in der Testabdeckung zu schließen.

Cybersicherheit endet nicht bei der Typgenehmigung von Fahrzeugen

Diagnosegeräte für Kraftfahrzeuge sind ein anschauliches Beispiel dafür, wie sich diese regulatorischen Grenzen überschneiden können: Die im Jahr 2026 verabschiedeten EU-Vorschriften für den sicheren Zugriff auf On-Board-Diagnosedaten (OBD) von Fahrzeugen sehen vor, dass Fahrzeughersteller unter bestimmten Umständen verlangen dürfen, dass Diagnosegeräte, die auf OBD-Daten zugreifen, den Anforderungen des CRA entsprechen.

Es ist wichtig, zu unterscheiden: Das Fahrzeug selbst kann weiterhin dem Rahmenwerk der Kfz-Typgenehmigung unterliegen, während für digitale Produkte zur Diagnose oder Wartung möglicherweise die Anforderungen des CRA gelten. Unternehmen der Automobilbranche können nicht davon ausgehen, dass ein einziges regulatorisches Rahmenwerk alles abdeckt, was sie entwickeln, integrieren, vertreiben oder nutzen. Verschiedene Teile des digitalen Ökosystems der Automobilbranche unterliegen unterschiedlichen Cybersicherheitsanforderungen. Deshalb sind Transparenz hinsichtlich der Softwarekomponenten, klare Sicherheitsanforderungen, Schwachstellenmanagement, automatisierte Verifizierung, Rückverfolgbarkeit und Nachweise über den gesamten Lebenszyklus der Software notwendig.

Fazit: Die Branche kennt dieses Prinzip bereits: Vertrauen muss durch Nachweise belegt werden. Im Zeitalter des Software-definierten Fahrzeugs müssen sich diese Nachweise ebenso kontinuierlich weiterentwickeln wie die Software selbst. (se)

Software-definierte Fahrzeuge

Künstliche Intelligenz: „Wir brauchen keinen Flickenteppich“

VDA Mobility Innovation Summit 2026

„Die deutsche Autoindustrie ist für zukünftige Herausforderungen gut aufgestellt – der Standort nicht“

* Ricardo Camacho, Director of Product Strategy, Embedded & Safety Compliance, Parasoft

(ID:50990530)