A code review, a security review, and a penetration test are three different services with different scopes, methods, outputs, and price points. They overlap in places, but they are not interchangeable. Getting the wrong one does not just waste money - it gives you false confidence, because you checked one thing while leaving the others unchecked.
Code Review: What Is in the Code
A code review is a structured examination of source code. It looks at how the application is built: the quality of the logic, the correctness of the data flow, the architecture decisions, and whether the code contains obvious problems. A security-focused code review specifically looks for vulnerabilities in how the code is written - authentication bypass, insecure direct object references, missing input validation, SQL injection, hardcoded credentials, and similar issues that a developer introduced when writing the code.
The input to a code review is the source code. Without source code access, a code review cannot happen. This is why code reviews are most naturally done by the team building the software, or by an external reviewer with repository access. The output is typically a report listing findings by severity, with specific file and line references and recommendations for fixing each issue.
What a code review does not do: it does not test the running application. A reviewer who spots a SQL injection vulnerability in the code cannot confirm whether it is exploitable in the deployed version, or whether a WAF (web application firewall) or other runtime control partially mitigates it. Code reviews find what is written wrong; they do not confirm what is exploitable in practice.
The automated scan versus human code audit distinction matters here. Automated static analysis tools such as Semgrep, CodeQL, or Snyk can catch a class of known vulnerability patterns quickly, but they produce false positives and miss context-dependent vulnerabilities that require a human to trace the data flow. A thorough security-focused code review uses both.
Security Review: Code Plus Configuration Plus Process
A security review is broader than a code review. It covers the code, but it also covers infrastructure configuration, access controls, third-party integrations, secret management, deployment processes, and sometimes organisational factors such as who has access to production and how credentials are managed.
A security review might examine your Supabase or database row-level security policies, your environment variable management across preview and production environments, whether service role keys are exposed to the browser, how your API routes validate and authorize requests, and whether your dependency chain contains known vulnerable packages. These are questions about the entire system, not just the application code.
The output of a security review is a broader report that goes beyond code findings. It may include architecture recommendations, access control changes, configuration fixes, and process improvements. The appropriate time to do a security review is before a major launch, after inheriting a codebase from another developer, or when preparing for an enterprise security questionnaire (note: our security review is not a SOC 2 or ISO 27001 audit).
We include a security lens in our code reviews - examining row-level security, API authorization, and secret management practices alongside code quality. You can run our free automated code review as a first pass before requesting a human review.
Penetration Test: Attacking the Running Application
A penetration test - pen test - is an authorised attempt to exploit vulnerabilities in a running system. A pen tester behaves like an attacker: they probe the application as it is deployed, looking for vulnerabilities that are actually exploitable in the live environment. They do not need source code access (though having it makes the test more thorough), because they are attacking the application from the outside, the same way a real attacker would.
A pen test confirms what is exploitable, not just what looks vulnerable in code. It can find vulnerabilities that no code review would have caught - misconfigurations in DNS, exposed admin interfaces, weak TLS configurations, rate limiting gaps, or server-side issues in third-party components your code interacts with.
Pen tests are typically more expensive than code reviews or security reviews because they require skilled specialists who work methodically against a live system. Reputable testers follow a published methodology, such as the OWASP Web Security Testing Guide, a flagship OWASP project describing best practices used by penetration testers. Results are documented with proof-of-exploit evidence - screenshots, request/response logs, or captured tokens - that a code review cannot produce.
To be transparent: we do not offer penetration testing. We are not a security testing firm. If you need a formal pen test - for compliance purposes, enterprise procurement, or a regulated industry - you need a specialist provider. We can help you understand what a pen test report means and what to prioritise from its findings, but we are not the right firm to conduct the test itself.
When You Need Each One
- Code review: when you have inherited a codebase, when you want a second opinion before a launch, when you have been using AI-assisted development and want human eyes on the output, or when a developer has left and no one on the team fully understands the code. A code review is the right starting point for most small teams.
- Security review: when you are preparing for an enterprise security questionnaire and want technical groundwork first (this is not a SOC 2 or ISO 27001 audit, and we do not provide one), when you have changed your infrastructure setup significantly, or when you want a wider view than code quality alone. A security review builds on a code review and adds configuration and process.
- Penetration test: when a compliance standard or customer contract explicitly requires one (check the exact wording of the standard or contract), when you are handling high-value data that makes you an attractive target, or when you want independent proof that your security controls actually work rather than just a report saying the code looks reasonable.
The Overlap That Confuses Buyers
The three services overlap in the middle. A thorough security-focused code review will find some of the same issues a pen test would find. A pen test that includes source code access is partly doing a code review. A security review that checks running infrastructure is doing some of what a pen test does.
The confusion arises because vendors use these terms inconsistently. 'Security audit' can mean anything from a 30-minute automated scan to a weeks-long engagement. 'Code review' can mean a teammate reading code in GitHub or a structured external review with a formal report. Before engaging any service, ask for a specific description of what they examine, what access they need, what the output document contains, and whether they are following a named methodology such as the OWASP Web Security Testing Guide.
The Cost Gradient
As a rough guide for scope planning: a code review of a small to medium application typically costs less than a pen test of the same application, sometimes significantly less. A security review sits in between. A pen test from a reputable firm for a complex application can cost considerably more than either. The cost reflects the labour and expertise required, the liability the firm assumes when simulating an attack, and the depth of proof-of-exploit documentation produced.
For early-stage teams, a code review or security review is the right first investment. It finds the issues that cost the least to fix (because they are found before they become incidents) and gives you a prioritised list to work from. Understanding when a code audit is the right step can help you frame the conversation with stakeholders and budget appropriately.
If you are trying to decide which service fits your situation right now, run the free automated code review on your repository first. It takes a few minutes and gives you a first view of where the obvious gaps are, which helps frame the conversation about whether you need a code review, a security review, or a pen test referral.
Common questions
What is the difference between a code review and a penetration test?
A code review examines source code for flaws but does not test the running application. A penetration test is an authorised attempt to exploit the deployed system, and it confirms what is actually exploitable rather than what merely looks vulnerable in the code.
Does a security review count as a SOC 2 or ISO 27001 audit?
No. A security review covers code, infrastructure configuration, access controls, secret management and deployment process, but it is not a SOC 2 or ISO 27001 audit. It is useful technical groundwork before an enterprise security questionnaire.
Which should a small team buy first: code review, security review or pen test?
For early-stage teams, a code review or security review is the right first investment, because it finds the cheapest-to-fix issues before they become incidents and gives a prioritised list. Zovintra does not offer penetration testing, so a formal pen test needs a specialist provider.
Sources
- OWASP Web Security Testing Guide - OWASP, accessed 19 Oct 2026
