SARIF (Static Analysis Results Interchange Format) is a JSON format that lets different scanners report findings in one shape, so one place can display them. Emit SARIF 2.1.0 from each tool, label each run with a category, and upload to a central viewer or code scanning.
What to know about GitHub's SARIF support
The GitHub documentation states that code scanning supports SARIF 2.1.0 only. Limits it lists for uploads:
| Limit | Value |
|---|---|
| Compressed file size | 10 MB |
| Runs per file | 20 |
| Results per run | 25,000 |
| Rules per run | 25,000 |
| Results shown beyond 5,000 per run | Dropped, keeping highest severity first |
Each run can contain results from one analysis tool. If you run the same tool several times on a commit, for example per language, give each a distinct category through runAutomationDetails, with an id in the form category/run-id.
Avoiding duplicate alerts
Code scanning matches results across runs by fingerprint. The docs say only primaryLocationLineHash inside partialFingerprints is used. The upload-sarif action tries to generate fingerprints if absent, but direct API uploads without them can create duplicates unless you compute them. Keep ruleId and file paths consistent between runs, or alerts will appear to close and reopen.
Steps to standardise
- Inventory the scanners you run and whether each can emit SARIF 2.1.0.
- Write down a category naming scheme, such as
sca,sast-java,secrets. - Add an upload step to the shared pipeline with a category per scan type.
- Test with a seeded finding: it should appear once, and close when fixed.
- Watch for large reports hitting size or result limits, and filter noise before upload.
What SARIF does not solve
Severity scales differ between tools, and SARIF does not make them equal. Agree a mapping in policy. SARIF is also aimed at code location findings, so dependency vulnerabilities and runtime findings may fit awkwardly. You may need a platform view that combines them with context such as reachability.
Where SARIF fits in the wider picture
Think of SARIF as a transport format, not a triage system. You still need ownership, deduplication across tools, and policy about what blocks. See Safeguard CLI in Azure DevOps with SARIF for a concrete pipeline recipe.
Quick check
Can I upload SARIF 2.0 files?
Per the GitHub documentation, code scanning supports 2.1.0 only. Convert older files first.
Why do my alerts keep reopening?
Likely changing rule ids, paths or missing fingerprints between runs. Keep them stable and let the action generate fingerprints.
Safeguard's CLI can produce results for pipelines, and the free scan at gold.safeguard.sh/scan shows how findings are presented.
Sources
- GitHub Docs: SARIF support for code scanning, fetched 19 October 2026
Last reviewed: 19 October 2026.
