Zu wenige Security-Engineers: Automatisierung, AI und SOP sauber

Es gibt nicht genug Leute, um diese Arbeit zu machen. Das ist die unbequeme Tatsache hinter der Automotive-Cybersecurity, und sie wird schlimmer, nicht besser.

Die Rechnung geht nicht auf

Die Workforce-Studien von ISC2 beziffern den weltweiten Cybersecurity-Mangel in Millionen, rund 4,8 Millionen nach ihrer Schätzung für 2026, wobei das Feld um etwa 87% wachsen müsste, um die Nachfrage zu decken. Rund 90% der Security-Teams berichten von einer Qualifikationslücke.

Jetzt grenze das auf Automotive ein. Ein ECU zu testen ist keine allgemeine IT-Security. Es braucht Leute, die CAN und CAN FD, UDS und DoIP, SecurityAccess, Diagnosesitzungen und die Echtzeitbedingungen eines eingebetteten Ziels kennen, und die das alles auf ISO/SAE 21434 abbilden können. Das ist eine winzige, überbuchte Teilmenge eines ohnehin knappen Felds. Gleichzeitig wächst der Markt für Automotive-Cybersecurity schnell, von rund vier Milliarden Dollar 2026 Richtung zwölf Milliarden und darüber hinaus bis in die frühen 2030er. Die Nachfrage klettert eine Steilwand hoch, während der Pool an Menschen, die tatsächlich ein Steuergerät testen können, sich kaum bewegt.

Dann zähl die Arbeit. Ein modernes Fahrzeugprogramm hat Dutzende ECUs. Jedes davon hat viele Releases auf dem Weg in die Produktion, und weitere danach. Wenn tiefes Security-Testing davon abhängt, für jedes Release jedes ECU einen aus einer Handvoll Spezialisten zu buchen, dann ist die Warteschlange länger als das Programm. Irgendetwas gibt nach, und meistens ist es das Testen.

SOP ist eine Wand, gegen die du nur einmal läufst

Der Start of Production verschiebt sich nicht. Wenn ein Fahrzeug den SOP erreicht, ändern sich die Kosten eines Security-Defekts komplett: Was vor dem Anlauf ein Kommentar im Code-Review war, wird danach zu einer Feldkampagne oder einem Rückruf. Und unter UN R155 und ISO/SAE 21434 kannst du nicht einfach ausliefern und hoffen. Du musst zeigen, dass die Maßnahmen getestet wurden und dass bekannte Probleme behandelt wurden.

Das eigentliche Ziel ist also konkret: den SOP ohne bekannte tief hängende Früchte erreichen. Kein perfektes ECU, das kann niemand versprechen, sondern eines, bei dem die offensichtlichen, hochwirksamen Funde aus der ersten Stunde beseitigt und dokumentiert sind. Diagnosedienste, die ohne Authentifizierung erreichbar sind. Schwacher oder voreingestellter SecurityAccess. Offenes XCP oder CCP. Schreibbare Identifier, die gesperrt sein sollten. Diese sind häufig, sie sind verheerend, und sie sind vollständig vermeidbar, wenn jemand bei jedem Release darauf testet.

Dieser letzte Teilsatz ist das ganze Problem. Ein einzelner Pentest vor dem SOP ist eine Momentaufnahme der Software, die du in dieser Woche hattest. Das ECU ändert sich ständig. Ein Feature, das zwei Sprints später hinzukommt, öffnet still einen Dienst wieder, und niemand testet erneut bis zum nächsten Audit, und zu diesem Zeitpunkt ist es im Auto.

Du kannst dich nicht herausstellen. Du kannst vervielfachen

Der Reflex ist, mehr Spezialisten einzustellen. Es ist der richtige Reflex und er reicht nicht, weil die Leute nicht da sind, um eingestellt zu werden, und selbst ein verdoppeltes Team kann nicht jedes Release jedes ECU manuell erneut testen.

Hier verändern AI und Automatisierung die Stückkostenrechnung, und es lohnt sich, genau zu sein, wie. AI schließt die Qualifikationslücke nicht von selbst, und wer dir erzählt, dass sie deine Security-Engineers ersetzt, will dir etwas verkaufen. Was sie gut kann, ist das Team, das du schon hast, auf ein neues Niveau zu heben: das, was ein guter Tester von Hand macht, in Engines zu kodieren, die ohne ihn laufen, sodass die knappen Menschen für die Arbeit eingesetzt werden, die nur Menschen leisten können.

Konkret: Das Wissen, wie man einen UDS-Stack enumeriert, SecurityAccess sondiert, eine Schnittstelle sicher fuzzt oder ein DoIP-Gateway durchläuft, ist stabil und wiederholbar. Es braucht nicht jedes Mal einen Spezialisten vor Ort. Es braucht einmal einen Spezialisten, um den Test zu bauen, und dann eine Maschine, die ihn bei jedem Release für immer ausführt. Der Spezialist ist dann frei für den neuen Angriffspfad, die TARA, das, was sich die Automatisierung nicht vorstellen kann.

Wie das in einem echten Programm aussieht

Genau dafür ist AutoST gebaut. Seine Engines tragen das Testwissen: UDS-Enumeration, SecurityAccess-Analyse (0x27), UDS- und CAN-Fuzzing, DoIP und SOME/IP, Android IVI. Du verdrahtest das ECU einmal mit einem Prüfstand, und von da an läuft AutoST über die API und in CI.

So verschiebt sich das Testen von “ein Spezialist, falls einer frei ist, vor dem Audit” zu “automatisch, bei jedem Major-Release”. Jeder Build jedes ECU bekommt denselben grundlegenden Security-Durchlauf. Die tief hängenden Früchte werden in dem Moment gefangen, in dem sie eingeführt werden, nicht im Auto entdeckt. Zum SOP hast du eine datierte Spur, die zeigt, dass jedes Release getestet und dass die bekannten Probleme geschlossen wurden, was auch genau das ist, was ein ISO/SAE 21434 Assessor sehen will.

Und die Handvoll Security-Engineers, die du hast, hört auf, ihre knappen Stunden damit zu verbringen, denselben schwachen SecurityAccess am vierzigsten ECU erneut zu finden. Diese Stunden fließen stattdessen in die Angriffe, die tatsächlich einen Menschen brauchen.

Die ehrliche Version

Automatisierung macht Security-Engineers nicht überflüssig. Automatisierung sorgt dafür, dass die, die du hast, zählen. AutoST übernimmt die Breite und die Regression, damit ein kleines Team ein ganzes Fahrzeugprogramm abdecken und den SOP ohne bekannte tief hängende Früchte erreichen kann. Die Tiefe, die Kreativität, die TARA und das Audit brauchen weiterhin Menschen, und Zyberum bringt auch die mit, als Team, das Tier 1, Tier 2 und OEM Programme durch genau das gebracht hat. Referenzen auf Anfrage.

Wenn dein Programm mehr ECUs als Security-Engineers hat, was auf fast alle zutrifft, dann ist diese Lücke das Problem, das AutoST schließen soll. Buch eine Demo und wir zeigen dir, wie es wirklich aussieht, jedes Release zu testen.