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, it has an actual specification and a published JSON schema, so consumers agree on what a file means.

What is in a file

{
  "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).

Security reports belong on a restricted access setting, not a public link — see share a security scan report.

Try it

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

Publish a scan report →

Related