SARIF in einem Absatz
SARIF (Static Analysis Results Interchange Format) ist ein OASIS-Standard — aktuell Version 2.1.0 — zur Darstellung der Ausgabe statischer Analysetools in einem einzigen JSON-Schema. Statt dass jeder Scanner sein eigenes Berichtsformat erfindet, docken SARIF-sprechende Tools direkt an GitHub Code Scanning, GitLab SAST, Azure DevOps und die meisten Sicherheits-Dashboards an — ohne eigenen Parser. Es gruppiert Findings unter einem tool.driver.rules-Array (Regel-Metadaten) und einem results-Array (jedes Finding: Regel-ID, Schweregrad, Datei, Zeile, Meldung).
Den Bericht erzeugen
Ein einziges Flag, ausführbar von jedem CI-Runner oder der eigenen Maschine:
./staticcodeaudit-linux-x86_64 /path/to/project --sarif --fail-on-highDies schreibt zwei Dateien neben den gewohnten HTML-Bericht: eine SCA-SARIF-<timestamp>.sarif-Datei und den üblichen SCA-REPORT-<timestamp>.html — der SARIF-Export kommt zusätzlich hinzu, der lesbare Bericht bleibt erhalten. --fail-on-high ist optional, sorgt aber dafür, dass der Schritt eine Pipeline tatsächlich blockiert: Der Prozess beendet sich mit Code 1, sobald ein Finding mit Schweregrad HIGH vorliegt, sonst mit 0.
Was die Datei tatsächlich enthält
Ein gekürztes reales Beispiel — ein Finding, erzeugt beim Scannen eines zweizeiligen verwundbaren Snippets:
{
"$schema": "https://raw.githubusercontent.com/oasis-tcs/sarif-spec/main/sarif-2.1/schema/sarif-schema-2.1.0.json",
"version": "2.1.0",
"runs": [{
"tool": {
"driver": {
"name": "StaticCodeAudit",
"version": "1.0.0",
"informationUri": "https://codefixture.com",
"rules": [{
"id": "hardcoded_secret",
"name": "Hardcoded secret",
"fullDescription": { "text": "Plain text secrets in code can be exposed via Git repository." },
"defaultConfiguration": { "level": "error" }
}]
}
},
"results": [{
"ruleId": "hardcoded_secret",
"level": "error",
"message": { "text": "Plain text secrets in code can be exposed via Git repository." },
"locations": [{
"physicalLocation": {
"artifactLocation": { "uri": "app.py" },
"region": { "startLine": 6 }
}
}],
"fixes": [{ "description": { "text": "Use environment variables or system_configs in database." } }]
}]
}]
}Jedes result trägt einen Dateipfad, eine Zeilennummer und — sofern eine Behebung bekannt ist — einen fixes-Eintrag mit einem Vorschlag in Klartext. GitHub Code Scanning stellt all das direkt im Security-Tab dar, an der exakten Zeile in der Diff-Ansicht annotiert.
SARIF oder SBOM — nie beides im selben Lauf
StaticCodeAudit exportiert außerdem ein Abhängigkeitsinventar als CycloneDX-1.5-SBOM (--sbom), aber beide Exporte schließen sich pro Lauf gegenseitig aus — sie beantworten unterschiedliche Fragen (gefundene Schwachstellen vs. vorhandene Abhängigkeiten), und sie in einer Datei zu vermischen würde beides schwerer konsumierbar machen. Beides gleichzeitig anzufordern schlägt sofort fehl:
$ ./staticcodeaudit-linux-x86_64 /path/to/project --sarif --sbom
❌ --sarif and --sbom are mutually exclusive. Use one or the other.Führen Sie den Scan in der CI zweimal aus, wenn Sie beide Artefakte benötigen — jeder Lauf dauert bei einer kleinen bis mittleren Codebasis deutlich unter einer Sekunde. Siehe den SBOM-Export-Leitfaden für die Abhängigkeitsinventar-Seite.
Anbindung an GitHub Code Scanning
GitHubs eigene upload-sarif-Action liest jede SARIF-2.1.0-Datei, unabhängig davon, welches Tool sie erzeugt hat. Ein minimaler Workflow-Schritt:
- name: Run StaticCodeAudit
run: ./staticcodeaudit-linux-x86_64 /path/to/project --sarif --fail-on-high
- name: Upload SARIF to GitHub Code Scanning
if: always()
uses: github/codeql-action/upload-sarif@v3
with:
sarif_file: docs/audit-reports/*.sarifif: always() ist hier entscheidend: Ohne es würde ein HIGH-Finding (das den vorherigen Schritt mit Code 1 beenden lässt) den Upload-Schritt überspringen, und Sie würden die Ergebnisse nie im Security-Tab sehen — Sie wüssten nur, dass die Pipeline fehlgeschlagen ist, nicht warum.
Verfügbarkeit
Der SARIF-Export ist ab der Stufe Team enthalten (Team, Team Plus, Enterprise); die Stufe Solo exportiert nur HTML. Vollständige Übersicht auf der Preisseite.
Häufig gestellte Fragen
Sendet die Erzeugung eines SARIF-Berichts etwas über das Netzwerk?
Nein. Die SARIF-Datei wird lokal auf die Festplatte geschrieben, neben den HTML-Bericht, aus Daten, die bereits während des lokalen Scans berechnet wurden. StaticCodeAudit macht während eines Scans keine ausgehenden Netzwerkaufrufe, überprüfbar mit einem Netzwerk-Monitor (tcpdump -i any -n) — ein zusätzliches Exportformat ändert daran nichts.
Kann ich die SARIF-Datei mit GitLab oder einer anderen Plattform statt GitHub verwenden?
Ja — SARIF 2.1.0 ist ein generischer OASIS-Standard, nicht GitHub-spezifisch. GitLab, Azure DevOps und die meisten Sicherheits-Dashboards, die „SARIF importieren" unterstützen, akzeptieren dieselbe Datei unverändert. Das obige Beispiel nutzt GitHubs upload-sarif-Action, weil sie das gängigste Ziel ist, nicht weil das Dateiformat daran gebunden ist.
Warum schlägt --sarif --sbom fehl, statt beide Dateien zu erzeugen?
Das ist eine bewusste Design-Entscheidung, kein fehlendes Feature: Eine SARIF-Datei beschreibt Findings, ein CycloneDX-SBOM beschreibt ein Abhängigkeitsinventar — sie in einem einzigen Export zu vermischen würde beides nachgelagert schwerer korrekt konsumierbar machen. Führen Sie den Scan zweimal aus (oder in zwei parallelen CI-Jobs), wenn Ihre Pipeline beide Artefakte vom selben Commit benötigt.
Enthält jedes Finding einen fixes-Vorschlag?
Nur dort, wo StaticCodeAudit ein bekanntes Behebungsmuster für diese Regel kennt — das obige Beispiel (hardcoded_secret) hat eines, aber noch nicht jede Regel liefert eines mit. Fehlt es, trägt der results-Eintrag trotzdem den vollständigen Ort und die Meldung, nur ohne das fixes-Feld.
An Ihrem eigenen Code testen
Öffnen Sie den Live-Demo-Bericht — keine Installation, keine Anmeldung — oder führen Sie die Binary gegen ein kleines Projekt aus und prüfen Sie die SARIF-Datei selbst.
Live-Bericht öffnen Demo-Binary herunterladen