codeql-reporter: PR comment ignores dismissed/fixed alert states

[bedatty]

Context

The composite action src/security/codeql-reporter reads the CodeQL SARIF output directly and renders the PR comment from it. It does not cross-reference the GitHub Code Scanning API, so it has no notion of alerts that were dismissed via the Security tab or that are already marked as fixed on the base branch.

Discovered while handling findings on #212 — two actions/untrusted-checkout/medium findings kept appearing on every re-scan after being dismissed / confirmed as accepted residual risk, because the SARIF-level detection is structural (the rule fires on any actions/checkout with dynamic repository: / ref: inputs in a privileged workflow, regardless of the surrounding trust model).

Impact

• False signal on PRs. Dismissed alerts keep showing up in the PR comment on every run, confusing reviewers who've already triaged them via the Security tab.
• Disagreement between surfaces. The Security tab (authoritative source) shows zero open alerts, while the PR comment generated by this action shows N findings. Evidence from PR feat(gitops-update): manifest-driven topology + anacleto cluster #212 (see below).
• Pressure to disable rules globally. Contributors may be tempted to add rules to the codeql-config exclusion list (next to actions/unpinned-tag) just to clean up the noise, trading repo-wide security signal for PR ergonomics.

Evidence from PR #212

Final state at head e2c774c8:

Alert	Rule	API state	Still in PR comment?
#113	actions/code-injection L106	fixed	✅ removed
#114	actions/code-injection L108	fixed	✅ removed
#115	actions/code-injection L348	fixed	✅ removed
#116	actions/code-injection L354	fixed	✅ removed
#117	actions/untrusted-checkout L121	dismissed (via UI, with justification)	❌ still shown
#118	actions/untrusted-checkout L104	fixed (on PR merge ref)	❌ still shown

The fixed / dismissed states come from gh api repos/.../code-scanning/alerts?ref=refs/pull/212/merge.
The PR comment comes from the SARIF uploaded by the CodeQL Analysis job, which still reports the two locations.

Root cause

src/security/codeql-reporter/action.yml (inline github-script): reads .sarif files from inputs.sarif-path, iterates over runs[].results[], and renders every finding. There is no call to github.rest.codeScanning.* to fetch alert states and filter them out.

$ grep -c "dismissed" src/security/codeql-reporter/action.yml
0

Proposed fix

Before rendering the comment body, enrich the findings parsed from SARIF with the current state from the Code Scanning API and suppress the ones that are no longer actionable:

1. After parsing the SARIF findings, call
   `github.rest.codeScanning.listAlertsForRepo({ ref: 'refs/pull//merge', state: 'open', per_page: 100 })`
   with pagination.
2. Build a lookup by (ruleId, path, startLine) of alerts whose state is open.
3. Filter the SARIF findings: keep only those that match an open alert. Everything else is dismissed or fixed and should not drive the comment.
4. Optionally: add a small footer like `N finding(s) hidden (dismissed or fixed). See the Security tab for the full list.` so reviewers know the comment isn't lying by omission.

Nice-to-have: gate the enrichment on permissions. If the token lacks security-events: read, fall back to the current SARIF-only behavior with a warning.

Alternatives considered

• Exclude the rule in codeql-config (src/security/codeql-config/action.yml) — already done for actions/unpinned-tag. Works but kills the signal repo-wide. Rejected as the general fix; reasonable only for rules we never want to see again.
• Inline SARIF suppression comments (# codeql[alert-suppression]) — tooling support for YAML actions workflows is not reliable; also, suppressions live in the analyzed file rather than as a policy decision.
• Do nothing, rely on the Security tab — current workaround. Noisy.

Acceptance criteria

• A PR where an alert is dismissed via the UI and the workflow is re-run must produce a PR comment that no longer lists that finding.
• A PR where a finding is fixed on the merge ref must not list it either.
• If the API call fails (permissions, outage), the step degrades gracefully with a warning rather than failing the job.
• README of src/security/codeql-reporter documents the new behavior and any required permissions.

References

• Triaged during: feat(gitops-update): manifest-driven topology + anacleto cluster #212
• Composite: src/security/codeql-reporter/action.yml
• GitHub API docs: https://docs.github.com/en/rest/code-scanning/code-scanning#list-code-scanning-alerts-for-a-repository