Home / Knowledge hub / Secure code review
Knowledge hub
Secure code review
Reading code specifically to spot security flaws before they ship.
What it means
Secure code review is reading source code with one question in mind: can this be abused? A reviewer follows data from where it enters, through the logic, to where it is stored or sent, and looks for places where trust is misplaced.
It differs from a normal review for correctness or style. The reviewer looks for missing authorisation checks, unsafe handling of input, weak use of cryptography, and secrets left in the code. It can be done by people, by tools, or by both.
Why it matters
Reading code finds flaws at the cheapest moment, before they reach customers. A missing ownership check spotted in a pull request costs minutes. The same flaw found after a breach costs an investigation, a notification and a loss of trust.
It also finds things testing misses. A running test only sees the paths it happens to try. A reviewer can see the unused admin function, the debug route left in, or the branch of logic that only runs on a rare error, and ask whether it is safe.
How it shows up
Reviews are strongest when they are focused and the reviewer knows what the change is meant to do. Sign-in, access control, payments, file upload and anything that builds a query or a command deserve a closer read than a colour change. A short checklist keeps reviewers from relying on memory.
The mistakes repeat. Large changes get skimmed. Reviewers read only the changed lines and miss the unchanged code that the change relies on. Findings are noted in comments and never tracked. Pair the read with static analysis for the routine patterns, and keep human attention for logic.
Questions people ask
Secure code review, answered
Is secure code review the same as SAST?
No. SAST is an automated tool that matches code against known patterns. Secure code review is a person reading with security in mind. Tools are fast and consistent. People are better at logic, intent and context.
Who should do the review?
A developer other than the author, ideally one with security training. For sensitive areas, a security specialist should read too. A security champion can bridge the two. The author is too close to the code to see its blind spots.
Does code review replace penetration testing?
No. Reading code shows what the code says, and testing shows what the running system does. Configuration, deployed behaviour and chained flaws only appear when you test the live application.
How long should a review take?
Reviewer attention drops on large changes, so smaller pull requests get better reviews. Rather than set a time, set a size limit, and give sensitive changes extra reviewers. Short reviews of small changes beat long reviews of large ones.
What should reviewers look for first?
Start with where untrusted input enters, where decisions about who may do what are made, and where secrets and sensitive data are handled. Those places hold most of the serious flaws.
Sources
Where this comes from
Related
Terms that sit next to this one
SAST
Tools that read your source code without ever running it.
White-box testing
Testing with access to the source code, not just the running application.
Security champion
A developer in a team who takes on security questions and spreads good habits.
Static analysis rules
The patterns a code scanner uses to decide what counts as a flaw.
Pull request security check
Automatic security testing that runs on a code change before it is merged.
What does the code say versus do?
In white-box mode we read your code while testing the running app, so a finding can point to the file and line, and we report only what we exploited. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.