Run lightweight SAST checks in the IDE for instant feedback, a focused scan on every pull request for enforcement, and a deeper scheduled scan for full coverage. Most teams need at least two of the three. If you can only do one, start with the pull request.
What OWASP says about placement
OWASP's guidance on source code analysis tools says they can be built into IDEs so developers catch issues early, and that they scale and can run repeatedly in nightly builds or CI pipelines. Those are three different jobs, so it helps to treat them as three different tools, even when one product provides all of them.
IDE: fast, advisory, easy to ignore
In the editor, feedback arrives while the code is still in the developer's head. Fixing a flagged line costs seconds.
The limits are plain. Developers can ignore it or not install it. Lightweight checks run on the open file, so they miss flows across files. Use the IDE for education and quick wins, not as a control you can point to.
Pull request: the enforcement point
A pull request check is where you can set policy: block on new high severity findings, comment inline, require a reviewer for exceptions. It sees the diff, so results are about what the author just changed.
Keep it fast and quiet. If the check takes twenty minutes or comments on old code, people learn to merge around it. Report only new findings on changed lines at first, and save the backlog for another conversation.
Nightly or scheduled: full coverage and the backlog
A scheduled full scan catches what a diff scan cannot: findings that depend on code far from the change, newly added rules, and issues in code nobody has touched in years. It is also the right place to tune rules and work down a backlog, because speed matters less.
Send results to the same place as pull request findings so developers see one list.
A simple decision guide
- Starting from nothing: pull request check, new findings only.
- Developers want faster feedback: add the IDE plugin to the optional list.
- Concerned about old code: add a weekly or nightly full scan with a triage owner.
- Regulated environment needing evidence: keep the pull request gate and the scheduled scan logs.
Common mistakes
Blocking on everything on day one. Start with warnings, learn the noise level, then block on a narrow set you trust.
Running the full scan on every commit, which slows delivery and burns CI minutes.
Letting findings live in a tool no developer opens. Put them in the pull request and the issue tracker.
Safeguard offers policies and gates, including pull request gates, that can enforce rules like these across repositories. You can see the idea in the demo below.
Click through it at your own pace, or open it full screen.
Quick check
Is an IDE plugin enough?
No. It is optional on each developer's machine, so it cannot be your enforcement point.
Should pull request scans block merges?
Eventually, for a narrow set of findings you trust. Start in warning mode to learn the noise level.
Sources
Last reviewed: 19 October 2026.
