Diff-only review vs. whole-tree SAST: why scope shaped like the change wins
Whole-tree static analysis has a place. But for the day-to-day question — "is it safe to merge this?" — diff-only review is faster, cheaper, and a lot easier for the team to actually act on.
The mismatch
Classic SAST tools were designed to scan the entire codebase, on a schedule, and produce a backlog. That made sense when the unit of work was a release every quarter. It makes much less sense when the unit of work is a merge request opened twenty minutes ago.
If a developer is waiting on a verdict for an 80-line change, the worst thing a tool can do is hand them 4,200 findings from elsewhere in the codebase. They'll close the tab.
What "diff-only" actually means
Diff-only review reads only the lines that changed in this MR — added, removed, or modified — plus the immediate context needed to understand them. It deliberately doesn't re-litigate the rest of the repo on every commit.
- Fast: reviewing 80 lines is bounded work, not whole-tree work.
- Cheap: the per-MR cost stays predictable as the codebase grows.
- Actionable: every finding is on something the author touched five minutes ago, while the context is still fresh in their head.
What you give up — and what to do about it
Honest tradeoff: diff-only review will not, on its own, find a vulnerability that has been sitting untouched in app/Legacy/Reports.php for three years. That's fine — diff-only isn't trying to. Its job is to keep the next change clean.
For the legacy stuff, run a periodic full scan separately and treat the output as a planning artefact, not a per-commit blocker. Two different tools doing two different jobs is healthier than one tool doing both badly.
Why this lands better with engineering
Engineering teams tolerate tools that respect their time. Diff-only review respects the team's time by definition — it never asks them to read findings about code they didn't touch. That single property does more for adoption than any amount of documentation.