# ISO/SAE 21434 Verifikationsnachweise aus Security-Tests

Was unter ISO/SAE 21434 als Verifikationsnachweis zählt, welche Clauses ihn fordern und wie ein Security-Testlauf zum Artefakt wird, das ein Assessor akzeptiert.

Source: https://auto-st.com/de/insights/iso-21434-verifikationsnachweise · Updated: 2026-10-07

ISO/SAE 21434 verlangt, dass du verifizierst, dass deine Cybersecurity-Kontrollen funktionieren, und den Nachweis dafür aufbewahrst. Ein Security-Test wird erst zum Nachweis, wenn ein Assessor ihn zu einer Anforderung zurückverfolgen, sehen kann, wann er lief, seine Funde reproduzieren und lesen kann, was mit jedem geschah. Dies ist ein Leitfaden, was die Norm fordert und wie du Artefakte erzeugst, die ein Assessment überstehen. Es ist praktische Orientierung, keine Zertifizierung, und kein Tool macht dich allein konform.

## Wo die Norm Tests fordert

Drei Clauses der ISO/SAE 21434:2021 sind der Ort, an dem Security-Tests leben:

| Clause | Aktivität | Was sie fordert |
| --- | --- | --- |
| 10.4.2 | Integration und Verifikation | [RQ-10-09] verifizieren, dass die Implementierung die Cybersecurity-Spezifikation erfüllt; [RC-10-12] empfiehlt Komponententests mit Fuzz-Testing und Schwachstellen-Scans, um unentdeckte Schwächen zu minimieren |
| 11 | Cybersecurity-Validierung | [RQ-11-01] nennt Penetrationstests, um die Cybersecurity-Ziele zu bestätigen |
| 8.5 | Schwachstellenanalyse | Schwächen finden und analysieren als fortlaufende Aktivität über den Lebenszyklus |

Ab CAL 2 wird Fuzz-Testing der Kommunikationsschnittstellen faktisch erwartet. Die Testtiefe skaliert mit dem Cybersecurity Assurance Level (CAL) des Items.

## Der Unterschied zwischen Testergebnis und Nachweis

Ein Assessment wird nicht danach bewertet, ob du einen Fuzzer laufen ließt. Es wird nach deinen Work Products bewertet: dem Verifikationsbericht, dem Validierungsbericht und dem Cybersecurity-Case, der argumentiert, dass das Item angemessen sicher ist, beurteilt im Cybersecurity-Assessment (Clause 6.4.9). Ein Testergebnis wird zum Nachweis, wenn es vier Dinge trägt:

1. **Nachverfolgbarkeit.** Eine Verbindung von der Cybersecurity-Anforderung zum Test, der sie verifiziert, und zurück. Ein Assessor muss bei einem Ziel starten können ("das ECU darf ohne Authentifizierung keine Diagnoseschreibungen akzeptieren") und den Test erreichen, der es prüft.
2. **Ein Datum und ein Scope.** Was getestet wurde, auf welchem ECU und welcher Softwareversion, und wann. Ein Ergebnis ohne Datum lässt sich nicht im Lebenszyklus einordnen.
3. **Reproduzierbarkeit.** Beim Fuzzing ein gespeicherter Seed, damit sich ein Crash erneut abspielen lässt. Ein Fund, den niemand reproduzieren kann, ist schwacher Nachweis.
4. **Eine Disposition.** Was mit jedem Fund geschah: behoben, gemindert oder als Restrisiko mit dokumentierter Begründung akzeptiert.

## Testarten den Clauses zuordnen

Verschiedene Security-Tests erzeugen Nachweise für verschiedene Clauses:

- **UDS-Enumeration** bildet die Diagnose-Angriffsfläche ab. Das ist Nachweis, dass erreichbare Services und DIDs gegen die Spezifikation geprüft wurden (10.4.2).
- **SecurityAccess-Prüfungen (0x27)** verifizieren, dass eine Authentifizierungskontrolle wirklich hält, oft eine direkte Cybersecurity-Anforderung (10.4.2).
- **Fuzzing** von UDS- und CAN-Schnittstellen ist das Komponententesten, das [RC-10-12] empfiehlt, und der Nachweis ist der geseedete Lauf samt seinen Funden.
- **DoIP-, SOME/IP- und IVI-Prüfungen** erweitern diese Abdeckung auf Ethernet- und Infotainment-Flächen.
- **Der ganze Satz, bei jedem Build erneut gefahren,** macht aus Clause 8.5 Schwachstellenanalyse eine stehende Aktivität statt einer Einmal-Prüfung.

## Was ein Assessor tatsächlich öffnet

Ein Assessor führt deine Tools nicht aus. Er liest Artefakte. Die funktionierenden sind:

- Ein **Bericht** je ECU mit den Funden, jeder mit Schweregrad, dem betroffenen Service oder der Schnittstelle und einer konkreten Behebung.
- Eine **datierte Historie**, die dasselbe ECU über Versionen getestet zeigt, sodass ein behobener Fund als erledigt und ein akzeptierter dokumentiert bleibt.
- Ein **maschinenlesbarer Export** wie SARIF 2.1.0, damit die Funde ins eigene Tooling und Issue-Tracking fließen, statt nur in einem PDF zu leben.
- Ein **Referenzfeld** an jedem Fund, das ihn mit der Anforderung oder dem Ticket verbindet, auf die er sich bezieht, die Nachverfolgbarkeit, die der Assessor sucht.

Bei einer ISO/SAE-21434-Audit-Unterstützung bei einem Tier-1 war die Lücke nie das Testen selbst. Es war, dass sich die Tests nicht auf Anforderungen zurückführen ließen, sodass gute Arbeit wie eine Anekdote wirkte. Die Nachverfolgbarkeit zu reparieren, nicht die Tests, bestand das Assessment.

## Wo Tests enden und Prozess beginnt

Security-Tests erzeugen Verifikations- und Validierungsnachweise. Tests schreiben nicht deine TARA, betreiben nicht dein Cybersecurity-Management-System (CSMS) und bauen nicht deinen Cybersecurity-Case. Das sind Prozess-Work-Products rund um die Tests. Zu übertreiben, was ein Test-Tool leistet, hilft keinem Audit, denn ein Assessor liest die ganze Argumentation, nicht nur das Testlog.

AutoST erzeugt die Test-Seite davon direkt: Enumeration, SecurityAccess-Prüfungen, geseedetes Fuzzing, DoIP/SOME/IP- und IVI-Tests, jeder Fund bewertet und mit einer Behebung versehen, eine datierte Scan-Historie, über Re-Tests getragene Risikoakzeptanz und PDF- plus SARIF-Export mit einem Referenzfeld je Fund. Es betreibt nicht dein CSMS und schreibt nicht deine TARA; dafür bietet Zyberum ISO/SAE-21434-Beratung aus demselben Team, das die SAE- und TÜV-SÜD-Automotive-Cybersecurity-Qualifikation hält.

## FAQ

**Welche ISO/SAE-21434-Clauses fordern Security-Tests?**

Clause 10.4.2 (Integration und Verifikation) fordert, die Implementierung gegen die Cybersecurity-Spezifikation zu verifizieren, wobei [RC-10-12] Komponententests inklusive Fuzzing und Schwachstellen-Scans empfiehlt. Clause 11 (Validierung) nennt Penetrationstests in [RQ-11-01]. Clause 8.5 behandelt Schwachstellenanalyse als fortlaufend.

**Was macht aus einem Testergebnis einen Verifikationsnachweis?**

Ein Test ist Nachweis, wenn ein Assessor ihn zu der Cybersecurity-Anforderung zurückverfolgen kann, die er verifiziert, sieht, wann er lief, den Fund reproduzieren kann und ein Ergebnis liest, das festhält, was getestet und was mit jedem Fund getan wurde. Ein rohes Log ist kein Nachweis, bis es diesen Kontext trägt.

**Macht das Ausführen von AutoST ein ECU ISO/SAE-21434-konform?**

Kein Tool tut das. AutoST erzeugt die Tests und die Nachweise für die Verifikations- und Validierungs-Clauses. Die TARA, der Cybersecurity-Case und das Assessment sind Prozessarbeit rund um die Tests, die Zyberum separat unterstützen kann.

## Sources

- [ISO/SAE 21434:2021 Straßenfahrzeuge, Cybersecurity-Engineering](https://www.iso.org/standard/70918.html)
- [SARIF 2.1.0, OASIS-Standard](https://docs.oasis-open.org/sarif/sarif/v2.1.0/sarif-v2.1.0.html)

## Related

- [ISO/SAE 21434](https://auto-st.com/de/glossar/iso-sae-21434)
- [CAL (Cybersecurity Assurance Level)](https://auto-st.com/de/glossar/cal)
- [UN R155 (UN-Regelung Nr. 155, Cyber Security)](https://auto-st.com/de/glossar/un-r155)
- [Nachweise für deine 21434-Arbeit, auf Abruf.](https://auto-st.com/de/iso-21434-tests)
- [Eine Zahl, die du verteidigen kannst, Nachweise, die du ablegen kannst.](https://auto-st.com/de/risikobewertung-reports)
- [Nachverfolgbarkeit im ISO 21434 Audit: Fuzzing zählbar machen](https://auto-st.com/de/insights/traceability-iso-21434-audit)

---
AutoST by Zyberum. Canonical page: https://auto-st.com/de/insights/iso-21434-verifikationsnachweise