Penetration Testing
Secure Code Review (Source Code Security Review)
A secure code review is a manual read of your application code, backed by static analysis, that finds security flaws at their root before release. It catches logic and authorisation bugs that black-box testing cannot reach. As a PCI SSC-approved QSA company, we map findings to PCI DSS 6.2.3 and 6.2.4 and ISO 27001 A.8.28.
Prefer to talk? Call +44 161 523 5276
- Manual review plus static analysis
- Supports PCI DSS 6.2.3 and 6.2.4
- Root-cause findings for developers
Trusted by banks, payment providers and global brands
On this page
- Secure code review services: what's included
- What does a secure code review look for?
- Manual secure code review vs static code analysis (SAST)
- How much does a secure code review cost?
- SAST, DAST and penetration testing: how they fit
- How is a secure code review carried out?
- Why choose Sovereign Secure for secure code review?
- Frequently asked questions
Overview
What is a secure code review?
The short answer
A secure code review is a manual security review of your application’s source code, backed by static code analysis (SAST), that finds flaws at their root before release. It covers authentication and authorisation logic, input handling, secrets, cryptography and third-party dependencies, with each finding tied to a file and line and mapped to OWASP and PCI DSS 6.2.
A secure code review, sometimes called a source code security review, examines your application source directly to find security flaws at their source. Working from the code gives visibility that external testing cannot: the full logic of authentication and authorisation, how input is handled everywhere it is used, and issues buried in paths that are hard to reach from outside.
We combine manual review, where an experienced tester reads the security-critical parts of the code, with static analysis tooling that covers the codebase at scale. Manual review finds the logic and design flaws; tooling catches the patterns and known-bad constructs. Together they give both depth and breadth. We use the OWASP ASVS as the measure of what secure code should do, so each finding maps to a recognised requirement. A threat modelling output, if you have one, shows reviewers which code enforces the controls that matter most.
Source code review is the strongest complement to a web application penetration test or API penetration test. It supports PCI DSS Requirement 6.2.3, which requires bespoke and custom code to be reviewed before release, the secure-coding expectations of 6.2.4, and ISO 27001:2022 Annex A 8.28, and, alongside testing, the security testing control in Annex A 8.29 covered on our ISO 27001 penetration testing page. New to testing? Our guides to what penetration testing is and the types of penetration testing show where a code review fits.
What's included
Secure code review services: what's included
A code review blends targeted manual analysis with static tooling.
- 01
Manual security review
An experienced tester reads the security-critical code paths, focusing on authentication, authorisation and data handling.
- 02
Static analysis
Tooling run across the codebase to surface known-bad patterns and vulnerable constructs at scale.
- 03
Authentication and access logic
Close review of how identity, sessions and permissions are enforced in code.
- 04
Input and output handling
Analysis of how untrusted input is validated, encoded and used, to find injection and related flaws.
- 05
Secrets and configuration
Detection of hardcoded credentials, keys and insecure configuration in the codebase.
- 06
Dependency review
Assessment of third-party libraries and components for known vulnerabilities and unsafe usage.
- 07
Fix-ready findings
Each issue explained at the code level, with the fix, so developers can act quickly.
- 08
Retest
A review of remediated code, scoped in your fixed-price proposal, with the report updated to show findings closed.
What we test for
What does a secure code review look for?
Coverage focuses on the flaws that live in the code and its dependencies. The OWASP Secure Code Review Cheat Sheet gives a public summary of the same areas if you want to brief your developers before a review. Dependency review is one part of wider supply chain security.
Injection and input handling
Untrusted input used unsafely anywhere in the code.
- SQL and NoSQL injection at the query layer
- Command and code injection
- Cross-site scripting from unsafe output
- Missing or inconsistent input validation
- Unsafe deserialisation
Authentication and authorisation
Identity and access logic that fails to enforce the intended controls.
- Flawed authentication logic
- Missing or inconsistent authorisation checks
- Insecure session and token handling
- Privilege checks bypassable in code
- Insecure password and credential handling
Secrets and configuration
Sensitive values and insecure settings embedded in the codebase.
- Hardcoded credentials and API keys
- Secrets committed to version control
- Insecure default configuration
- Debug or verbose modes left enabled
- Weak or misused cryptography
Cryptography
Incorrect or weak use of cryptographic functions.
- Weak or deprecated algorithms
- Insecure key management
- Predictable random values
- Improper certificate handling
- Misuse of encryption libraries
Dependencies and components
Risks introduced by third-party code.
- Known vulnerabilities in libraries
- Outdated or unmaintained dependencies
- Unsafe use of framework features
- Missing integrity checks
- Overly broad third-party permissions
Error handling and logging
How failures and sensitive events are handled in code.
- Sensitive data in error messages
- Sensitive data written to logs
- Unhandled exceptions exposing detail
- Insufficient logging of security events
- Information leakage through responses
Manual secure code review vs static code analysis (SAST)
Manual review and static code analysis answer different questions, and a useful secure code review uses both. SAST tools scan the whole codebase quickly for known-bad patterns; a reviewer reads the code that matters most and judges whether the logic is safe.
| Aspect | Manual secure code review | Static code analysis (SAST) |
|---|---|---|
| How it works | A reviewer reads security-critical code paths and traces how data and permissions flow | A tool parses the code and flags patterns that match known weakness rules |
| Finds well | Broken authorisation, business logic flaws, insecure design and misuse of frameworks | Injection patterns, unsafe functions, hardcoded secrets and known-bad constructs |
| Struggles with | Covering every line of a very large codebase | Logic and access-control flaws, and code paths it cannot fully trace |
| False positives | Few, because each finding is reasoned through | Common, so output needs triage by someone who understands the code |
| Speed | Days to weeks, depending on scope | Minutes to hours per scan, so it suits every build |
| Best use | In-depth review of critical components before release | Continuous checks in the CI/CD pipeline between reviews |
PCI DSS Requirement 6.2.3.1 adds that manual reviews must be carried out by someone other than the code’s author who knows secure coding techniques, which an independent review provides.
How much does a secure code review cost?
The cost of a secure code review follows the number of days a reviewer needs, and that depends mainly on how much code is in scope and how deep the review goes. Our code review services are quoted once the repositories, languages and depth of review are agreed.
| Cost driver | Why it changes the price |
|---|---|
| Size of the codebase | More lines of code and more components mean more to read and trace |
| Languages and frameworks | Each extra language or framework brings its own patterns and pitfalls |
| Full or focused review | Reviewing only security-critical areas, such as authentication and payments, takes fewer days than reviewing everything |
| Documentation and developer access | Architecture notes and a walkthrough from your developers shorten orientation |
| Pairing with a penetration test | A combined white-box test reuses the same understanding of the application |
| Review of remediated code | Checking the fixes adds a short second pass |
Our penetration testing cost guide shows the published UK day rates we reviewed and how days turn into a price.
SAST, DAST and penetration testing: how they fit
They test the same application from different angles. SAST reads the code without running it, DAST (dynamic application security testing) probes the running application from outside with automated requests, and a penetration test adds a person who chains findings together and tests business logic. A secure code review is the manual counterpart of SAST, just as a penetration test is the manual counterpart of DAST. A review can also feed white box penetration testing, where testers use the code to confirm suspected flaws against the running application.
If you sell connected products or software into the EU, the EU Cyber Resilience Act requires effective and regular security tests and reviews, and code review findings and their fixes form part of that evidence.
| Method | What it looks at | When it usually runs | What it finds best |
|---|---|---|---|
| SAST | Source code, without running it | On every commit or build | Known-bad code patterns, early, when they are cheapest to fix |
| Secure code review | Source code, read by a person | Before major releases and for critical components | Logic, authorisation and design flaws at their root |
| DAST | The running application, from outside | In test environments, often on a schedule | Configuration issues and common injection flaws that show at runtime |
| Penetration testing | The running application, tested by a person | At least annually and after significant change | Exploitable chains, access-control and business logic flaws |
How it works
How is a secure code review carried out?
- 1
Scoping
We agree the repositories, languages, components and depth of review, and fix the price.
- 2
Orientation
We work with your developers to understand the architecture and the security-critical areas.
- 3
Review
Manual review of critical code paths, backed by static analysis across the codebase.
- 4
Reporting
A report with findings tied to specific code locations, CVSS ratings and clear fixes.
- 5
Debrief
A walkthrough with your developers covering the findings and remediation.
- 6
Retest
We review the remediated code and reissue the report showing findings closed.
When a review is paired with a web application or API test, the test follows the five stages of penetration testing: planning and reconnaissance, scanning, gaining access, maintaining access, and analysis and reporting.
Why Sovereign Secure
Why choose Sovereign Secure for secure code review?
Established in 2012, we deliver PCI, ISO and Cyber Essentials work for banks, payment processors, card manufacturers and fast-growing companies.
Read client testimonials →- Manual review by experienced testers, not just a tool report handed over raw.
- Findings tied to exact code locations with the fix, so developers can act fast.
- Supports PCI DSS 6.2.3 and 6.2.4 and ISO 27001 A.8.28 secure-development requirements.
- Strongest paired with a web application or API test for full coverage.
FAQ
Frequently asked questions
Can't find your answer? Call us on +44 161 523 5276 or send us a message.
How is a code review different from a penetration test?
A penetration test attacks the running application from the outside. A code review reads the source directly, so it finds flaws in logic and hard-to-reach paths that external testing may never trigger. The two are complementary, and the most thorough assurance comes from doing both.
What languages and frameworks do you review?
We review the common web, mobile and back-end languages and frameworks. We confirm coverage for your specific stack during scoping and match reviewers to your technology.
Do we have to hand over our source code?
Yes, review requires access to the code, which can be provided through a read-only repository grant or a secure export. We handle your code confidentially, we are ICO registered and ISO 27001 certified, and we agree handling terms in the engagement.
Is static code analysis enough on its own?
No. Static code analysis is fast and suits every build, but it matches patterns rather than understanding intent, so it misses broken authorisation and business logic flaws and raises false positives that need triage. Run it continuously, and add a manual secure code review before major releases and for critical components such as authentication and payments.
Is this only manual, or do you use tools?
Both. Static analysis tooling gives breadth across the whole codebase; manual review by an experienced tester gives depth on the security-critical parts. We verify tool output by hand so you are not left with a list of false positives.
Does this satisfy PCI DSS 6.2.3 and 6.2.4?
Requirement 6.2.3 requires bespoke and custom software to be reviewed before release to find and correct coding vulnerabilities, and 6.2.3.1 requires manual reviews to be done by someone other than the code’s author who knows secure coding. Requirement 6.2.4 expects engineering techniques that prevent common attacks. An independent secure code review is strong evidence for both, and as a QSA company we write it so it aligns with your assessment. It also supports ISO 27001 A.8.28.
How long does a code review take?
It depends on the size of the codebase and the depth agreed. A focused review of critical components is often around one to two weeks; a large application takes longer. We confirm the timeline in the fixed-price proposal.
How much does a secure code review cost?
The price follows the size of the codebase, the number of languages and frameworks, and whether we review everything or focus on security-critical components such as authentication and payments. Our penetration testing cost guide explains how days are estimated, and you can request a code review quote with a fixed price.
Last reviewed October 2026 by the Sovereign Secure assessment team.
Related services
- Web application testingWeb application penetration testing in the UK: manual OWASP Top 10, access-control and business logic testing by a PCI QSA company. Get a quote.
- API penetration testingAPI penetration testing services for REST, GraphQL and SOAP web services, tested against the OWASP API Security Top 10 by a PCI QSA company. Get a quote.
- ISO 27001 penetration testingISO 27001 penetration testing mapped to Annex A 8.8 and 8.29: what auditors ask for, how often to test and an audit-ready evidence pack. Get a fixed quote.
- Penetration testing costPen test cost in the UK for 2026: published day rates and penetration testing price ranges by test type, what drives cost, and how to get a fixed quote.
- Penetration testing quoteScope your test types and asset counts and get a fixed-price penetration testing proposal.
Free consultation
Talk to an assessor
We aim to reply within one working day, and send a fixed quote once your scope is confirmed.
- PCI SSC-approved QSA, QPA, CPSA, P2PE and 3DS assessors
- IASME-licensed Cyber Essentials certification body
- Clients across the UK, US, Europe, Middle East and Asia since 2012
“The Cyber Security Services were delivered on time and price was competitive.”
Call +44 161 523 5276
Email [email protected]