Scan the diff in pull requests for speed, and scan the whole repository on a schedule for completeness. Diff scans keep feedback under a few minutes and avoid blaming developers for old issues. Full scans catch problems that span files and changes that a diff view misses.
What each mode does
Diff scan: analyzes only changed files, or reports only findings on changed lines. Results are quick and tied to the author's work.
Full scan: analyzes the entire codebase and its call paths. Results include every existing issue.
Trade-offs
| Diff scan | Full scan | |
|---|---|---|
| Speed | Fast | Slower |
| Noise on day one | Low | High, includes legacy findings |
| Cross file data flow | May miss | Covered |
| Finds old issues | No | Yes |
| Good as a merge gate | Yes | Rarely |
Why diff alone is not enough
Data flow analysis follows a value across functions and files. If a change in one file makes an old function unsafe, the dangerous line may sit in a file the pull request never touched. OWASP also points out that static analysis often needs complete, compilable code with libraries and build instructions, so partial views can reduce accuracy.
Setup steps
- Run a full scan once and record the result as the baseline.
- In pull requests, show only findings that are new compared with that baseline.
- Block merges for new high confidence findings of the severities you choose.
- Schedule a nightly or weekly full scan and review the delta.
- Work down the legacy list in planned sprints, not through pull request blocks.
Common mistakes
A common mistake is gating on a diff scan without ever running a full one, which leaves older issues invisible. The reverse also hurts: gating on a full scan makes every pull request fail for reasons unrelated to the change, and developers lose trust. Keep the baseline file under version control or in the tool, and re-baseline deliberately, with a record of why, instead of letting it drift each time findings become inconvenient.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch what the gate reports on a change and what it ignores.
Where Safeguard fits
Safeguard provides policy gates for pull requests, with SBOM and dependency scanning and reachability analysis behind them. The free scan is a first look.
Quick check
What is a baseline?
A saved snapshot of existing findings. New scans compare against it so only new issues interrupt developers.
Should legacy findings be ignored?
No. Track them separately and fix by risk. Just do not make them block unrelated pull requests.
Sources
Last reviewed: 19 October 2026.
