Für dein TeamEntwicklungsdienstleisterISO 21434

AutoST für Entwicklungsdienstleister: Security-Tests über alle Projekte

Wie Entwicklungsdienstleister mit AutoST eine Testmethode über alle Kundenprojekte nutzen, Kundendaten trennen und Nachweise übergeben, die Kunden akzeptieren.

Aktualisiert 7. Oktober 2026Diese Seite als Markdown

Kurz gesagt

Ein Entwicklungsdienstleister entwickelt und testet Steuergerätesoftware für OEMs und Tier-1, oft für mehrere Kunden gleichzeitig und mit Teams, die zwischen Projekten wechseln. AutoST gibt ihm eine Security-Testmethode, die von Projekt zu Projekt mitwandert: UDS-Enumeration, ODX- und CDD-gestützte DID- und Routinen-Scans, SecurityAccess-Prüfung und Seeded Fuzzing, mit Kundentrennung über Gruppen und Rollen und einer PDF- und SARIF-Übergabe pro Komponente. Das Wissen steckt im Profil, nicht in einem Ingenieur.

Die Aufgabe

Ein Entwicklungsdienstleister baut, was OEMs und Tier-1 nicht selbst bauen: Diagnose-Stacks, Applikationssoftware, ganze Steuergeräte, Prüfstände und Testkampagnen. Ein typisches Team arbeitet gleichzeitig für zwei oder drei Kunden, unter NDAs, die jeden Datenfluss von einem Projekt ins andere verbieten, und mit Leuten, die alle paar Monate das Projekt wechseln. Cybersecurity-Tests stehen immer häufiger im Leistungsumfang, weil der Kunde seine eigenen ISO/SAE-21434-Pflichten in der Kette weitergibt.

Was wir in solchen Projekten regelmäßig sehen, ist kein Mangel an Können, sondern an Kontinuität. Ein Ingenieur hat für den letzten Kunden ein Skript zum Sammeln von Seeds geschrieben, ein anderer hat ein Fuzzing-Setup auf seinem Laptop, und wenn beide ins nächste Projekt wechseln, geht die Methode mit. Der nächste Kunde bekommt einen anderen Test, ein anderes Berichtsformat und eine andere Vorstellung davon, was “getestet” heißt. Am Prüfstand sehen die Ergebnisse vertraut aus: Services, die in der Default Session erreichbar sind, obwohl sie Extended Session bräuchten, TesterPresent, das die Programming Session unbegrenzt offen hält, Identifikations-DIDs, die ohne SecurityAccess beschreibbar sind.

Was die Rolle aus einem Testlauf braucht

Ein Dienstleister braucht eine Testmethode, die er über Kunden hinweg wiederverwenden und in einem Format übergeben kann, das jeder Kunde akzeptiert.

Eine Methode über alle Projekte. Dieselbe UDS-Enumeration von Sessions, Services, Sub-Funktionen und DIDs, dieselbe SecurityAccess-Prüfung (0x27) und dasselbe Seeded UDS- und CAN-Fuzzing, gespeichert als Profil, das ein neuer Ingenieur am ersten Tag fahren kann.
Die Diagnosebeschreibung des Kunden. ODX-, ODX-D-, PDX- oder Vector-CDD-Import pro Steuergerät, damit DIDs die Namen des Kunden tragen und Routinen-Scans (RID) aufrufen, was definiert ist. Schreibtests sind standardmäßig aus und werden bestätigt, bevor etwas geschrieben wird.
Strikte Trennung. Gruppen pro Kundenprojekt, rollenbasierter Zugriff pro Ingenieur und die Wahl des Betriebsmodells, damit die Vertraulichkeitsbedingungen jedes Kunden erfüllt sind.
Eine saubere Übergabe. Ein PDF-Bericht pro Komponente mit datierter Historie, SARIF 2.1.0, CSV oder JSON für die Werkzeuge des Kunden und ein Fix Plan mit Was, Risiko und Fix pro Finding, den die Entwickler des Kunden oder deine eigenen abarbeiten.
Ethernet und IVI, wo Projekte es brauchen. UDS über DoIP, DoIP-Gateway-Routing und SOME/IP-Service-Tests für Ethernet-Steuergeräte, dazu Android-IVI-Checks über ADB für Infotainment-Projekte.

Typisches Setup

Der Dienstleister betreibt eine AutoST-Instanz, auf eigenen Servern oder von Zyberum in der EU gehostet, mit einer Gruppe pro Kundenprojekt. Jeder Projektprüfstand bekommt einen Carbyne-Agenten, unter Windows mit Vector-Hardware über die XL Driver Library oder unter Linux mit PEAK, Kvaser oder jedem SocketCAN-Interface, dazu Ethernet für DoIP, SOME/IP und ADB. Der Agent pollt das Backend über HTTPS, Prüfstände in einem kundenspezifischen Labornetz brauchen also keine eingehenden Ports. Verlangt ein Kunde, dass nichts sein Haus verlässt, ist eine eigene Installation auf den Servern des Kunden möglich.

Der Security-Lead besitzt die Profile und hält sie über Projekte hinweg konsistent; Projektingenieure fahren die Scans zu jedem Integrationsmeilenstein. Lizenziert wird pro getesteter Komponente, der Preis kommt nach einer Demo.

Ein sinnvolles erstes Projekt

Nimm ein laufendes Kundenprojekt, in dem Security-Tests schon im Leistungsumfang stehen.

Woche 1: Setup. Eine Gruppe für das Projekt anlegen, den Agenten am Prüfstand installieren und koppeln, die ODX- oder CDD-Datei des Kunden importieren und mit dem Kunden abstimmen, welche SecurityAccess-Level und Sessions gesperrt sein müssen.
Woche 2: Baseline. Enumeration über alle Sessions, DID- und Routinen-Scan, SecurityAccess-Prüfung. Die Findings mit der Projektleitung durchgehen und entscheiden, was an den Kunden geht.
Wochen 3 und 4: Fuzzing. Seeded UDS-Fuzzing mit TesterPresent-Lebenszeichen und DTC-Überwachung auf den Services, die das Steuergerät anbietet; jeden Crash einmal reproduzieren.
Woche 5: Übergabe. PDF und SARIF-Export mit deinem eigenen Bericht liefern und den Kunden durch den Fix Plan führen.
Woche 6: Wiederverwendung. Das Profil als Standard speichern und in einem zweiten Projekt von einem anderen Ingenieur fahren lassen, um zu prüfen, ob die Methode mitwandert.

Wie Ergebnisse in ISO/SAE 21434 und UN R155 fließen

Ein Entwicklungsdienstleister ist Zulieferer im Sinne von ISO/SAE 21434 Clause 7, und das Cybersecurity Interface Agreement mit dem Kunden legt fest, welche Verifikationsarbeit er liefert. Clause 10.4.2 fordert die Verifikation der Implementierung gegen die Cybersecurity-Spezifikation ([RQ-10-09]) und empfiehlt Komponententests mit Fuzz-Testing und Schwachstellen-Scans ([RC-10-12]); die AutoST-Berichte sind Nachweis für dieses Work Product, in jedem Projekt in derselben Form. Clause 11 ([RQ-11-01]) nennt Penetrationstests für die Validierung; die bleiben meist beim Kunden oder seinem Pentest-Dienstleister, und AutoST liefert ihnen eine Baseline.

UN R155 richtet sich an den Fahrzeughersteller, aber Absatz 7.2.2.5 verlangt, dass er seine Abhängigkeiten von Zulieferern steuert. Deshalb fließen Testnachweise gegen die Bedrohungen aus Anhang 5 die Kette hinauf, von dir zum Tier-1 und zum OEM. Ein datierter, reproduzierbarer Scan pro Komponente ist die Art Nachweis, die diesen Weg übersteht. AutoST stellt keine Zertifikate aus und macht kein Projekt konform.

FAQ

Häufig gestellte Fragen

Können wir AutoST für mehrere Kunden nutzen, ohne Daten zu vermischen?

Ja. Jedes Kundenprojekt wird eine Gruppe, die ihre Komponenten besitzt, und rollenbasierter Zugriff entscheidet, welcher Ingenieur welche Gruppe sieht. Verlangt ein Kunde, dass seine Daten in einer bestimmten Umgebung bleiben, läuft AutoST auf deinen Servern oder auf Servern, die der Kunde kontrolliert.

Unser Kunde hat schon einen eigenen Pentest-Dienstleister. Wo passt AutoST?

Davor. AutoST fährt die wiederholbaren Diagnose- und Busprüfungen während der Entwicklung, damit der Pentest des Kunden auf einer sauberen Baseline startet, statt Tage mit Findings zu verbringen, die du selbst hättest beheben können. Den Pentest ersetzt AutoST nicht und behauptet das auch nicht.

Brauchen wir die ODX- oder CDD-Datei des Kunden?

Nein, aber sie hilft. Ohne die Datei enumeriert AutoST Sessions, Services und DIDs durch Abfragen. Mit einer ODX-, ODX-D-, PDX- oder Vector-CDD-Datei bekommen gefundene DIDs ihre echten Namen, Routinen werden genau so aufgerufen, wie sie definiert sind, und optionale Schreibtests werden vor dem Lauf bestätigt.

Quellen

Passende Seiten

← Für dein Team