Security im Fahrzeug-Testing: Warum wir uns (mehr) mit Automotive Pentesting auseinandersetzen müssen (auch nach SOP!)

Beleuchten wir eingangs das Muster, das sich durch fast alle Fahrzeugprogramme zieht. Wer heute in ein laufendes Fahrzeugprogramm, also in die Domäne der Security in der Fahrzeugentwicklung, schaut, der findet Cybersicherheit, klar.

Zumindest auf dem Papier.

Es gibt eine TARA irgendwo in der Ordnerstruktur.

Es gibt einen Penetrationstest, der ziemlich genau für drei Monate vor SOP eingeplant ist.

Es gibt sogar konkrete Security-Anforderungen, die aus der Risiko-Analyse abgeleitet wurden und inzwischen im Requirements-Tool hängen.

Und es gibt einen oder mehrere Cybersecurity-Verantwortliche (zuletzt vermutlich eher nur noch einen), die in der Regel sogar tatsächlich wissen, worum es geht.

Und trotzdem: Wer mit den beteiligten Engineers, Testern und Projektverantwortlichen spricht, bemerkt schnell, etwas stimmt nicht. Die Aktivitäten sind zwar da, aber sie greifen nicht richtig ineinander. Der Pentest läuft, aber seine Ergebnisse kommen zu spät, um noch etwas zu ändern — und selbst wenn sie rechtzeitig kämen, ist oft unklar, wer sie wie weiterverarbeitet: als verbindliche Grundlage für Design-Entscheidungen, als Risikoakzeptanz, oder schlicht als Report, der abgeheftet wird. Die TARA existiert, hat aber die Architekturentscheidungen nicht (teilweise wirklich gar nicht!) beeinflusst. Die Anforderungen sind definiert, werden aber im Engineering nicht als handlungsleitend wahrgenommen.

Die Beobachtung ist oft ganz offensichtlich:

Cybersecurity ist in vielen Fahrzeugprogrammen formal vorhanden, aber strukturell zu spät eingebunden

Dabei wollen wir gar nicht zu sehr die stets individuellen Strukturen und Prozesse beleuchten. Vielmehr soll hier klar werden, was das für die effektive Wirksamkeit von Testing und den Security-Reifegrad des Gesamtprogramms bedeutet. Es geht dabei auch nicht primär um Compliance. Es geht um die berechtige Frage, ob Cybersecurity im Fahrzeug tatsächlich funktioniert.

Wo die eigentlichen Vehicle-Security-Probleme entstehen: nicht im Testing, sondern viel früher

Die unbequeme Wahrheit lautet: Viele der Schwachstellen, die im Penetrationstest vor SOP gefunden werden, sind nicht im Test neu aufgedeckt worden. Sie hätten längst bekannt sein müssen. Sie haben ihren Ursprung bereits Monate oder gar Jahre früher: in der Konzeptphase, bei der Auswahl der Hardware, beim Festlegen der Netzwerkarchitektur.

Drei typische Beispiele gefällig, wie Entscheidungen spätere Sicherheit strukturell limitieren? Bitte sehr:

• Eine Gateway-ECU wird ohne Hardware Security Module (HSM) ausgewählt. Damit ist frühzeitig festgelegt, wie kryptografische Schlüssel gespeichert und wie Kommunikation abgesichert werden kann. Oder eben nicht. Das lässt sich im Pentest beobachten, aber nicht mehr beheben.
• Message Authentication wird beim Entwurf der Fahrzeugnetzwerkarchitektur nicht berücksichtigt. Ein nachträgliches Retrofit ist technisch aufwendig und in vielen Projektzeitplänen schlicht nicht mehr realisierbar.
• Trust zwischen ECUs wird implizit angenommen, ohne Verifikationsmechanismus. Ein Angreifer, der eine ECU kompromittiert, kann so in anderen Systemen Schaden anrichten, die vielleicht gar nicht im Pentesting-Scope lagen.

Ja, Automotive Pentesting kann solche Entscheidungen sichtbar machen. Rückgängig machen kann es sie nicht.

In diesen Fällen wird der Penetrationstest weniger zur Entdeckung neuer Probleme und mehr zur Bestätigung alter Weichenstellungen.

Zusammengefasst ist genau das der strukturelle Kern des Problems. Und nun?

Von der Automotive Pentesting Theorie in die Praxis: 5 Bereiche, in denen sich Dinge verändern

Die gute Nachricht: Das Bewusstsein für genau diese skizzierte Problematik wächst. Die entsprechenden Verschiebungen sind in laufenden Projekten auch bereits sichtbar –

Nicht zuletzt haben die UNECE WP.29 (UN R155/156)-Regulierungen und die ISO/SAE 21434 dies zunehmend beschleunigt.

Klar, Teams ändern ihre Vorgehensweise nicht, weil irgendein Industriestandard es scheinbar vorschreibt. Sondern einfach, weil ein bestehendes, mit der Zeit veraltetes Setup unter realen Bedingungen zu brechen beginnt.

Schauen wir uns fünf Bereiche an, in denen diese Transition bereits greifbar wird:

1. Security muss in der Konzeptphase beginnen. Nicht danach.

Solange Cybersecurity erst dann einsetzt, wenn Architektur und Hardware bereits entschieden sind, bleibt Testing reaktiv. Der Hebel liegt früher: in der Phase, in der Systeme noch gestaltbar sind.

Was das konkret bedeutet: Die TARA darf kein nachgelagertes Dokument sein, das einen bereits gefällten Systementwurf beschreibt. Sie muss ein Werkzeug sein, das diesen Entwurf beeinflusst. Threat-Szenarien müssen so frühzeitig bekannt sein, dass sie in die Auswahl von ECU-Hardware, in die Definition von Kommunikationspfaden und in die Sicherheitsanforderungen an Schnittstellen einfließen können.

Entlang der ISO/SAE 21434-Methodik kommen hier die ‘Cybersecurity Goals’ und ‘Cybersecurity Claims’ zum Tragen. Aber in der Projektpraxis klafft zwischen dieser Logik und der tatsächlichen Einbindung von Cybersecurity noch häufig eine Lücke. Projekte müssen eine Verbindung schaffen zwischen „das sagt der Prozess“ und „so steht es um die Projektrealität“.

Was initial Aufwand scheint, zahlt sich aus. Für das Gesamtergebnis, für die Qualität des Security-Testings, und weil teure Last-Minute-Anpassungen kurz vor SOP damit vermieden werden. Wer Cybersecurity früh in die Konzeptphase integriert, kommt später mit weniger Findings aus dem Pentest heraus. Und mit solchen, die noch korrigierbar sind.

2. Safety und Security gemeinsam denken, nicht nebeneinander

In der klassischen Projektstruktur arbeiten Safety- und Cybersecurity-Teams immer noch parallel. Sie haben ihre eigenen Analysen, ihre eigenen Work Products, ihre eigenen Reviewzyklen. Das ist organisatorisch nachvollziehbar, aber technisch problematisch.

Systeme in modernen Fahrzeugen kennen diese Grenze nicht.

Ein manipuliertes Signal auf dem Fahrzeugnetzwerk kann gleichzeitig ein Safety-Problem und ein Security-Problem sein. Ein Fallback-Mechanismus, der für Functional Safety designed wurde, kann einen unerwarteten Angriffspfad öffnen. Und wenn Safety-Analyse (HARA) und TARA-Analyse auf unterschiedlichen Systemannahmen beruhen, entstehen Lücken, die keine der beiden Disziplinen allein schließen kann.

In Projekten, die das erkannt haben, entstehen klarere Interaktionsmodelle: gemeinsame Reviews, abgestimmte Systemmodelle, explizite Interface-Agreements zwischen den Disziplinen. Das ist selten reibungslos. Aber es ist der einzige Weg, um sicherzustellen, dass Safety- und Security-Maßnahmen sich nicht gegenseitig unterlaufen.

3. Ein einmaliger Pentest vor SOP bildet ein System ab, das sich längst weiterentwickelt hat

Software-Updates kommen regelmäßig. Backend-Services entwickeln sich weiter. Fahrzeugfunktionen hängen zunehmend von Cloud-Infrastruktur ab. Lieferanten liefern neue SW-Versionen spät im Projektzyklus. OTA-Infrastruktur wird parallel zu Hardware und Software aufgebaut.

Die Folge? Einen einzigen Penetrationstest zum Ende des Entwicklungszyklus durchzuführen bedeutet, einen Snapshot eines Systems zu erstellen, das sich permanent verändert. Das Ergebnis landet im Report und gibt Sicherheit? Nur für den Zustand, der zum Zeitpunkt des Tests bestand. Was danach kommt, ist nicht abgedeckt.

Projekte, die das verstanden (und für ihre Abläufe verinnerlicht!) haben, integrieren Testing früher und iterativer:

• Tests auf ECU-Ebene während der Entwicklung,
• Systemlevel-Assessments in Integrationsphasen,
• Backend-Tests parallel zur Backend-Entwicklung.

Das erfordert andere Prozesse, andere Tool-Infrastruktur und einen anderen Budget-Ansatz. Aber erst so entsteht ein Bild, das tatsächlich dem realen Risikoprofil des Fahrzeugs entspricht.

4. Compliance erreichen ist nicht dasselbe wie Engineering-Tiefe sicherstellen

Die ISO/SAE 21434 hat viel bewirkt. Der Standard schafft Struktur, etabliert eine gemeinsame Sprache und stellt sicher, dass bestimmte Arbeitsschritte nicht vergessen werden. Er ist eine notwendige Grundlage. (Entsprechend hat die Neuauflage von The Essential Guide to ISO/SAE 21434, das weltweit führende Nachschlagewerk, auch in 2026 seine Daseinsberechtigung. Neue Auflage, neuer Titel: 1000 Things Worth Knowing in Automotive Cybersecurity)

Aber die ISO/SAE 21434 ist keine hinreichende Bedingung für ein tatsächlich sicheres Fahrzeug. Der Punkt, an dem alle Work Products existieren und die Prozess-Checklisten abgehakt sind, kann täuschen: Er sieht aus wie ein Abschluss, ist aber nur der formale Rahmen.

Was dahinter steht, entscheidet weiterhin die Engineering-Tiefe.

Konkrete Fragen, die in diesem Moment offen bleiben können:

• Sind die identifizierten Angriffspfade nach den letzten Änderungen noch valide?
• Mitigieren die implementierten Controls die Risiken tatsächlich (oder wurden sie einmal so definiert und seitdem nicht mehr angepasst?)
• Werden Testergebnisse genutzt, um das Design zu verbessern, oder nur um Findings formal zu schließen?

Ein Beispiel: Secure Boot ist implementiert, dokumentiert und einmal getestet. Was passiert, wenn der Update-Mechanismus sich ändert? Oder wenn Keys in der Produktion anders verwaltet werden als in der Entwicklungsumgebung?

Der echte Mehrwert entsteht, wenn Testing zurück ins Engineering fließt. Wenn getroffene Annahmen hinterfragt werden, nicht nur dokumentiert.

Das setzt aber voraus, Cybersecurity konsequent nicht als einmalige Aktivität zu verstehen, die man zu einem bestimmten Projektzeitpunkt abhakt. Security muss von Anfang an strukturell verankert sein und kontinuierlich mitlaufen.

Genau das ist der Mindset-Unterschied zwischen „Compliance-Papier-Tigern“ und echtem Security Engineering.

5. Cybersecurity-Kompetenz muss intern aufgebaut werden, dauerhaft auslagern ist keine Option

Es gab eine Zeit (und die ist erst wenige Jahre her), in der Fahrzeug-Cybersecurity durch wenige externe Spezialisten oder Dienstleister abgedeckt werden konnte. Diese Zeit ist nicht vorbei. Aber so ein Ansatz alleine genügt heute nicht mehr.

Allein der Blick auf die technologische Weiterentwicklungen im Produkt Fahrzeug: Embedded Software, Fahrzeugnetzwerke (CAN, Automotive Ethernet), Backend-APIs, Cloud-Services, Telematiksysteme, teils mobile Applikationen mit Fahrzeuganbindung.

Dazu kommt: Die geforderte Tiefe im Testing wächst (etwa mit Blick auf die Test-Cases der GB 44495).

Es geht heute nicht darum, Tools auszuführen. Es geht darum zu verstehen, wie Systeme sich verhalten, wie sie versagen und wie sie manipuliert werden können. Und, sicherzustellen, dass diese gewonnenen Erkenntnisse kontinuierlich in die Entwicklung zurück fließen.

Entsprechend bauen mehr Organisationen (OEMs wie Supplier gleichermaßen) interne Teams auf, richten dedizierte Labs ein und schaffen spezialisierte Rollen.

Nicht zwangsläufig aufgrund einer besonderen Security-Überzeugung, sondern aus der faktischen Notwendigkeit heraus.

Selbstcheck: Wie steht es um Ihre Fahrzeug-Cybersecurity in der Praxis wirklich?

Ein erstes allgemeines Verständnis ist immer gut, noch besser ist immer ein ehrlicher Blick auf die eigene Situation.

Die folgenden Fragen sollen als ein erster Selbstcheck dabei helfen einzuschätzen, wie Automotive Cybersecurity im eigenen Fahrzeugprogramm / in der eigenen Entwicklungsarbeit tatsächlich integriert ist.

Ob Security formal zwar vorhanden, aber in der Praxis isoliert (nicht) erarbeitet wird.

Keine Sorge, dies ist nicht als eine weitere Audit-Checkliste gedacht, sondern als Reflexionsinstrument für die drei Rollen, die in der Praxis am häufigsten betroffen sind.

Für System Engineers, die das System bauen

• Beeinflusst die TARA tatsächlich Designentscheidungen oder beschreibt sie, was bereits entschieden wurde?
• Sind Security-Anforderungen im Arbeitsalltag klar sichtbar, wenn etwas implementiert wird?
• Haben Testergebnisse in der Vergangenheit je dazu geführt, einen Teil des Designs zu überdenken?

Für Fahrzeug-Cybersicherheits-Verantwortliche

• Konzentrieren sich die meisten Aktivitäten noch auf die Zeit kurz vor SOP?
• Fließen Findings stets konsistent und zeitnah zurück in Entwicklungsdiskussionen?
• Werden Annahmen regelmäßig validiert oder hauptsächlich dokumentiert und dann nicht mehr angefasst?

Für Projektmanager in der Fahrzeugentwicklung

• Ist Cybersecurity als kontinuierliche Aktivität im Projektplan verankert oder taucht sie nur an bestimmten Meilensteinen auf?
• Hat man tatsächlich Sichtbarkeit auf reale Risiken oder hauptsächlich auf Status, Deliverable-Fortschritt und formale Abschlüsse?
• Werden Interaktionen zwischen Safety, Security und Systems Engineering aktiv gesteuert oder dem Zufall überlassen?

Wenn einige dieser Fragen nicht leicht zu beantworten sind, ist das kein Zeichen schlechter Arbeit.

Es ist eben meistens ein Zeichen dafür, dass Cybersecurity formal etabliert – aber noch nicht vollständig in die Entwicklungsrealität integriert ist.

Der Unterschied zwischen diesen beiden Zuständen ist, wie die Praxis zeigt, erheblich.

Budgets, Prozesse, Teamgrenzen: Was sich ändert, wenn Fahrzeug-Cybersecurity (Testing) ernst genommen wird

Alle beschriebenen Verschiebungen haben sehr konkrete Auswirkungen auf das, was Cybersecurity in einem Fahrzeugprogramm bedeutet und wie Security-Aktivität heutzutage organisiert sein muss:

• Budgets verlagern sich von einmaligen Aktivitäten zu langfristigen Capabilities.
• Prozesse müssen früher starten und länger aktiv bleiben.
• Teams brauchen klare Interfaces und Verantwortlichkeiten, auch über Disziplingrenzen hinweg.
• Softwareentwickler und Engineers müssen Security-Grundlagen verstehen, nicht nur implementieren.
• Testing wird zur kontinuierlichen Disziplin, nicht zur gelegentlichen Maßnahme kurz vor dem Milestone.

Es geht nicht darum, mehr zu tun.

Es geht darum, die richtigen Dinge zum richtigen Zeitpunkt am richtigen Ort zu tun.

Und das verändert die Rolle, die Cybersecurity in der gesamten Domäne des Fahrzeug-Testings spielt, grundlegend: weg von der Absicherungsaktivität am Ende, hin zur strukturgebenden Disziplin, die ein Programm von Anfang an begleitet.

Wie könnte ein Ausblick aussehen?

Wenngleich Marktdynamiken auch vor Security keinen Halt machen, steht fest: Cybersecurity im Fahrzeugbereich wird nicht wieder gehen.

Regulatorischer Druck (Anforderungen der UN R155, ISO/SAE 21434, die tief in die nachgelagerte Zulieferkette einwirken) und zunehmend auch weitere nationale Regulierungen (wie AIS 189 in Indien, die Korea Vehicle Security Regulierung u.a.) erhöhen kontinuierlich die Anforderungen an Nachweisbarkeit und Prozessualität.

Gleichzeitig werden Fahrzeugsysteme komplexer, vernetzter und abhängiger von Software, und damit angreifbarer.

Die Frage, ob Cybersecurity im Projekt vorhanden ist, stellt sich in kaum einem Programm mehr.

Die relevante Frage ist eine andere: Wo wird Cybersecurity tatsächlich verortet? Und greift sie ein, bevor Entscheidungen getroffen sind, die später nicht mehr korrigierbar sind?

Diese Frage zu beantworten erfordert technische Tiefe über den gesamten Stack: von der ECU bis zu Backend-Systemen, von der Konzeptphase bis zum Post-Production-Betrieb.

Hier kommt der erhöhte Stellenwert von Automotive Pentesting ins Spiel.

Hier arbeitet das BreachLabz Automotive-Pentesting. Neu: mit Standort in Bangalore/Indien

Die aufgezeigten Verschiebungen — früheres Einsetzen von Security, engere Verzahnung mit Safety und Systems Engineering, iteratives Testing über den gesamten Entwicklungszyklus — erzeugen schlicht mehr Arbeit.

Für OEM-Teams, für Supplier, und ja: auch für externe Automotive-Pentesting-Dienstleister wie BreachLabz.

Gleichzeitig hat der Fokus auf Cybersecurity im Automotive Pentesting eine physische Dimension, die sich nicht wegdiskutieren lässt: Firmware-Analyse, Hardware-Angriffe, Secure-Boot-Validierung, Bussystem-Analyse — das sind nicht nur Remote-Tätigkeiten.

Das sind auch Aufgabenstellungen, die ein Bauteil in der Hand erfordern. Eine echte ECU. Ein reales Fahrzeugnetzwerk. Eine Testumgebung, die dem Produktionssystem so nah wie möglich kommt.