Partly. SARIF 2.1.0 lets a result carry a suppressions array with a kind, a status and a free text justification, so a dismissal can travel in the report file. It does not standardize the decider, the date or an expiry, so you still need a sidecar record for those.
What SARIF is
SARIF is the Static Analysis Results Interchange Format, an OASIS standard for the output of analysis tools. A SARIF file holds runs, each with results. Many tools write it, and many platforms read it, which makes it a natural carrier when you move between scanners.
What the suppressions property holds
Under the 2.1.0 specification, a result may contain a suppressions array. Each suppression object has:
- kind: either inSource, meaning a language construct such as an annotation suppresses the result, or external, meaning the result is suppressed in an external persistent store.
- status: accepted, underReview or rejected.
- location: where the suppression is stored.
- guid: which, per the spec's note, can link the suppression to a record in a result management system.
- justification: a user supplied explanation.
The specification adds a behavior worth knowing. If the array is present but empty, a consumer must treat the result as not suppressed. If the array is absent or null, no suppression information is available at all. A migration script should not confuse the two.
The migration use
A decision exported from your old scanner as "external, accepted, justification: only used in tests" maps cleanly to a suppression object. The new tool, if it reads suppressions, can show the result as handled. The guid field can point back to the original record so the two stay linked.
The related baselineState property is also useful for checking your work. It marks each result as new, unchanged, updated or absent with respect to a baseline run. After import, a run compared against the baseline should show most results as unchanged. A big block of "new" results means identity matching failed.
Where it falls short
| Need | SARIF support |
|---|---|
| Reason text | Yes, justification |
| Accepted or under review | Yes, status |
| Who decided | Not standardized |
| When it was decided | Not standardized |
| Expiry date | No |
| Ticket link | Partly, through work item URIs on the result |
For those gaps, add properties in your own namespace or keep a sidecar file. Check whether the consumer preserves unknown properties before relying on them.
Also remember that SARIF is built around code locations. Dependency findings point at a manifest or lockfile rather than a source line, and some consumers handle that differently. Test with a small dependency file.
Practical steps
- Export a sample of 20 decisions from the old tool.
- Convert them to SARIF suppression objects with a script.
- Load them into the new tool and see which fields survive.
- Record what was dropped and decide on a sidecar for it.
The spec also warns that justification text is user supplied, so a consumer should show it with care. Sanitize comments before you generate files.
Quick check
Does an empty suppressions array hide the finding?
No. Per the specification, an empty array means suppression information exists and the result is not suppressed.
Is SARIF the only way to move decisions?
No. VEX documents, CSV files and vendor APIs also work. SARIF is useful when both tools already read it.
Sources
Last reviewed: 19 October 2026.
