Source code review services

Source code review services are easy to confuse with code scanning tools. This page covers the service: a person reviews your code for security flaws and writes up findings. The table lists providers whose own pages state code review, in A to Z order with no ranking. Each row shows the facts we could source, and "Not published" where a provider says nothing. Facts were checked on 9 November 2026.

What does a source code review cover?#

A source code review is a security assessment in which a reviewer reads your code, follows data from input to output, and reports flaws with the file and line. Typical targets are authentication, access control, input handling, cryptography and secrets in the repository. The OWASP Code Review Guide is an OWASP lab project that documents the practice.

A review sees what a running test cannot, such as dead code paths and checks that exist in the UI only. It does not see deployment settings or third-party services. A web application penetration test covers those from outside.

How does manual review differ from SAST and AI code review tools?#

Manual review is a person reading code. SAST is an automated scan. AI code review tools are a newer kind of automated reader, and their claims vary by vendor, so test them on your own repository.

OWASP lists what SAST does well: tools "can be run on lots of software, and can be run repeatedly" and catch "certain well-known vulnerabilities" such as buffer overflows and SQL injection. It also lists limits. SAST tools can "automatically identify only a relatively small percentage of application security flaws", are weak at authentication and access control problems, produce "high numbers of false positives", and find it "difficult to 'prove' that an identified security issue is an actual vulnerability."

Who needs a source code review, and when?#

You need one when you ship code that guards money or private data, when you take over a code base, or before a major release. A buyer's security questionnaire can also ask for it. Code review is often the right choice when a pentest finds a pattern and you want to find every instance.

What should you ask code review providers?#

Ask for these answers in writing before you sign.

Our guide questions to ask a pentest provider has the longer list.

What drives the price of a code review?#

Price follows the amount of code in scope, the number of languages, the depth of the review, and the retest terms. Many providers quote after scoping. The "Published price" column shows a figure only where a provider lists one, so a blank price is a missing fact. See penetration testing cost for the ranges we sourced.

How do you read the table?#

Providers appear in the table when their own pages state code review. The Web, API, Cloud and AI apps columns show "yes" only where the provider names that scope, and "unknown" means the pages we read did not say. The table does not list languages. Ask each provider, and compare the answer with your stack. Click a provider name for its sources and check date, and read how we compare for the rules.

Which scoping mistakes cause rework?#

The main mistake is to scope by repository and not by risk. A large repository holds many libraries nobody should review. Name the modules that handle authentication, payments and tenant data, and list the vendored code that is out of scope. A second mistake is to skip build instructions, since reviewers then cannot run tests or tools. Also check the API penetration testing page if the review targets an API.