SAST is most valuable when it comments on risky code while the author still has the file open. It is least valuable when it dumps hundreds of historical findings onto the default branch and teaches the team to treat static analysis as wallpaper.
GitHub Actions is a good home for SAST because the pull request is already the review point. The question is not whether to add a scanner. The question is how to choose a rule set and workflow that developers will still respect three months later.
TL;DR
- Put SAST on pull requests where developers can still act on the result quickly.
- Start with curated rules and a small blocking set before you write custom checks.
- If a rule repeatedly wastes time, tune it or remove it rather than telling developers to ignore it.
- Treat SAST as code review assistance first and a hard gate second.
| Goal | Tooling | Example |
|---|---|---|
| Developer-facing PR feedback | Semgrep CI | semgrep ci |
| GitHub-native code scanning | CodeQL | github/codeql-action |
| Local experimentation | CLI scan | semgrep scan |
| Policy tuning | Rule curation | only block what you will fix |
Start here: Start with What SAST catches well. You get better pipelines when you are honest about both the strengths and the blind spots.
What SAST catches well
Static analysis is good at spotting risky patterns before the code runs: insecure API usage, dangerous sinks, obvious injection paths, missing validation steps, and other mistakes that show up clearly in source. That makes it a natural fit for pull requests.
Static analysis is not a magic runtime oracle. It will never tell you everything about a live deployment, a misrouted header, or a staging-only configuration quirk. The best teams use SAST for what it is good at and let runtime checks handle the rest.
A sensible GitHub Actions setup keeps the job small and obvious
If the workflow definition is unreadable, nobody will tune it when the rule set drifts. Small security jobs age better. That is one reason the native Semgrep CI example is useful: it makes the control easy to explain and easy to maintain.
If you already use Semgrep AppSec Platform, the official GitHub Actions configuration is short. If you want a purely GitHub-native route, CodeQL is a reasonable alternative. The principle is the same either way: tie the result to the pull request and keep ownership close to the team changing the code.
Alert fatigue is a pipeline design bug
When developers complain that SAST is noisy, the answer is usually not more discipline. It is better tuning. Either the wrong rules are enabled, the severity model is out of step with the repository, or the workflow is surfacing too much historical debt as if it were new work.
You fix that by trimming the blocking set, scoping rules to the languages you actually use, and reviewing repeated false positives as design defects in the security workflow. A noisy gate is not maturity. It is just a slow way to lose trust.
Make SAST feel like code review support, not a compliance chore
The strongest SAST programs read like extra review context. Developers see why the finding exists, where the risky pattern is, and what sort of fix would satisfy the policy. That keeps the job close to engineering quality rather than distant governance.
This is also where operational hygiene matters. Your existing GitHub posts on workflow run cleanup and branch protection are relevant because CI health and merge policy are part of whether a security job remains useful over time.
Example workflow
This official Semgrep CI shape is a good example of a small, readable SAST job attached to GitHub Actions.
FAQ
Should SAST block every pull request?
No. Start with a small blocking set of high-confidence findings. Let the rest show up as review input until the rule quality is good enough to justify stricter enforcement.
Is Semgrep the only option in GitHub Actions?
No. CodeQL is a strong GitHub-native option. The more important choice is whether the workflow gives useful, review-time feedback to the team changing the code.
Why do developers ignore SAST so quickly?
Usually because the signal-to-noise ratio is poor. Repeated false positives, huge historical backlogs, and unclear remediation guidance train people to stop looking.
Related: GitHub CLI Secrets: Automate Branch Protection Rulesets and How to Delete All GitHub Actions Workflow Runs with the GitHub CLI both help keep the CI layer around SAST disciplined and maintainable.