Security Code Review Explained: What a Reviewer Looks For in a Diff, and Why

A security code review is the deliberate reading of source code for the specific purpose of finding the ways it can be made to do something its author did not intend. That definition sounds obvious until you compare it to what most teams actually run, which is a functional review with a security checklist nearby. The OWASP Secure Code Review Cheat Sheet draws the line precisely: a security review differs from a functional review by targeting input validation, authentication, authorization, cryptographic implementation and attack vectors, rather than correctness. A diff that works perfectly can still hand an attacker a path into the system, and only one of those two reviews is looking for it.

What makes the topic worth an article now rather than in 2020 is that a language model can read a diff competently, cheaply and continuously — which changes the economics of review without changing a single one of the dimensions being reviewed. The checklist is older than the models and has not moved. What moved is how often you can afford to run it.

What a reviewer is actually reading for

The OWASP cheat sheet organises the work into six areas, and the useful thing about the list is that each area is a question rather than a category. Categories invite box-ticking; questions produce findings.

Input and injection. The question is not whether the code has a sanitizer; it is whether anything reaches an interpreter — shell, SQL, template engine, expression evaluator — and at which layer that requirement is supposed to be enforced. A diff that adds a parameterised query is good; a diff that adds a parameterised query into a function whose other callers pass raw strings is a diff that has moved the problem.

Authentication and session. Who is the caller, and how did the code establish that? The recurring bug is not a broken password check, it is a session that survives a privilege change — elevation happens, the token keeps its old claims, and an hour later the privileges are still there.

Authorization. Object-level checks, every time, on every route. The specific thing to look for in a diff is a new route that does not inherit the guard its siblings have, because middleware is registered per-router and a route added under a different one simply will not be covered.

Cryptography. Primitive, mode, key length, and where the key lives. Two questions catch most real findings: can anyone who can read this codebase also read the key, and is this comparison one that must not leak timing.

Business logic. Whether the sequence can be reordered, replayed, or driven by values the client chose. A price, a quantity, a role or a state transition that arrives from the client and is not re-derived server-side is a finding regardless of how it is validated.

Configuration and secrets. What the diff ships that should never have been in a repository, and whether the defaults are safe where the code actually runs. A debug flag defaulting to true is a finding about production, not about the flag.

Baseline review versus diff review

OWASP separates two modes, and conflating them is a common source of both wasted effort and false confidence. A baseline review examines the codebase comprehensively, and it is the right tool for a new application or a major release, onboarding a legacy system, satisfying a compliance requirement, or doing the post-incident analysis after something has already gone wrong. A diff-based review looks only at what changed, and it is the right tool for pull requests, commits, feature completion and continuous validation.

The distinction matters because the two produce different work. A baseline review ends with a backlog; a diff review ends with a merge decision. Running the first continuously is unaffordable, and running the second on a codebase that has never had the first is how teams accumulate a false sense of coverage: every change passes review, and the pre-existing SQL concatenation sits there untouched.

Techniques, and what each one catches

OWASP lists four review techniques, and they are distinguished by what evidence the reviewer follows rather than by how thorough they are. Code pattern analysis follows familiar shapes: the dangerous function call, the deserialisation of untrusted input, the missing length check. It is fast and it is exactly what a deterministic tool does well. Data flow analysis follows a value from where it enters to where it is used, which is the only way to answer whether the sanitizer applied three functions ago still applies here. Threat-based review starts from an attacker's capability and works forward, which is how you catch the gap between two individually correct components. Business logic review reads the workflow rather than the lines, asking what sequence of legitimate operations produces an illegitimate state.

Only the first of those four is well served by a scanner, and only the first and second are well served by an unguided model pass. That is not an argument against models; it is an argument for telling the reviewer which technique you want, because a prompt that asks for "security issues" will reliably produce pattern analysis and stop.

What AI changed, and what it did not

Research on AI-authored code made the review bottleneck sharper rather than creating it. The NYU study of GitHub Copilot suggestions, published at IEEE S&P in 2022, found roughly 40% of generated snippets contained an exploitable pattern across 18 CWE categories. The Stanford work on developer behaviour, published at ACM CCS in 2023, found the more consequential effect: developers using assistants were more confident their code was secure while producing measurably less secure code. More output plus more confidence is a review problem.

A language model as reviewer changes one variable in that equation — throughput. It can read every pull request, at a cost per token rather than per seat, and it can be asked the six questions above explicitly. It does not change the questions, and it does not acquire the two properties that make a review trustworthy: determinism and the ability to execute the code. The same diff reviewed twice can produce different findings, severities shift between runs, and the reviewer cannot prove that a flagged path is reachable.

OrcaCode Review is the productised form of that idea, and it is worth looking at closely because the design choices reveal the failure modes. A review that isolates the failing case as a specific, reproducible comment — this key still varies in time, so a retried charge mints a new key and can double-charge, here is the one-line change — is doing the job a reviewer does. A review that reports "potential security issue" without a reproduction is doing pattern analysis with worse precision than the pattern matcher. And a rules-and-gate engine published under an open licence is making an implicit claim worth checking: that the reviewer's judgement should be reviewable too.

The two-layer arrangement that works

Given a deterministic scanner and a probabilistic reviewer, the arrangement that survives practice is to give each the work it is actually good at. The scanner runs on every push: seconds, no model, no variance, catching secrets, dangerous API calls, unsafe deserialisation and hallucinated imports. The reviewer runs on every pull request: minutes, model-backed, catching the logic between the lines — whether the authorization check runs before the fetch, whether the idempotency key is bound to a stable value, whether the new route inherited the guard.

Then the layer people skip: the gate. A finding that does not block a merge is a notification, and notifications are read on Fridays. The gate has to be narrow and it has to be absolute — critical findings block, everything else comments — and the waiver has to be written down, because the value of a gate is not that it stops the first finding but that it makes every bypass visible.

Reviewing the change, not the codebase

The practical discipline for a diff review is a short sequence, and its value is that it can be taught in an afternoon. Read the diff for what it adds to the attack surface rather than for what it changes. For each new entry point, follow the input one hop past where the diff ends — the vulnerability is usually in the function it calls, which the author did not read. For each new route, check the guard registration. For each new dependency, check whether it exists and whether someone else published the name. For each new configuration value, ask what it defaults to where it will actually deploy.

None of that requires knowing the language well, which is why it scales to reviewers who are not security specialists. It does require that the reviewer sees the diff rather than the file, because the whole method depends on knowing what is new.

And the honest limit: a diff review cannot find the flaw that was there before the diff. If the application has never had a baseline review, the highest-value security work available is not a better reviewer — it is one deliberate pass over the codebase, in the areas that touch money, identity and file access, with the six questions above. After that, every subsequent diff review is protecting something that has been looked at once. Before it, every diff review is protecting an unknown.