What is SARIF? The standard format for security findings

SARIF, the Static Analysis Results Interchange Format, is the standard way security tools report findings. It is a JSON format standardized at OASIS: a scanner writes a SARIF file describing what it found and where, and any SARIF-aware consumer - a dashboard, an IDE, a code-review integration - can read it without knowing anything else about the tool that produced it.

The problem it solves

Every scanner needs to answer the same questions about each finding: which rule fired, where, how severe, and why. Before standardization, each tool answered in its own format, and every platform that wanted to display findings maintained a parser per tool. The result was integration friction that quietly locked teams into whatever tooling they had already wired up.

SARIF fixes the interface. The scanner’s job ends at “emit valid SARIF”; the consumer’s job starts at “read valid SARIF”; neither needs to know the other. For a platform built on the principle that engines detect and the dashboard governs, a standard interchange format is not a convenience - it is what makes the separation work.

What a finding contains

A SARIF file describes one or more runs, each declaring the tool and its rules, followed by results. A well-formed result carries:

• Rule identity - which check fired, with links back to the rule’s metadata.
• Location - file, line, column, and a snippet of the affected code.
• Severity and ranking - the level, plus numeric properties consumers use for ordering.
• Message - the human-readable explanation.
• Code flows - for data-flow findings, the step-by-step path from source to sink, which is how taint analysis evidence travels inside the file.
• Fingerprints - identifiers designed to keep a finding’s identity stable across scans, the property that lets triage decisions persist instead of resetting.

The format also has an extension point - property bags - where tools attach structured data beyond the core schema, such as CWE numbers, confidence levels, or engine-specific context.

What to expect from a serious emitter

Emitting minimally valid SARIF is easy; emitting useful SARIF is a commitment. The differences that matter downstream: schema-valid output (consumers reject or mangle invalid files), populated code flows so evidence survives the export, stable content-based fingerprints rather than line-number identities, and severity properties that reflect real prioritization signals rather than a single flat level.

The SecuNexa engines emit SARIF 2.1.0 with all of the above - full traces, CWE mapping, confidence, and stable fingerprints - which is exactly what the dashboard consumes to correlate findings across engines. The practical benefit runs in both directions: SecuNexa results plug into anything SARIF-aware you already run, and the dashboard’s contract with its own engines is the same public standard everyone else can meet.