SARIF ingestion from a third-party scanner
Fifteen repositories run CodeQL plus a commercial SAST tool. The vendor CLI produces SARIF 2.1.0, which a reusable workflow uploads with github/codeql-action/upload-sarif. Three problems appeared. First, pull requests from forks show Resource not accessible by integration and produce no SARIF results. Second, after adding the vendor upload to a repository whose advanced CodeQL workflow used the category sast, the CodeQL alerts disappeared from the Security tab while vendor alerts remained. Third, after every push, previously triaged vendor alerts reopen as new alerts, roughly tripling the alert count, and the SARIF includes 3,000 informational findings from rules the vendor marks low confidence. The largest service produces a 12 MB SARIF file, and its uploads occasionally fail with a size-related error. The team wants pull request gating on high-severity vendor findings without breaking fork contributions.
1. How do you fix SARIF uploads for pull requests from forks?
Read the worked answer
On pull_request from a fork, GITHUB_TOKEN is read-only regardless of the permissions block, so security-events: write cannot be granted and upload fails. Do not fix it with pull_request_target plus a checkout of the fork's code: that runs untrusted code with a write token and a secret-bearing context, which is a supply-chain compromise.
Use a two-workflow pattern. The unprivileged pull_request workflow builds and scans, writes the SARIF as an artifact, and stops. A second workflow triggered by workflow_run in the base repository downloads the artifact and uploads it with security-events: write. Treat the artifact as untrusted: validate the SARIF schema and size, never execute anything from it, and restrict which workflows may trigger the privileged upload. Gate merges on the resulting code scanning check, and test with a real fork pull request before rolling out to all fifteen repositories.
2. Why did the CodeQL alerts disappear, and what is the rule for categories?
Read the worked answer
Code scanning stores results per category and per Git ref, and a new upload replaces prior results for the same category on that ref. Two producers sharing sast overwrite each other, which is why the CodeQL alerts vanished while vendor results remained.
Give every producer a unique, stable category: one per tool and per language, for example codeql-javascript, vendor-sast-payments, semgrep. Categories must stay stable over time, because renaming one creates a new result set and shows up as a mass close plus mass open. Confirm both sides of the configuration: default setup uses per-language categories, while an advanced workflow sets category in the init step, and neither may reuse the vendor's value. After correcting categories, rerun both analyses and verify in the Security tab that alerts from both tools coexist, then document the naming convention inside the reusable workflow so repositories cannot diverge.
3. How do you stop duplicate alerts and handle the oversized SARIF file?
Read the worked answer
Duplicates across runs mean GitHub cannot match a new result to an existing alert. The vendor SARIF either omits partialFingerprints or derives them from volatile values such as timestamps or run IDs. Configure the tool to emit stable fingerprints from rule ID, file path, and a normalized code snippet, so triage state survives line shifts and refactors; if the tool cannot, post-process the SARIF before upload. Never include a timestamp or UUID in a fingerprint.
For volume, filter the 3,000 informational results before upload - keep the full report as an artifact for audit and upload only findings the team will act on. For the 12 MB file, split the SARIF by project or rule set and upload each with its own category, since per-upload result and size limits otherwise cause intermittent failures. Add validation in the reusable workflow that fails clearly when a SARIF file is oversized or lacks fingerprints, instead of silently dropping results.