Duplicate alerts after a SARIF upload usually mean GitHub could not tell that two results are the same finding. It matches results across runs with the partialFingerprints property, and with paths. Supply stable fingerprints, keep file paths consistent, and the same finding stays one alert.
How matching works
Each time you upload results, code scanning processes them and adds or updates alerts. To avoid showing the same problem twice, GitHub uses fingerprints to match results from different runs, so a finding appears once in the latest run for the branch.
The fingerprint comes from the partialFingerprints property defined in the SARIF standard from OASIS. GitHub's documentation says files produced by the CodeQL workflow or the CodeQL command line already include this data.
Two causes of duplicates
| Cause | What happens |
|---|---|
| No fingerprints in the file and none computed | Alerts are processed and shown, but users may see duplicates |
| File paths differ for the same result between runs | A new alert is created and the old one closes |
The second cause is easy to miss. GitHub's page notes that if file paths differ for the same result on each new analysis, a new alert is created and the old one is closed. A build that writes absolute paths from a temporary directory will do this on every run.
What the upload action does for you
If your SARIF lacks partialFingerprints, the upload-sarif action calculates the field and tries to prevent duplicates. The documentation adds a condition: GitHub can only create them when the repository contains both the SARIF file and the source code used in the analysis. That is, the action needs the checkout.
If you upload through the code scanning REST endpoint for SARIF files instead, and do not provide fingerprints, alerts are still processed and shown, but duplicates may appear. The documentation suggests computing the data before upload, and points to the script the upload action uses as a starting point.
A checklist for tool builders
- Emit relative paths, rooted at the repository, using a base identifier in the artifact location where your tool supports it.
- Keep the path style the same on every run and every operating system.
- Include partialFingerprints for each result, generated from stable content, not from line numbers alone.
- Do not put timestamps or run IDs in the fingerprint.
- Upload from a workspace that contains the source, so GitHub can compute fingerprints when you do not.
GitHub's example shows fingerprint keys named primaryLocationLineHash and primaryLocationStartColumnFingerprint, which are the ones its tooling computes.
One tool per run
A SARIF file can hold several runs, and each run represents one execution of one tool. The documentation says each run can only have results for one analysis tool. If you merge two scanners into a single run, you will break filtering and matching. Use two runs.
Try it yourself
Click through it at your own pace, or open it full screen. Find the file and line a finding points to, since that location is what fingerprints are built from.
Where this fits
Safeguard's CLI can write SARIF, as described in its output formats post. The free scan is a first step if you want to see findings before wiring up CI.
Quick check
Does the upload action fix missing fingerprints?
It calculates them when they are missing, provided the repository holds the SARIF file and the source that was analyzed.
Why do alerts close and reopen when I change build paths?
Different paths for the same result make GitHub create a new alert and close the old one. Keep paths stable.
Sources
Last reviewed: 19 October 2026.
