Diff-First Scanning: Why Context Matters More Than Coverage

Security scanning has a coverage problem that is actually a relevance problem. Full repository scans produce comprehensive results, but most of those results are not actionable in the context of a pull request.

The full-scan trap

A full-scan approach generates findings for the entire codebase on every PR. In a mature repository, that can mean hundreds of findings. Most of them existed before the current PR and have nothing to do with the code being reviewed.

This creates three problems:

1. Signal loss. The developer cannot find the finding that relates to their change.
2. Alert fatigue. After the third PR with 200 unrelated findings, developers stop reading.
3. Ownership confusion. Who is responsible for fixing a finding introduced six months ago by a developer who has since left?

How diff-first scanning works

Diff-first scanning analyzes only the code changed in the current pull request. The process:

1. Extract the diff between the PR branch and the target branch.
2. Identify new and modified lines.
3. Run detectors only against changed code and its immediate context.
4. Report findings tied to specific lines in the PR diff.

When you still need full scans

Diff-first scanning is not a replacement for full scans. It is the right default for PR workflows. Full scans serve different purposes:

• Baseline creation — initial scan to catalog existing issues.
• Periodic audits — scheduled scans to catch issues introduced through dependency updates or configuration changes.
• Compliance requirements — some frameworks require evidence of full coverage.

The right default

For pull request workflows, diff-first is the right default because it aligns scanning with the developer's mental model. They are thinking about the code they changed. The scanner should be thinking about it too.

Coverage metrics matter for compliance. Relevance metrics matter for adoption. Optimize for relevance in daily workflows and schedule full scans for periodic review.