Ask each candidate tool for a SARIF export from your pilot, then check five things: stable fingerprints, baseline state, suppressions with justifications, code flows showing the data path, and a file size that fits the platform you upload to. Supporting SARIF in name is not the same as filling these fields.
What SARIF is
SARIF, the Static Analysis Results Interchange Format, is an OASIS standard for the output of static analysis tools. The current version is 2.1.0. It is a JSON format whose top level holds one or more runs, each with the results of one tool execution. The specification states its goal as a widely used format that readily available tools can parse.
For a buyer, that means a way to move results between tools and into code hosting platforms. It is also a lock in check: if the export is rich, you can leave with your data.
Five fields to look at
Fingerprints. The spec defines fingerprint and partial fingerprint properties that let a results management system track a result across runs. Without stable ones, every rescan makes old findings look new. GitHub's code scanning documentation says it uses one partial fingerprint property to match results across runs, and that rule identifiers and file paths must stay consistent, otherwise it opens new alerts and closes old ones.
Baseline state. A property recording whether a result is new, unchanged or absent relative to a baseline. This is what new code only reporting builds on.
Suppressions. An array of suppression objects with kind, status, location and justification. If dismissals from your pilot appear here with the reason text, your decisions are portable.
Code flows. A description of an execution path relevant to a result, made of thread flows and locations. This is how a tool can express the route from input to dangerous call. A tool that outputs only a file and line has less to say.
Rule metadata. Rule identifiers, descriptions and help text. Check that identifiers do not change between runs.
Limits to know
Platforms cap uploads. GitHub's documentation lists, among other limits, a ten megabyte maximum for a gzip compressed SARIF file, a cap on results per run where only the highest severity ones are shown beyond a threshold, and a requirement to keep rule identifiers and paths consistent. Limits can change, so check the current page before you rely on a number.
If a candidate tool produces a huge file on your biggest repository, test an upload during the pilot.
A quick export test
- Run each tool on one repository and export SARIF.
- Validate the file with any SARIF viewer or validator.
- Open it and look for the five fields above.
- Rescan after a trivial edit and compare fingerprints.
- Upload it to your code hosting platform and confirm the alerts appear, once.
Differences between tools here predict how smooth integration and later migration will be.
When SARIF is not needed
If you use one vendor end to end, with a dashboard you are happy with, and have no plans to move, SARIF matters less. But exit options are cheap to ask for before signing.
Quick check
Does supporting SARIF mean everything exports?
No. Check that fingerprints, suppressions and code flows are actually populated in a real export.
Why do duplicate alerts appear after upload?
Usually inconsistent fingerprints, rule identifiers or file paths between runs.
The Safeguard CLI can write SARIF output, and the free scan at gold.safeguard.sh/scan needs no setup.
Sources
Last reviewed: 19 October 2026.
