A baseline review examines the entire codebase at one point in time, and a diff-based review examines just what changed in a pull request or commit. Most teams need both: a baseline for new, inherited or high-risk systems, and diff-based review as the daily routine that stops new problems arriving.
The two review types, defined
The OWASP Secure Code Review Cheat Sheet separates reviews into these two types.
Baseline review. A comprehensive pass over the whole codebase. OWASP lists new applications or major releases, legacy system onboarding, compliance requirements and post-incident analysis as the situations where it fits.
Diff-based review. A pass over the code changes alone. It fits pull requests, commits, feature completion and the normal daily development flow.
| Baseline review | Diff-based review | |
|---|---|---|
| Scope | Whole codebase | One change |
| Typical trigger | Onboarding, major release, incident | Every pull request |
| Effort | Days to weeks | Minutes to an hour |
| Catches | Existing design flaws and old bugs | New flaws and regressions |
| Weakness | Goes stale the day after it ends | Cannot see problems already in the code |
Why one is not enough
A diff-based review sees just the lines in front of it. If an authorization check was missing before the change, a reviewer reading a small, unrelated diff will not notice. That is the gap a baseline closes.
A baseline has the opposite problem. It describes the code on one date. Once the team keeps shipping, the findings begin to age. Without a routine diff-based review, you are paying for a snapshot and then drifting away from it.
How the preparation differs
OWASP lists preparation that applies to both: understand the architecture and business requirements, gather threat models and earlier findings, identify critical assets and high-risk functions, and review the security requirements.
For a baseline, add: map the application boundaries and dependencies, analyse the overall security architecture, check the incident history, and audit third-party libraries.
For a diff-based review, add: identify the modified files and the components they touch, assess the effect on existing security controls, understand the purpose of the change, and prioritise high-risk modifications.
A hybrid that works in practice
The same cheat sheet describes a hybrid approach, and it maps to a simple plan.
- Pick the components where a failure would hurt most, such as login, payments, file handling and anything that parses outside data.
- Run a baseline on those components first, and write down what you found.
- Run diff-based review on every change, everywhere.
- Expand the baseline a little each cycle until it covers the code that matters.
- Escalate from diff to baseline when a change raises a concern about the surrounding code.
Step five is the one teams forget. If a pull request reveals that a module has no consistent authorization pattern, the right response is not a longer comment thread. It is a short baseline review of that module.
Who does what
A diff-based review belongs to the team that wrote the change, with a security champion or security engineer pulled in for the high-risk modifications. A baseline usually needs a few days of concentrated attention from someone with time to trace data through the application, and often an outside pair of eyes.
Try it yourself
Open the demo below and look at how a scan result lists issues by file. Think about which of those you would find from a diff alone, and which need a reader who knows the surrounding code.
Click through it at your own pace, or open it full screen.
Safeguard supports the diff side of this with pull request gates and policies, and the baseline side with dependency scanning and reachability analysis across a whole repository. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Can automated tools replace a baseline review?
No. OWASP describes manual review as complementary to automated testing, aimed at business logic and context that tools tend to miss. Use tool output to decide where to look, then read that code yourself.
How often should we repeat a baseline?
OWASP ties baselines to events: a major release, an architecture change, an incident, a compliance cycle, or onboarding a legacy system. A fixed calendar date matters less than those triggers.
Sources
Last reviewed: 19 October 2026.
