## TL;DR
GitHub code scanning files alerts by rule ID, and it only shows alerts for the default branch (or the PR under review). If the SARIF upload went to another branch, or trivy's rule IDs collided with already-dismissed alerts, the upload succeeds and the alerts page says "no new alerts" while the CLI lists 30 highs. Check the upload step's logs, confirm the target branch, and inspect the rule IDs in the SARIF file.

## The query

```text
trivy --format sarif uploaded to GitHub code scanning showed "no new alerts" while the CLI listed 30 highs - rule-id mapping
```

## Use this when

- The SARIF upload step succeeded but code scanning shows no new alerts
- trivy CLI on the same image lists high-severity findings
- The scan runs on a branch other than default, or on a schedule

## Not for

- The upload action itself failing (an action or permissions problem)
- Code scanning showing alerts you disagree with (triage)
- SARIF files that are malformed (a format problem)

## Steps

### 1. Read the upload step's logs

Open the workflow run and read the codeql-action upload-sarif (or github/codeql-action) step output. Confirm it processed the file and reported a successful upload, and note which ref it attached the results to.

Expected output: confirmation of success and the exact branch or PR the results were filed under.

### 2. Check which branch the alerts belong to

Code scanning alerts are per-branch, and the alerts page defaults to the default branch. If the upload ran on a feature branch, the alerts exist but are not where you are looking.

Expected output: you find the 30 alerts under the correct branch's alert list.

### 3. Inspect the rule IDs in the SARIF

```bash
python3 -c "
import json
sarif = json.load(open('trivy.sarif'))
for r in sarif['runs'][0]['tool']['driver']['rules'][:10]:
    print(r['id'])
"
```

Expected output: the rule IDs trivy emitted (usually CVE IDs). Check whether these IDs already exist as dismissed or fixed alerts; GitHub will not re-raise them as "new".

### 4. Compare against the CLI finding list

Match the CLI's 30 highs against the SARIF results by CVE ID. If every CLI finding has a SARIF result with a matching rule ID, the data made it; the display or dedup is what hid them.

Expected output: a reconciled list showing which findings are genuinely new versus already-known.

### 5. Run the scheduled scan against the default branch

For fleet-wide visibility, the scheduled trivy job should check out and scan in the context of the default branch, so its alerts land where the team looks. Verify: the next scheduled run's alerts appear on the default branch's code scanning page.

## Variant phrasings

### trivy sarif github code scanning no new alerts
The short symptom search.

### trivy sarif upload rule id mapping code scanning
The cause-first search.

Compatibility: trivy SARIF output with GitHub code scanning via the upload-sarif action. Applies to scheduled and PR scans.

## Why it happens
Code scanning is not a dumb inbox for SARIF files; it is an alert database keyed by rule ID and location, scoped to branches. Uploading the same CVE findings that were already raised (or dismissed) produces "no new alerts" correctly, from its perspective. And results uploaded for a non-default branch live under that branch's alert list, invisible from the default view. The CLI lists findings; code scanning lists new alerts. Those are different questions.

## Edge cases / pitfalls

- Dismissed alerts stay dismissed across re-uploads with the same rule ID and location. If a dismissal was wrong, fix the dismissal; re-uploading will not override it.
- trivy SARIF rule IDs must be stable across runs for dedup to work correctly. If your trivy version changes the ID scheme, expect a one-time flood of "new" alerts.
- PR scans show alerts in the PR's security tab, not the main alerts page. Check both places before concluding the upload vanished.
- Keep the SARIF file as a workflow artifact for a few days. When the counts disagree again, you will want the exact file that was uploaded.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ynFT8zJFsmaREMH2mHfn6Q