A secure code review process is a structured read of an application’s source code to find security flaws before attackers do. A reviewer, usually a person helped by tools, checks how the code handles untrusted input, who is allowed to do what, and where secrets and data end up. It answers a different question from a normal peer review. Instead of “does this work?”, it asks “what could someone make this do that we never intended?”
This guide explains how the secure code review process works, what reviewers look for, and how it fits alongside scanning and penetration testing. It is written for IT managers and business owners who commission software, not only for developers.
Table of Contents
What does the secure code review process involve?
The OWASP Secure Code Review Cheat Sheet describes it as manually reading source code to find security flaws that automated tools often miss. The focus is on application logic, data flow and implementation detail.
So what happens in practice? A reviewer will:
- read the code alongside the design, so they know what each part is meant to do;
- trace how data enters the application and where it ends up;
- check each security decision, such as login, session handling and access checks;
- record every finding with the file, the line and a fix the developers can act on.
Tools help with the first pass of the secure code review process, because they can point a reviewer at risky areas and check dependencies. But the cheat sheet is clear that the core analysis depends on human judgement, and that people should filter out false positives.
What do reviewers look for in the code?
The OWASP cheat sheet lists the weaknesses that come up most often. A reviewer works through each of them:
- Input validation gaps. Missing server-side checks are the usual culprit.
- Injection flaws. These include SQL injection, cross-site scripting, path traversal, command injection and NoSQL injection.
- Weak authentication and sessions. Think poor password handling, guessable tokens and badly configured cookies.
- Broken access control. A user who can reach another customer’s records by changing a number in a request is the classic example.
- Unsafe deserialization and XML external entity processing.
- Cryptographic mistakes. Examples are weak algorithms, poor key management and reused nonces.
- Business logic flaws. Race conditions and steps in a workflow that can be skipped fall here.
The last group matters most, because it is where tools fall down. A scanner cannot know that a discount code should only work once, or that an invoice should never be approved by the person who raised it. A human reviewer who understands the business can spot that.
What are the different types of secure code review?
The same cheat sheet splits reviews into two kinds.
Baseline review
A baseline review covers the whole codebase. It suits a new application, a major release, a legacy system you have just inherited, a compliance requirement, or the aftermath of an incident. The cheat sheet gives eight areas to cover: architecture, entry points and input validation, authentication and authorisation, data flow, business logic, cryptography, error handling and configuration.
Diff-based review
A diff-based review looks only at code that has changed. It fits pull requests, day-to-day development and hotfixes. The reviewer concentrates on what the change does to access control, whether it opens a new attack route, and whether it crosses a trust boundary or adds a new integration.
Most teams need both in their secure code review process. A baseline review sets a starting point, and diff-based reviews stop new problems creeping in.
How is a secure code review different from SAST?
Static application security testing (SAST) is the automated cousin of code review. A tool scans source or compiled code and flags suspect patterns. OWASP’s page on source code analysis tools lists clear strengths. They scale to large codebases, run on every build, and reliably catch some well-known classes such as SQL injection. Results also point to the exact file and line.
The same page is blunt about the limits. Such tools “can automatically identify only a relatively small percentage of application security flaws”. Authentication problems, access control issues and misuse of cryptography are hard for them to detect. They often miss configuration issues because configuration is not part of the code. And they produce false positives, so someone still has to decide what is real.
Because of this, SAST and manual review do different jobs. Run the tool on every commit, then bring in a person for the parts a tool cannot reason about.
Secure code review or penetration testing: which do you need?
They answer different questions, and they work best together.
| Question | Secure code review | Penetration testing |
|---|---|---|
| What is examined? | The source code | The running application or network |
| When is it most useful? | During development | Before release and on a regular schedule |
| What does it prove? | Where the flaw is in the code | That the flaw can really be exploited |
| What can it miss? | Problems that only appear when deployed | Code paths nobody thought to probe |
So a review finds the flaw and the line responsible. A test shows an attacker getting through it. If you have to choose, pick based on the stage of the project. A product still being built gains most from review. A live system that holds customer data should be tested. For a deeper comparison of the automated options, see our piece on SAST, DAST and penetration testing, or read how API penetration testing works if your application is mostly an interface for other systems.
When should you commission an external secure code review process?
Your own developers should review each other’s work every day, and that is the cheapest secure code review process you will ever run. An outside reviewer is worth the money in a few situations:
- you are about to launch a product that handles payments, health data or personal information;
- you have bought, inherited or outsourced code that nobody in the company fully understands;
- a customer, insurer or regulator has asked for independent assurance;
- you have had an incident and need to know whether the same flaw exists elsewhere.
The NCSC developers collection makes the underlying point well: complexity is the enemy of security, and third-party libraries should be scrutinised like your own code. An independent pair of eyes is one way to do that.
If you want a second opinion on a codebase, Aardwolf Security offers secure code review as a service, and you can get in touch to talk through scope. The advice above holds whether or not you ever call us.
How do you prepare for a code review?
A little preparation makes the secure code review process faster and cheaper, so work through these steps first:
- Share the repository and say which language and frameworks it uses.
- Hand over any design notes or diagrams, even rough ones.
- Tell the reviewer what the application is meant to protect, such as money, personal data or admin access.
- Name a developer who can answer questions during the review.
- Decide up front how findings will be tracked and who owns the fixes.
The NCSC also recommends tracking security issues in a register from identification through to mitigation, so findings do not get lost once the report lands.
Frequently asked questions
How long does a secure code review take?
It depends on the size and complexity of the code, so there is no honest single figure. A small web application may take days, while a large platform takes weeks. A reviewer should scope it after seeing the codebase.
Can automated tools replace a manual review?
No. Tools catch known patterns at speed, but OWASP notes they find only a small share of application security flaws. Business logic and access control need a person.
Do you need to share your source code with an outside firm?
Yes, a code review needs access to the code. Use a signed confidentiality agreement and share it through a controlled repository, ideally read-only.
Is a code review the same as a pull request review?
Not quite. A pull request review checks that a change is correct and tidy. A secure review has a narrower aim: finding ways the code could be abused. Many teams add a security checklist to their pull requests to bridge the gap.
How often should code be reviewed?
Build the secure code review process into development: review every change as part of normal development. Add a full baseline review for major releases and when the code changes hands.
Subscribe to our newsletter
Honest updates, straight to your inbox. Unsubscribe any time.
