To set up SAST in CI for pull requests, add a workflow that runs your scanner on the pull request trigger, scan only changed code, show findings as comments or code scanning annotations, and block merges only on high severity results after a tuning period. Start in report-only mode.
Key takeaways
- Run on the pull request event so developers see findings before merge.
- Report only new findings, using a diff-aware scan or a baseline.
- Use SARIF so GitHub shows results from any tool as annotations.
- Do not block merges on day one. Tune for a couple of weeks first.
Step 1: Which scanner should I wire in?
Pick one that documents a CI path for your platform. CodeQL ships as GitHub Actions. Semgrep documents a sample GitHub Actions config. gosec has a GitHub Action. GitLab SAST runs in GitLab CI. See best SAST tool for a small team if you have not chosen.
Step 2: How do I run it on pull requests?
Use the pull request trigger in your workflow. Semgrep's sample config includes the pull_request trigger under the comment "Scan changed files in PRs (diff-aware scanning)", runs in the semgrep/semgrep container and calls semgrep ci with a token stored as a repository secret. For CodeQL advanced setup, GitHub says the pull_request trigger scans pull requests targeting the default branch and results appear as alerts in a check. Advanced workflows need the security-events: write permission, and private repositories also need contents: read.
A minimal CodeQL query suite choice looks like this inside the init step:
- uses: github/codeql-action/init@v4
with:
queries: security-extended
Interpreted languages must use build mode none. Compiled languages use autobuild or a manual build.
On GitLab, SAST by default runs only in branch pipelines. You must follow GitLab's guidance on merge request pipelines to run it there.
Step 3: How do I show only new findings?
Use a diff-aware scan. Semgrep reports findings caused by changes since a baseline, set with SEMGREP_BASELINE_REF on CI providers configured manually. The tradeoff, per its docs, is no cross-file analysis in diff-aware mode. Keep a scheduled full scan for that, for example the weekly default CodeQL schedule.
Step 4: How do I get results into the pull request?
Emit SARIF and upload it. GitHub's docs say any valid SARIF 2.1.0 file can be uploaded with the upload-sarif action. gosec, for instance, writes SARIF with the -fmt sarif and -out flags. On the pull request, the code scanning results check shows each tool separately and new alerts on changed lines appear as annotations. Limits to remember: 10 MB gzipped per file and 25,000 results per run.
Step 5: When should the check block a merge?
Block only after tuning, and only on severe findings. GitHub's results check fails on error, critical or high severity alerts, and lower severities appear as warnings or notes. You can change which severities fail the check in repository settings. A scanner's exit code can also fail a build. gosec exits 1 when there are unsuppressed findings, unless you pass -no-fail.
See how a pull request gate looks in the interactive demo.
Click through it at your own pace, or open it full screen.
What about fork pull requests and secrets?
Workflows from forks usually do not get your repository secrets. Check your CI platform's rules before using a token-based scanner on public repositories.
Frequently asked questions
Should SAST run on every pull request?
Yes, on the pull request event, with a diff-aware or baseline scan so runtime stays short.
Do I need a paid plan to run CodeQL on pull requests?
GitHub says private repositories need a GitHub Code Security license. Public repositories can use code scanning without the add-on.
How long should a pull request scan take?
Aim for minutes. If a full scan is slow, use a diff-aware scan on pull requests and a full scan on a schedule.
What if developers ignore the findings?
Tune the noise first. See how to reduce SAST false positives.
Sources
- Semgrep sample CI configs: https://docs.semgrep.dev/semgrep-ci/sample-ci-configs
- Semgrep customize CI jobs: https://docs.semgrep.dev/deployment/customize-ci-jobs
- GitHub, customizing advanced setup for code scanning: https://docs.github.com/en/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/customizing-your-advanced-setup-for-code-scanning
- GitHub CodeQL action: https://github.com/github/codeql-action
- GitHub, SARIF support: https://docs.github.com/en/code-security/code-scanning/integrating-with-code-scanning/sarif-support-for-code-scanning
- GitHub, triaging code scanning alerts in pull requests: https://docs.github.com/en/code-security/code-scanning/managing-code-scanning-alerts/triaging-code-scanning-alerts-in-pull-requests
- GitHub, about code scanning: https://docs.github.com/en/code-security/code-scanning/introduction-to-code-scanning/about-code-scanning
- gosec: https://github.com/securego/gosec
- GitLab SAST docs: https://docs.gitlab.com/user/application_security/sast/
Last reviewed: 19 October 2026.
