Save one SARIF file per release, named by tag and commit, and keep scan settings stable so alerts match across runs. GitHub can parse SARIF 2.1.0 results from third-party tools and uses fingerprints to avoid duplicate alerts, which means inconsistent paths or rule identifiers can distort your history.
What SARIF is, in plain words
SARIF is a standard JSON format for the output of static analysis tools. Many scanners can write it, which makes it a convenient common shape for evidence. GitHub documents that it can parse SARIF files from third-party tools to show code scanning alerts, and that CodeQL results use a supported subset of SARIF 2.1.0.
Why stability matters
GitHub's documentation explains that each upload is processed and alerts are added to the repository, with fingerprints used to match results across runs so each issue appears once in the latest run for the selected branch. Two conditions are called out:
- The ruleId for a result must be the same across analyses.
- File paths must be consistent across runs, or each new analysis creates a new alert and closes the old one.
For evidence, this means a tooling change can look like a spike in fixed findings. Note any tool or configuration change in your evidence log with a date.
Per release archive
| Item | Keep |
|---|---|
| The SARIF file | One per release or per merge to main |
| Tool name and version | In the file name or the index |
| Commit and tag | In the file name |
| Scan configuration | A copy of the config file at that commit |
| Digest | SHA-256 beside the file |
Steps
- Make the scan job write SARIF to a known path.
- Upload it for code scanning so the team sees alerts in the pull request.
- Copy the same file to your evidence store with a name like repository, tag, tool, date.
- Store the digest and add a row to the release index.
- When you change tools, run both for one cycle and record the overlap, so history stays comparable.
What the archive proves
It proves that a scan ran on a given commit and what it found at that moment. It does not prove the findings were handled. For that, pair it with the alert records described in code scanning alerts as audit evidence.
Try it yourself
Click through it at your own pace, or open it full screen. Notice the rule and location attached to each result, the same fields a SARIF file carries.
Where Safeguard fits
Safeguard provides SBOM and dependency scanning and compliance and evidence automation, so results are stored per scan with timestamps. You can run a free scan.
Quick check
Is SARIF only for one scanner?
No. It is a standard format that many tools can write, which is why GitHub can accept third-party results.
Why did a tool change look like many fixed alerts?
If file paths or rule identifiers change between runs, new alerts are created and old ones closed, as GitHub documents.
Sources
Last reviewed: 19 October 2026.
