SARIF (Static Analysis Results Interchange Format)
SARIF ist der OASIS-JSON-Standard für den Austausch von Tool-Findings. Was eine SARIF-Datei enthält, warum sie auch für Steuergeräte-Tests passt und worauf du achtest.
Aktualisiert Diese Seite als Markdown
Kurz gesagt
SARIF (Static Analysis Results Interchange Format) ist ein OASIS-Standard, Version 2.1.0, für den Austausch der Ergebnisse von Analyse- und Testwerkzeugen als JSON. Ein SARIF-Log enthält einen oder mehrere Runs, jeweils mit dem erzeugenden Tool, den geprüften Regeln und den gefundenen Ergebnissen samt Level, Meldung und Ort. Code-Scanning-Dashboards, Issue-Tracker und CI-Pipelines lesen es, und damit ist es ein praktischer Weg, Security-Findings von Steuergeräten in die Werkzeuge der Entwickler zu bringen.
Was ist SARIF?
SARIF ist ein JSON-Format für die Ausgabe von Werkzeugen, die Probleme finden. Das Ziel: Jedes Tool schreibt Ergebnisse gleich, damit ein Viewer, ein Tracker oder eine Pipeline sie ohne eigenen Parser pro Tool lesen kann.
Der Aufbau ist einfach. Ein SARIF-Log hat eine version (2.1.0), ein $schema und ein Array von runs. Jeder Run nennt das tool (seinen driver mit Name, Version und rules) und listet results. Ein Ergebnis hat eine ruleId, ein level (error, warning, note oder none), eine message und locations. Optionale Felder ergänzen Fingerprints, um ein Finding über mehrere Runs zu verfolgen, Fixes, Code Flows und beliebige properties.
Wo ist es definiert?
SARIF 2.1.0 ist ein OASIS-Standard, 2020 veröffentlicht vom OASIS Static Analysis Results Interchange Format Technical Committee, mit zugehörigem JSON-Schema. Es ist keine Automotive-Norm. ISO/SAE 21434 schreibt kein Dateiformat für Findings vor; die Norm verlangt, dass Verifikationsergebnisse als Arbeitsprodukte dokumentiert werden, und SARIF ist ein Weg, sie in die Werkzeuge zu bringen, die die Behebung verfolgen.
Was es in der Praxis bedeutet
Die meisten Security-Teams haben schon einen Ort, an dem Findings aus statischer Analyse und Dependency-Scans landen. Bringst du die Steuergeräte-Findings an denselben Ort, vermeidest du eine zweite Liste, die niemand beachtet. SARIF schafft das, wenn der Export sorgfältig gemacht ist.
Drei Punkte entscheiden, ob es funktioniert. Stabile ruleIds und Fingerprints, damit ein Re-Test bestehende Findings aktualisiert, statt Duplikate zu erzeugen. Sinnvolle Levels, denn viele Dashboards filtern auf error. Und die Orte: Ein Steuergeräte-Finding hat keine Quelldatei, es braucht also logicalLocations (Steuergerät, Session, Service, DID), und das importierende Tool muss sie anzeigen. Ein Finding wie “beschreibbarer DID F18C in der Extended Session ohne SecurityAccess” liest sich gut als SARIF-Ergebnis, wenn der Regeltext Risiko und Abhilfe erklärt.
Wie AutoST es testet
AutoST testet SARIF nicht, es erzeugt es. Der Fix Plan, der die Findings aller Engines (UDS-Enumeration, SecurityAccess, DoIP, SOME/IP und Android-IVI) als priorisierte Aufgaben sammelt, exportiert nach SARIF 2.1.0, dazu CSV und JSON, und der Status eines Findings bleibt über Scans hinweg erhalten. In einen Tracker kommt die Datei über einen Import oder Upload, nicht über ein Hersteller-Plugin.
Häufige Missverständnisse
SARIF ist kein Bewertungsmodell. Das Feld level ist grob; Scores wie CVSS oder ein Risiko-Score gehören in properties oder in die Regel-Metadaten. Und SARIF macht Findings verschiedener Tools nicht von selbst vergleichbar: Zwei Tools können dieselbe Schwäche mit unterschiedlichen Regeln beschreiben.
FAQ
Häufig gestellte Fragen
Ist SARIF nur für statische Codeanalyse?
Nein. Der Name sagt statische Analyse, das Format beschreibt aber jedes Tool, das Regeln prüft und Ergebnisse meldet. Dynamische Testergebnisse wie Fuzzing-Abstürze oder Protokoll-Findings passen, solange jedes Ergebnis eine Regel, ein Level und eine Meldung hat.
Wie passen Steuergeräte-Findings zu SARIF-Locations?
SARIF erwartet für die meisten Ergebnisse eine Datei und eine Zeile. Steuergeräte-Findings haben keine Quelldatei, deshalb nutzen sie logische Orte, etwa Steuergerät, Session und Service oder DID. Manche Viewer zeigen solche Ergebnisse weniger detailliert an als Code-Findings.
Ersetzt ein SARIF-Export den Testbericht?
Nein. SARIF ist für Maschinen und Entwickler-Workflows. Ein Auditor oder eine Führungskraft braucht weiter einen lesbaren Bericht mit Umfang, Methode, Findings und Nachweisen, deshalb gehen PDF und SARIF meist zusammen.
Quellen
Passende Seiten
- PlattformEine Zahl, die du verteidigen kannst, Nachweise, die du ablegen kannst.AutoST bewertet das ECU-Risiko aus 26 gewichteten UDS-Services auf einer Skala von 0 bis 10 und erstellt PDF-Testnachweise, plus SARIF, CSV und JSON.
- PlattformFindings sind einfach. Beheben ist der Punkt.AutoST fasst jedes Finding aller Engines in einem nach Schweregrad priorisierten Fix Plan zusammen. Export nach CSV, SARIF 2.1.0 und JSON.
- PlattformSicherheitstests bei jedem Build, nicht einmal im Jahr.AutoST hat API-Tokens und ein CI-Plugin, das einen Scan auslöst, den Build bei Findings fehlschlagen lässt und JSON, JUnit XML und PDF ausgibt.
- Für dein TeamAutoST für CI/CD-Engineers: Steuergeräte-Security-Scans als Pipeline-GateWie CI/CD- und Testautomatisierungs-Engineers AutoST-Scans über die REST-API oder das Bamboo-Plugin aus der Pipeline starten, Builds gaten und Nachweise ablegen.
- VergleicheAutomatisierter ECU-Security-Test vs. manueller PenetrationstestAutomatisierte ECU-Tests fangen wiederholbare Schwächen bei jedem Build; ein manueller Pentest findet Logikfehler und Angriffsketten. Kosten und wann du was brauchst.
