AutoST für CI/CD-Engineers: Steuergeräte-Security-Scans als Pipeline-Gate

Die Aufgabe

Ein CI/CD- oder Testautomatisierungs-Engineer in einem Steuergeräteprojekt baut und pflegt die Pipeline, die einen Commit bis zum geflashten Steuergerät am Prüfstand und zu einem grünen oder roten Build bringt. Unit-Tests, statische Analyse und Hardware-in-the-Loop-Tests sind meist schon da. Security-Tests nicht: Die passieren einmal pro Musterphase, von Hand, und das Ergebnis kommt Wochen nach der Änderung, die es verursacht hat.

Wir sehen regelmäßig Regressionen, die eine Pipeline am Tag ihrer Entstehung gefunden hätte. Ein Debug-Service, der für einen Test-Build aktiviert wurde, bleibt im Release in der Default Session erreichbar. Ein Refactoring des Diagnose-Stacks verliert den Fehlversuchszähler bei SecurityAccess. Eine neue DID für die Bandende-Programmierung ist ohne Authentifizierung beschreibbar. Jedes davon ist ein einzeiliger Diff, und jedes zeigt der nächste Enumerations-Scan.

Was die Rolle aus einem Testlauf braucht

Der Engineer braucht einen Security-Scan, der sich wie jede andere Stufe verhält: skriptbar, zeitlich begrenzt und eindeutig.

• Einen Auslöser ohne Mensch. Langlebige API-Tokens (JWTs), im Dashboard eingeschränkt und widerrufbar, authentifizieren die Pipeline gegen die REST-API. Dieselbe API startet jeden Scan, den auch das Dashboard starten kann.
• Ein klares Urteil. Das Bamboo-Plugin lässt den Build scheitern, wenn die Findings deinen Schwellwert überschreiten. In anderen CI-Systemen liest dein Skript das Scan-Ergebnis aus der API und setzt den Exit-Code.
• Ausgaben, die der Build-Server versteht. JUnit XML zeigt den Scan in den Build-Ergebnissen wie jede Testsuite, JSON speist eigene Werkzeuge, und ein PDF pro Lauf wird als Nachweis archiviert. Der Fix Plan exportiert SARIF 2.1.0 für Code-Scanning-Dashboards.
• Stabile Ergebnisse. Akzeptierte Risiken und Kommentare bleiben über Re-Scans erhalten, das Gate reagiert also nur auf neue Findings. Fuzzing nutzt einen gespeicherten Seed, ein nächtlicher Crash lässt sich exakt nachspielen.
• Keine eingehenden Ports am Prüfstand. Der Carbyne-Agent pollt das Backend über HTTPS, das Prüfstandsnetz muss vom Build-Server aus nicht erreichbar sein.

Typisches Setup

Die Pipeline baut die Firmware, flasht sie mit deinem vorhandenen Flash-Werkzeug auf das Steuergerät am Prüfstand und ruft dann AutoST auf. 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, dazu Ethernet für DoIP und SOME/IP. Er holt den Job ab, fährt den Scan und streamt die Ergebnisse ans Backend; mehrere Prüfstände laufen parallel.

In Atlassian Bamboo ist das Plugin ein Task im Build-Plan: Es startet den Scan, wartet auf das Ende, wendet den Schwellwert an und hängt JSON, JUnit XML und das PDF an. In Jenkins, GitLab CI oder GitHub Actions gibt es kein Plugin; ein Skript-Schritt ruft die REST-API mit dem Token aus deinem Secret Store auf und macht dasselbe. Eine übliche Aufteilung ist ein kurzes deterministisches Profil pro Build, Enumeration und SecurityAccess-Prüfung, und ein längeres Fuzzing-Profil nachts oder vor einem Release.

Ein sinnvolles erstes Projekt

Fang mit einem Steuergerät an einem Prüfstand an, den die Pipeline schon flasht.

1. Woche 1: Anbindung. Agent am Prüfstand installieren und koppeln, ein API-Token für die Pipeline anlegen und den Bamboo-Task oder einen Skript-Schritt ergänzen, der nach dem Flashen einen Enumerations-Scan startet.
2. Woche 2: Baseline und Schwellwert. Den Scan auf dem aktuellen Release fahren, die Findings mit dem Security-Team durchgehen, Gewolltes akzeptieren und den Schwellwert so setzen, dass der heutige Build besteht.
3. Woche 3: Gate. Den Schwellwert scharf schalten. Ab jetzt lässt ein neu erreichbarer Service, ein verlorener Fehlversuchszähler oder eine neu beschreibbare DID den Build scheitern, mit dem Request im Bericht.
4. Woche 4: Nächtliches Fuzzing. Einen geplanten Job mit Seeded UDS-Fuzzing ergänzen, mit TesterPresent-Lebenszeichen und DTC-Überwachung, und Crashes in den Fix Plan leiten.
5. Review. Die gefundenen Regressionen zählen und entscheiden, welche weiteren Steuergeräte und Prüfstände in die Pipeline kommen.

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

Jeder Pipeline-Lauf hinterlässt ein datiertes PDF, damit wird Security-Verifikation vom Projektmeilenstein zur Aufzeichnung pro Build. ISO/SAE 21434:2021 Clause 10.4.2 fordert die Verifikation gegen die Cybersecurity-Spezifikation ([RQ-10-09]) und empfiehlt Komponententests mit Fuzz-Testing und Schwachstellen-Scans ([RC-10-12]); Clause 8.5 behandelt die Schwachstellenanalyse als fortlaufende Aktivität. Ein Gate in der Pipeline ist der direkteste Weg, beides bei jedem Release umzusetzen.

UN R156 verlangt, dass ein Software-Update die Sicherheit des Fahrzeugs nicht untergräbt, in der Praxis also Retest nach jedem Update; eine Pipeline macht das automatisch. Für die Bedrohungen rund um den Diagnosezugriff aus UN R155 Anhang 5 zeigt die Historie pro Build, dass die Maßnahme noch wirkte, als die Software ausgeliefert wurde. AutoST ersetzt keinen Penetrationstest und zertifiziert nichts; es sorgt dafür, dass die bekannten Prüfungen nie übersprungen werden.