# AutoST für Tier-1-Zulieferer: Teste dein Steuergerät, bevor der OEM es tut

> Ein Tier-1-Zulieferer muss ein Steuergerät liefern, das die Cybersecurity-Anforderungen des OEM erfüllt, und das in einem Verifikationsbericht belegen. AutoST erledigt den wiederholbaren Teil davon am eigenen Prüfstand: UDS-Enumeration, DID- und Routinen-Scan aus der eigenen ODX oder CDD, SecurityAccess-Prüfung und reproduzierbares Fuzzing, vor jeder Musterphase. Findings landen als priorisierte Fix-Plan-Aufgaben bei der Firmware-Entwicklung, mit dem Request, der sie ausgelöst hat.

Wie Tier-1-Zulieferer mit AutoST ihre Steuergeräte vor jeder Musterphase gegen die Security-Anforderungen des OEM testen und auditfeste Nachweise übergeben.

Source: https://auto-st.com/de/fuer/tier-1-zulieferer · Updated: 2026-10-07

## Die Aufgabe

Ein Tier-1-Zulieferer bekommt vom OEM eine Cybersecurity-Anforderungsspezifikation, baut das Steuergerät und muss in einem Verifikationsbericht zeigen, dass jede Anforderung erfüllt ist. Nach ISO/SAE 21434 Clause 7 steht die Arbeitsteilung in einem Cybersecurity Interface Agreement: wer die TARA macht, wer welche Maßnahme verifiziert, wer welches Work Product liefert. Das Testen landet fast immer beim Zulieferer, für jede Musterphase, für jede OEM-Variante und für jedes Software-Release nach dem Produktionsstart.

Am Prüfstand sieht die Realität anders aus als im Agreement. In Penetrationstests von Leistungselektronik-Steuergeräten für Tier-1-Zulieferer, darunter ein DC/DC-Wandler und ein On-Board-Charger, haben wir SecurityAccess-Seeds gefunden, die konstant waren oder aus der Laufzeit abgeleitet wurden, keinen Fehlversuchszähler nach falschen Keys, Identifikations-DIDs wie Seriennummer und Fingerprints, die ohne SecurityAccess beschreibbar waren, und Resets bei fehlerhaften ISO-TP First Frames. Nichts davon war intern aufgefallen, denn der einzige Test vor dem Pentest war der Diagnosetester, der prüft, ob die spezifizierten Services funktionieren.

## Was die Rolle aus einem Testlauf braucht

Die Test- und Cybersecurity-Ingenieure beim Zulieferer brauchen einen Lauf, der zum Mustertakt passt und den Entwicklern etwas Konkretes in die Hand gibt.

- **Ein wiederholbares Profil pro Musterphase.** Dieselbe Enumeration von Sessions, Services und DIDs, dieselbe SecurityAccess-Prüfung (0x27) und dasselbe Seeded Fuzzing vor A-, B- und C-Muster. Eine Regression zwischen zwei Releases zeigt sich so als Diff und nicht als Überraschung im Labor des OEM.
- **Die eigene Diagnosebeschreibung.** Der ODX- oder CDD-Import benennt jede DID und ruft die Routinen auf, die das Steuergerät wirklich definiert. Die Schreibtests auf DIDs (0x2E) prüfen, was das Steuergerät annimmt, mit Bestätigung, bevor irgendetwas geschrieben wird.
- **SecurityAccess-Prüfungen, die zur Implementierung passen.** Zufälligkeit der Seeds über viele Requests, Key-Rückgewinnung bei schwachen Algorithmen und ein Katalog bekannter Default-Keys, Sperre nach falschen Keys, erzwungene Reihenfolge und der optionale Reset-Test. Der Zulieferer hat den Algorithmus geschrieben; der Lauf sagt ihm, ob er hält.
- **Reproduzierbares Fuzzing.** Ein gespeicherter Seed pro Lauf und die exakte Payload pro Finding, damit der Firmware-Entwickler den ISO-TP-Frame oder das übergroße TransferData nachspielen kann, das das Steuergerät aufgehängt hat.
- **Ausgaben für Entwickler.** Fix-Plan-Aufgaben, nach Schweregrad sortiert, mit Was, Risiko und Fix, exportiert als SARIF, CSV oder JSON in den Tracker, den das Team schon nutzt, und ein PDF für den OEM.

## Typisches Setup

Der Prüfstand existiert schon: Steuergerät, Netzteil, Restbussimulation, ein CAN-Interface. Der Carbyne-Agent läuft auf dem Prüfstands-PC, unter Windows mit Vector-Hardware über die XL Driver Library oder unter Linux mit PEAK, Kvaser oder jedem anderen SocketCAN-Interface. Für Steuergeräte an Automotive Ethernet laufen DoIP und SOME/IP über den normalen Netzwerkport. Der Agent pollt das Backend über HTTPS.

Die meisten Tier-1 installieren AutoST auf eigenen Servern, weil Diagnosebeschreibungen des OEM und Firmware-Details vertraulich sind; kleinere Standorte nutzen die von Zyberum in der EU gehostete Instanz und behalten den Agenten lokal. Der Cybersecurity-Manager besitzt das Testprofil und die Risikogewichtung, der Testingenieur fährt die Scans am Ende jedes Integrationszyklus, und das Firmware-Team arbeitet den Fix Plan ab. Lizenziert wird pro getesteter Komponente, eine Steuergerätefamilie mit mehreren OEM-Varianten ist also ein Gespräch, nicht mehrere.

## Ein sinnvolles erstes Projekt

Mach den Pilot an einem Steuergerät in der B-Muster-Phase, für das es eine Cybersecurity-Anforderungsspezifikation gibt, gegen die du prüfen kannst.

1. **Woche 1: Umfang.** Steuergerät auswählen, ODX oder CDD anhängen, die SecurityAccess-Level auflisten und die Services, die nur in Extended oder Programming Session erreichbar sein dürfen. Den Agenten am vorhandenen Prüfstand installieren und koppeln.
2. **Woche 2: Baseline.** Enumeration über alle Sessions, DID- und Routinen-Scan, SecurityAccess-Prüfung. Die Findings mit dem Firmware-Lead durchgehen und festlegen, was ein Bug ist, was akzeptiert wird und was der OEM wissen muss.
3. **Wochen 3 und 4: Fuzzing.** Seeded UDS-Fuzzing auf den Services, die das Steuergerät anbietet, mit TesterPresent-Lebenszeichen und DTC-Überwachung. Jeden Crash einmal reproduzieren, bevor er in den Fix Plan geht.
4. **Wochen 5 und 6: Fix und Retest.** Die Entwickler arbeiten die priorisierten Aufgaben ab; dasselbe Profil läuft erneut. Akzeptierte Risiken und Kommentare bleiben erhalten, das zweite PDF zeigt genau, was geschlossen wurde.
5. **Übergabe.** Das PDF an den Verifikationsbericht für das C-Muster hängen und entscheiden, ob das Profil Teil jedes Releases wird.

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

ISO/SAE 21434:2021 Clause 10.4.2 fordert, dass die Implementierung gegen die Cybersecurity-Spezifikation verifiziert wird ([RQ-10-09]), und empfiehlt Komponententests mit Fuzz-Testing und Schwachstellen-Scans ([RC-10-12]). Das AutoST-PDF mit seiner datierten Scan-Historie ist der Nachweis auf Komponentenebene hinter diesem Verifikationsbericht, und die ALM/PLM-Referenz im Fix Plan verbindet jedes Finding mit der Anforderung oder dem Ticket, zu dem es gehört. Die Validierung nach Clause 11 ([RQ-11-01]) nennt Penetrationstests; AutoST ist die Baseline dafür, kein Ersatz. Clause 8.5 behandelt die Schwachstellenanalyse als fortlaufende Aktivität, und ein Profillauf vor jedem Release liefert genau das ohne zusätzlichen Prozess.

UN R155 richtet sich an den Fahrzeughersteller, aber Absatz 7.2.2.5 verlangt, dass der Hersteller zeigt, wie sein CSMS die Abhängigkeiten von Zulieferern steuert. Deshalb fragen OEMs nach Testnachweisen der Zulieferer gegen die Bedrohungen aus Anhang 5. UN R156 macht dasselbe für jedes Software-Update nach der Genehmigung. Bei der Unterstützung eines R155-Audits bei einem Tier-1 lag die Lücke nie im Testen selbst, sondern im Nachweis, welcher Test welche Anforderung abdeckt und wann er zuletzt lief. Eine Historie pro Komponente mit reproduzierbaren Läufen schließt diese Lücke. AutoST ist keine Zertifizierung und macht das Steuergerät nicht konform; es erzeugt die Nachweise, die das Agreement mit deinem OEM verlangt.

## FAQ

**Unser OEM verlangt einen Penetrationstest. Reicht AutoST?**

Nein, und das behauptet AutoST auch nicht. AutoST deckt den wiederholbaren Teil der Diagnose- und Bus-Angriffsfläche ab und erzeugt die Verifikationsnachweise dafür. Ein Penetrationstest geht weiter: Firmware, Secure Boot, Hardware-Schnittstellen, Angriffsketten. Wenn AutoST vorher läuft, verbringen die Pentester ihre ersten Tage nicht mit Findings, die du selbst hättest beheben können.

**Können wir mit unserer eigenen ODX- oder CDD-Datei testen?**

Ja. AutoST importiert ODX, ODX-D, PDX und Vector-CDD-Dateien pro Steuergerät. Gefundene DIDs tragen dann ihre echten Namen, Routinen werden genau so aufgerufen, wie sie definiert sind, statt per Brute Force, und die optionalen Schreibtests sind standardmäßig aus und werden vor dem Lauf bestätigt.

**Bekommt der OEM Zugriff auf unsere Instanz?**

Nur wenn du das willst. Auf deinen eigenen Servern verlassen die Daten nie dein Netz, und du übergibst PDF-Berichte. Mehrere OEMs betreiben eine eigene Instanz und lassen sich das Ergebnis des AutoST-Profils von den Zulieferern liefern; Gruppen und Rollen halten die Zulieferer dort getrennt.

## Sources

- [ISO/SAE 21434:2021 Road vehicles, Cybersecurity engineering, Clause 7, Clause 10.4.2 und Clause 11](https://www.iso.org/standard/70918.html)
- [UN-Regelung Nr. 155, Cybersecurity und Cybersecurity-Managementsystem, Absatz 7.2.2.5 und Anhang 5](https://unece.org/transport/documents/2021/03/standards/un-regulation-no-155-cyber-security-and-cyber-security)
- [UN-Regelung Nr. 156, Software-Update und Software-Update-Managementsystem](https://unece.org/transport/documents/2021/03/standards/un-regulation-no-156-software-update-and-software-update)
- [ISO 14229-1:2020 Unified diagnostic services (UDS), Teil 1: Application layer, Service 0x27](https://www.iso.org/standard/72439.html)

## Related

- [Hält dein Seed/Key wirklich?](https://auto-st.com/de/security-access-test)
- [Mach es am Prüfstand kaputt, nicht im Feld.](https://auto-st.com/de/ecu-fuzzing)
- [ISO/SAE 21434](https://auto-st.com/de/glossar/iso-sae-21434)
- [Automatisierter ECU-Security-Test vs. manueller Penetrationstest](https://auto-st.com/de/vergleich/automatisierter-ecu-test-vs-manueller-pentest)
- [Nachverfolgbarkeit im ISO 21434 Audit: Fuzzing zählbar machen](https://auto-st.com/de/insights/traceability-iso-21434-audit)
- [AutoST für OEM-Security-Teams: Zulieferer-Steuergeräte, Gateways, Fahrzeugnetz](https://auto-st.com/de/fuer/oem-security-teams)

---
AutoST by Zyberum. Canonical page: https://auto-st.com/de/fuer/tier-1-zulieferer