On this page
How to Add SAST Scanning to a GitHub Repo
Add SAST to a GitHub repo with CodeQL or Semgrep, block on critical findings, and tune the noise. A practical, copy-pasteable tutorial.
Quick answer
- GitHub’s code scanning uses CodeQL and needs almost no setup: enable it in the Security tab or add the workflow file.
- For custom rules and speed, add Semgrep as an alternative or complement.
- Start by blocking on high-confidence, high-severity findings and tune from there.
What you’ll build
SAST scanning on every pull request for a GitHub repo, so vulnerability patterns in code are flagged before merge. Two options: GitHub’s native CodeQL (simplest) or Semgrep (more configurable).
Step 1 — Enable CodeQL (native)
In your repo, go to Settings → Code security and analysis → Code scanning, and enable CodeQL with the default setup. GitHub generates the workflow for you.
How to verify it worked: the Security tab shows a CodeQL workflow that runs on your next push or pull request.
Step 2 — Or add Semgrep for custom rules
Create .github/workflows/semgrep.yml:
name: Semgrep
on:
push:
branches: [main]
pull_request:
jobs:
semgrep:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: semgrep/semgrep-action@v1
with:
config: p/defaultHow to verify it worked: the Semgrep job runs on a pull request and reports findings in the PR.
Step 3 — Confirm it catches a real bug
Temporarily add a classic flaw — a SQL query built with string concatenation — to a branch and open a PR. How to verify it worked: the scanner flags the line in the pull request, proving the tool is actually watching.
Step 4 — Tune the noise
Review the first batch of findings. Fix true positives; suppress false positives with a comment or a rule exclusion; and adjust which severities block a merge. The goal is a signal developers trust, not a red wall they ignore.
Step 5 — Set the block policy
In branch protection or the workflow, decide what fails the build. A common starting point: block on critical and high findings, report the rest.
Where this bites vibecoders
SAST is the automated review that catches the flaws AI assistants keep reintroducing. But a scanner you enable and then ignore is worse than none — it trains the team to dismiss red marks. The habit that makes it stick: confirm it catches a planted bug, then fix or consciously suppress every finding so the dashboard actually reflects reality.
Where AI coding assistants get this wrong
- Pasting a Semgrep config key or action version that doesn’t exist.
- Enabling every rule so the first run floods the repo with findings.
- Treating “scan ran” as “scan reviewed” without triaging results.
- Never verifying the scanner catches a known-bad pattern.
Checklist
- Enable CodeQL or add Semgrep to the repo.
- Run scanning on every pull request.
- Verify it flags a planted test bug.
- Triage findings: fix or suppress with a reason.
- Set a block policy for critical/high findings.
FAQ
What is the difference between CodeQL and Semgrep?
CodeQL (GitHub’s engine) does deep data-flow analysis with a query language; Semgrep is pattern-based, fast, and easy to write custom rules for. Both are solid; many teams use CodeQL for defaults and Semgrep for bespoke rules. See What Is SAST?.
Does code scanning cost money?
GitHub code scanning with CodeQL is free for public repositories and included in many plans for private ones. Check GitHub’s billing for your account’s current limits.
Should I block merges on SAST findings?
Block on high-confidence, high-severity findings; report lower ones. Over-blocking produces bypasses, and under-blocking produces theater. Revisit the threshold as you tune noise.