Export alert state, rule, severity, tool name, creation time and, for dismissed alerts, who dismissed it, when, the reason and the comment. GitHub's code scanning REST API returns these. Together they show that findings were detected, reviewed and closed with an explanation, which is what auditors test.
What the API returns
GitHub's REST documentation for code scanning lists an alerts endpoint at the repository path ending in code-scanning and alerts, and an analyses endpoint. An alert object in the documentation's examples includes:
| Field | Why it helps as evidence |
|---|---|
state | Whether the alert is open or dismissed at export time |
rule (id, severity, description, tags) | What was found, and the weakness category tags |
tool name | Which scanner produced it |
dismissed_by, dismissed_at | Who closed it and when |
dismissed_reason, dismissed_comment | Why it was closed, in words |
An example in the documentation shows a dismissed alert with the reason "false positive" and a comment explaining that a sanitizer exists in the library. That pairing of reason and comment is what you want in every dismissal.
Why dismissals matter most
An open alert shows a finding. A dismissed alert shows a decision. Auditors read decisions. A wall of dismissals with empty comments suggests alerts are being cleared to turn a dashboard green. A few dismissals each with a clear reason and a named person suggests triage.
A simple export routine
- Choose a cadence, monthly works for most small teams.
- For each repository with code scanning enabled, call the alerts endpoint and save the JSON.
- Also save the analyses list, which shows that scans ran and when.
- File the output by month and repository.
- Review the dismissals once a quarter. Check each has a reason and comment.
- Record the review in a one line note with a date.
Keep scan runs consistent
GitHub documents that code scanning uses fingerprints to match results across runs, and that ruleId and file paths need to stay consistent. If paths change between runs, new alerts are created and old ones closed. That affects your evidence: a changed path can look like fixed alerts when nothing was fixed. Keep the scan configuration stable and note when you change it.
For uploads from other tools, see keeping SARIF results per release.
Try it yourself
Click through it at your own pace, or open it full screen. Look at the fields a finding carries, then imagine each as a column in your export.
Where Safeguard fits
Safeguard provides SBOM and dependency scanning, reachability analysis and compliance and evidence automation, so findings and their dispositions are kept in one record. You can run a free scan.
Quick check
Is an open alert bad evidence?
Not necessarily. Open alerts show detection. What matters is that you have a triage process and the open items have owners and dates.
Should dismissals always have a comment?
Yes, as a team rule. The API has a field for it, so use it.
Sources
Last reviewed: 19 October 2026.
