# What Is SARIF? — The Standard Format for Static Analysis Results

Canonical: https://commareports.com/glossary/sarif
Published: 2026-09-11

> SARIF is the OASIS-standard JSON format for static analysis and security findings. What is in a SARIF file, which tools emit it, and why the HTML view still matters.

# SARIF

**SARIF — Static Analysis Results Interchange Format — is the
OASIS-standard JSON format for reporting static analysis and security
findings.** Version 2.1.0 is the one everything implements. Unlike
[JUnit XML](/glossary/junit-xml), it has an actual specification and a
published JSON schema, so consumers agree on what a file means.

## What is in a file

```json
{
  "version": "2.1.0",
  "runs": [
    {
      "tool": {
        "driver": {
          "name": "semgrep",
          "rules": [
            {
              "id": "python.lang.security.audit.eval-detected",
              "shortDescription": { "text": "eval() on user input" },
              "defaultConfiguration": { "level": "error" }
            }
          ]
        }
      },
      "results": [
        {
          "ruleId": "python.lang.security.audit.eval-detected",
          "level": "error",
          "message": { "text": "Detected eval() on user-controlled data" },
          "locations": [
            {
              "physicalLocation": {
                "artifactLocation": { "uri": "src/handlers/import.py" },
                "region": { "startLine": 88, "startColumn": 12 }
              }
            }
          ]
        }
      ]
    }
  ]
}
```

The three load-bearing parts:

- **`tool.driver.rules`** — the catalogue of every check the tool can
  report, with descriptions and default severity. This is what lets a
  consumer render a finding it has never seen before.
- **`results`** — the findings, each pointing at a rule id.
- **`locations`** — file, line and column, which is what turns a finding
  into an inline pull-request annotation.

Optional but valuable: `codeFlows` (the taint path from source to sink),
`fixes` (suggested patches), `partialFingerprints` (stable identity
across runs, so a finding can be tracked or suppressed).

## Who emits it

CodeQL, Semgrep, Trivy, Grype, Bandit, Brakeman, ESLint, Checkov, KICS,
tfsec, Snyk, Gitleaks, Prowler and ScoutSuite, among many others —
usually behind `--format sarif`. GitHub code scanning, GitLab and Azure
DevOps all ingest it.

## Why the HTML report still exists

SARIF is an interchange format. It is not something a person reads.

Code scanning UIs surface it one finding at a time, inside the
repository, behind repository permissions. That is the wrong shape for
three common jobs:

- **An audit.** The reviewer needs one document, dated, showing the full
  finding set — not a filtered queue in a tool they cannot log into.
- **A client or contractor handoff.** They have no repo access at all.
- **A decision.** "We accept this finding because…" belongs next to the
  finding, and needs to still be readable a year later.

The scanner's HTML output is that document. Publishing it to a stable URL
gives auditors, clients and non-engineers a readable artifact, and lets
reviewers select an individual finding and comment on it — so the triage
decision is attached to the evidence rather than lost in a chat thread
([comment on HTML](/comment-on-html)).

Security reports belong on a restricted access setting, not a public
link — see [share a security scan report](/share-security-scan-report).

## Try it

Comma is free — unlimited reports, unlimited commenters, unlimited
revision history.

**[Publish a scan report →](https://commareports.com/)**

### Related

- [Share a SARIF report](/share-sarif-report) · [Semgrep](/share-semgrep-report) · [Trivy](/share-trivy-report)
- [SBOM](/glossary/sbom) · [JUnit XML](/glossary/junit-xml)
- [Security teams](/for/security-teams) · [Glossary](/glossary)