# SARIF (Static Analysis Results Interchange Format)

> 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.

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.

Source: https://auto-st.com/glossary/sarif · Updated: 2026-10-07

## 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 `ruleId`s 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

**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

- [OASIS: Static Analysis Results Interchange Format (SARIF) Version 2.1.0](https://docs.oasis-open.org/sarif/sarif/v2.1.0/sarif-v2.1.0.html)
- [OASIS: SARIF Version 2.1.0, OASIS Standard (os)](https://docs.oasis-open.org/sarif/sarif/v2.1.0/os/sarif-v2.1.0-os.html)
- [ISO/SAE 21434:2021 Road vehicles, Cybersecurity engineering (work products and verification reports)](https://www.iso.org/standard/70918.html)

## Related

- [A number you can defend, evidence you can file.](https://auto-st.com/risk-scoring-reports)
- [Findings are easy. Fixing is the point.](https://auto-st.com/fix-plan)
- [Security tests on every build, not once a year.](https://auto-st.com/ci-cd-integration)
- [AutoST for CI/CD Engineers: ECU Security Scans as a Pipeline Gate](https://auto-st.com/for/ci-cd-engineers)
- [Automated ECU Security Testing vs Manual Penetration Test](https://auto-st.com/compare/automated-ecu-testing-vs-manual-pentest)

---
AutoST by Zyberum. Canonical page: https://auto-st.com/glossary/sarif