SARIF

Software today is checked not only by humans but also by analysis programs. These programs read the written program text and report suspicious spots, such as a security vulnerability or a careless typo. In the past, every such analysis tool stored its messages in its own, self-invented file structure. Anyone wanting to display the results of five tools together had to build five translators. SARIF is the answer to this: a fixed, uniform structure for such result files. The name stands for “Static Analysis Results Interchange Format,” that is, roughly, “exchange format for results of program text checking.”

A shared reporting form for analysis tools

The benefit of SARIF lies in the savings on intermediate work. A large software project often runs a dozen analysis tools simultaneously. Without a shared format, every tool needs its own connection to the display interface. With SARIF there is only one connection, and new tools can be added with almost no effort.

A comparison makes this tangible. Imagine medical reports where every practice uses its own form. A hospital would have to learn to understand each form individually. With a uniform report, the admissions desk reads everything the same way. SARIF is this uniform form for code checks.

Also important: SARIF itself checks nothing. It finds no errors and assesses no risks. It is purely a means of transport for results, much like an envelope says nothing about its contents. Beginners frequently confuse this distinction.

What is in a SARIF file

A SARIF file is text in JSON structure. JSON is a widespread notation for structured data, in which values are given names within curly braces. Humans can read such files, but they are primarily intended for programs. SARIF has been an official standard of the organization OASIS since 2019, currently in version 2.1.0.

The content is organized into a few fixed parts. First comes which tool ran in which version. Then follows a list of rules, that is, the checks the tool knows about. After that come the actual findings, called “results” in SARIF.

Every finding always contains the same information: file, line, and column of the suspicious spot, a short description, a reference to the associated rule, and a severity rating. Some tools additionally attach a suggested fix, which a development environment can then apply with a single click. Entire flow paths are also possible, such as the path of an unsafe input through several functions.

SARIF in GitHub, pipelines, and editors

SARIF is most commonly encountered on platforms for program code, especially on GitHub. There, the “Code Scanning” feature accepts SARIF files and displays the findings directly within the project. If a check runs automatically after every change, new warnings appear as comments on the affected code. GitLab and Azure DevOps also support the format.

SARIF is likewise common in automated workflows that experts call a pipeline: a chain of steps that starts without manual intervention with every code change. One step in it is often a security scan. Its result is passed on and evaluated as a SARIF file. If the severity turns out too high, the workflow stops and the change does not make it into the product.

In trade news, the term usually appears in passing. When a vendor announces that its tool now supports SARIF, it means: it fits into existing checking chains without tinkering. For companies this is a selling point, because it makes vendors more easily interchangeable. AI-powered analysis tools also use SARIF, so that their suggestions end up in the same interfaces as those of classic programs.