SARIF (Static Analysis Results Interchange Format)
SARIF is the OASIS JSON standard for exchanging tool findings. What a SARIF file contains, why it fits ECU test results too, and what to watch for when you import one.
Updated This page as Markdown
In short
SARIF (Static Analysis Results Interchange Format) is an OASIS standard, version 2.1.0, for exchanging the results of analysis and testing tools as JSON. A SARIF log holds one or more runs, each with the tool that produced it, the rules it checked and the results it found, with severity level, message and location. Code-scanning dashboards, issue trackers and CI pipelines read it, which makes it a practical way to move ECU security findings into the tools developers already use.
What is SARIF?
SARIF is a JSON format for the output of tools that find problems. Its goal is that every tool writes results the same way, so that a viewer, a tracker or a pipeline can read them without a parser per tool.
The structure is simple. A SARIF log has a version (2.1.0), a $schema and an array of runs. Each run names the tool (its driver with name, version and rules) and lists results. A result has a ruleId, a level (error, warning, note or none), a message and locations. Optional fields add fingerprints for tracking a finding across runs, fixes, code flows and arbitrary properties.
Where is it defined?
SARIF 2.1.0 is an OASIS standard published in 2020 by the OASIS Static Analysis Results Interchange Format Technical Committee, with an accompanying JSON schema. It is not an automotive standard. ISO/SAE 21434 does not prescribe a file format for findings; it requires that verification results are documented as work products, and SARIF is one way to carry them into the tools that track remediation.
What it means in practice
Most security teams already have a place where findings from static analysis and dependency scans end up. Bringing ECU test findings into the same place avoids a second list that nobody watches. SARIF does that if the export is done carefully.
Three points decide whether it works. Stable ruleIds and fingerprints, so that a re-test updates existing findings instead of creating duplicates. Meaningful levels, because many dashboards filter on error. And locations: an ECU finding has no source file, so it needs logicalLocations (ECU, session, service, DID), and the importing tool has to display them. A finding such as “writable DID F18C in extended session without SecurityAccess” reads well as a SARIF result if the rule text explains the risk and the fix.
How AutoST tests it
AutoST does not test SARIF; it produces it. The Fix Plan, which collects the findings of all engines (UDS enumeration, SecurityAccess, DoIP, SOME/IP and Android IVI) as ranked tasks, exports to SARIF 2.1.0 next to CSV and JSON, and finding status carries over between scans. Getting the file into a tracker is an import or an upload step, not a vendor plugin.
Common misunderstandings
SARIF is not a severity model. The level field is coarse; scores such as CVSS or a risk score belong in properties or in the rule metadata. And SARIF does not make findings comparable across tools by itself: two tools can describe the same weakness with different rules.
FAQ
Frequently asked questions
Is SARIF only for static code analysis?
No. The name says static analysis, but the format describes any tool that checks rules and reports results. Dynamic test results such as fuzzing crashes or protocol findings fit as long as each result has a rule, a level and a message.
How do ECU findings fit SARIF locations?
SARIF expects a file and line for most results. ECU findings have no source file, so they use logical locations instead, for example the ECU, the session and the service or DID. Some viewers display such results with less detail than code findings.
Does a SARIF export replace a test report?
No. SARIF is for machines and developer workflows. An auditor or a manager still needs a readable report with scope, method, findings and evidence, which is why PDF and SARIF usually go together.
Sources
Related pages
- PlatformA number you can defend, evidence you can file.AutoST scores ECU risk from 26 weighted UDS services on a 0-10 scale and produces PDF test evidence with a non-repudiation footer, plus SARIF, CSV and JSON export.
- PlatformFindings are easy. Fixing is the point.AutoST turns every finding across all engines into one severity-ranked fix plan, with what, risk and fix per task and export to CSV, SARIF 2.1.0 and JSON.
- PlatformSecurity tests on every build, not once a year.AutoST has API tokens and a CI plugin that triggers a scan, fails the build on findings and emits JSON, JUnit XML and PDF. Any CI system can drive it via the REST API.
- For your teamAutoST for CI/CD Engineers: ECU Security Scans as a Pipeline GateHow CI/CD and test automation engineers trigger AutoST ECU scans from a pipeline through the REST API or the Bamboo plugin, gate builds on risk and archive evidence.
- ComparisonsAutomated ECU Security Testing vs Manual Penetration TestAutomated ECU testing catches repeatable weaknesses on every build; a manual pentest finds logic flaws and chained attacks. What each finds, costs and when to use which.
