What Is Code Review?

Security code review is effective for a specific set of problems and blind to another, and knowing which is which determines whether the effort pays back. Reviewing everything equally is how review programmes become a rubber stamp.

What review finds well, and what it misses

The right-hand column is where serious findings live. An attacker changing an identifier and reading another customer's record is not a coding error visible in a diff — it is a design question, which is why threat modelling matters more than review volume.

Making review worth doing

Review by risk, not by volume. Changes touching authentication, authorisation, cryptography, payment, file handling or anything processing untrusted input deserve real attention. A copy change does not.

Give reviewers a checklist tied to your own threat model rather than a generic list. Reviewers asked to “look for security issues” find style problems; reviewers asked “does this endpoint check the object belongs to the caller” find authorisation flaws.

Treat it as knowledge transfer. The durable return on security review is not the findings — it is that developers who have had three authorisation flaws explained to them stop writing the fourth.

Automated and human review are complementary

Static analysis should run first and clear the mechanical findings, so human attention is spent where judgement is required. A reviewer working through missing input validation that a tool would have flagged is expensive triage.

Making review sustainable

The practical constraint on security review is reviewer attention, and it is finite in a way that tooling is not. A team that attempts to security-review every change will either slow delivery to a degree the business rejects, or — far more commonly — quietly degrade into approving diffs without reading them.

Three habits keep it honest. Route changes by risk, so the reviewer's attention lands where a mistake would matter. Keep changes small enough to actually review, since a thousand-line diff receives a glance regardless of who is looking at it. And rotate reviewers across the codebase, because the person who wrote the original design is the least likely to notice its assumptions.

Where capacity genuinely does not exist, be explicit about it. A documented decision that only authentication, authorisation and payment changes receive security review is a defensible position. A policy claiming everything is reviewed, quietly unenforced, is the worst of both — no coverage and a false record of it.

Where to start

Write a short checklist for your own application — five to ten questions drawn from the flaws you have actually had, or that a penetration test has found. Generic checklists produce generic reviews.

See secure development in practice. GuardsArm reviews secure development practices through application penetration testing.