Wiki · Concept · Last reviewed June 25, 2026

Static Analysis Results Interchange Format

Static Analysis Results Interchange Format, or SARIF, is a standard JSON-based format for storing and exchanging static-analysis results across security tools, code hosts, and review workflows.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: SARIF, static analysis, code scanning, AI coding agents, security evidence

Definition

Static Analysis Results Interchange Format, abbreviated SARIF, is an OASIS Standard for the output of static-analysis tools. The approved SARIF Version 2.1.0 specification was published on March 27, 2020, and OASIS states that it defines a standard format for static-analysis results.

The purpose is interoperability. Static analyzers, linters, security scanners, compiler checks, and code-quality tools can emit findings in a shared structure rather than only in proprietary reports. A code host or review system can then display results from multiple tools with consistent fields for tool identity, rules, locations, messages, severity-like metadata, and result fingerprints.

How It Works

A SARIF file is a log. Its top-level structure includes one or more runs, and each run can describe the tool that produced the analysis, the artifacts examined, and the results found. A result can point to a location in source code, reference a rule, include a message, and carry other metadata needed to reproduce, suppress, triage, or compare findings.

The format does not require every consuming platform to support every field. GitHub documentation says code scanning supports a subset of the SARIF 2.1.0 JSON schema and that third-party tools should use that version. GitHub also documents upload paths through GitHub Actions, the code scanning API, or the CodeQL CLI, which makes SARIF a practical bridge between external scanners and repository alerts.

The important architectural choice is that SARIF separates scanner output from scanner ownership. A finding can travel as evidence even when the scanner, code host, reviewer, and remediation system are different systems.

Agent Context

AI coding agents make SARIF more important because they can generate patches faster than humans can review them. A scanner result in SARIF gives the agent and the human reviewer a shared object: which rule fired, where it fired, what message was attached, and whether the next patch changed the finding.

A good agent workflow should not ask a model to vaguely "fix security issues." It should pass structured findings, preserve the original SARIF file, record the agent run that attempted a repair, rerun analysis, and compare before-and-after results. SARIF is not a reasoning engine, but it gives the workflow a durable evidence layer that can be audited after the pull request is merged or rejected.

SARIF also helps avoid a common failure mode in AI repair loops: the agent optimizes for a textual instruction while losing the scanner's exact source location or rule identity. Keeping scanner findings structured makes it easier to distinguish fixed findings, moved findings, suppressed findings, and newly introduced findings.

Governance Use

A governance-grade SARIF workflow should preserve the SARIF file, scanner name and version, rule set, commit SHA, branch or pull request, analysis timestamp, upload path, review decision, suppression rationale, and repair evidence. For AI-assisted changes, it should also record the agent identity, model or tool configuration, prompt or task summary, generated patch, human approver, and rerun results.

SARIF belongs beside Common Weakness Enumeration, CVE, CVSS, OSV, and SBOM evidence. It is not itself a vulnerability taxonomy or severity framework. It is a container for analysis results that can reference those systems or feed decisions based on them.

Limits

SARIF does not prove that a finding is true. Static-analysis tools can produce false positives, miss reachable vulnerabilities, disagree about severity, or fail to model runtime context. A SARIF file can also be stale if the code changed after analysis, incomplete if the scanner was misconfigured, or misleading if an automated repair only suppresses the warning.

The format is also not a complete audit trail. It says what an analyzer reported, not why a human accepted risk, whether a generated patch was reviewed, or whether production exposure changed. Those decisions need issue tracking, deployment records, policy checks, and incident-response context.

Source Discipline

Claims about SARIF should cite the OASIS specification or OASIS SARIF Technical Committee. Claims about GitHub ingestion should cite GitHub Docs because hosting platforms may support only selected portions of the schema and may impose upload limits or other validation rules. A real audit note should include the SARIF version, scanner version, commit, upload destination, and date checked.

Spiralist Reading

Spiralism reads SARIF as a discipline of legible warning. Code-scanning tools do not speak in certainty; they emit structured concern. The useful question is not whether the machine has found sin in the code. It is whether the institution can preserve the warning, test it, argue with it, and remember what happened next.

For agentic coding, this matters because speed can erase accountability. SARIF slows the loop just enough to keep a record: the rule, the file, the line, the attempted repair, the rerun, and the human decision.

Sources

Return to Wiki