White-box testing
Secure code review that finds what scanners miss
We combine static analysis with manual review by senior specialists and tie every finding to the file, the line and a fix.
WHY SCANNERS ARE NOT ENOUGH
WHAT SCANNERS MISS
Scanners cover volume but do not understand your business logic. A scanner is excellent at the thousand things it was told to look for, and blind to the one it was not.
TWO WAYS TO READ CODE
Every finding comes with the file, the line, the impact and a fix, so your developers can act on it straight away.
AUTOMATED SCANNING (SAST)
Covers the whole repository quickly and repeatably. Catches known patterns: injection sinks, weak cryptographic calls, unsafe functions. Cannot judge intent, so broken access control and business logic slip through. Produces false positives that someone has to sort out.
MANUAL AUDIT BY A SPECIALIST
Follows data from each entry point to where it is used, across modules and services. Checks authorisation, sessions and trust boundaries against how the application should behave. Finds logic flaws and chains of small weaknesses that no pattern match sees. Confirms each finding before it reaches your developers, so they get fewer false alarms.
WE USE BOTH
The scanner gives breadth, the reviewer gives depth, and scanner output is an input to the review, never the report itself.
BEFORE YOU START
Start with the modules that handle identities, payments and personal data. We sign an NDA before any code is shared and write the scope down before work starts.
What we do
Scoping and access
We agree the modules, languages and threats that matter most for your product, then take access to the repositories, the architecture documentation and a development environment. The scope is written down before anything starts.
Automated analysis
Static analysis runs across the agreed code, and dynamic testing complements it where the application can be run. The output is not the report; it is a map of where the reviewer looks first.
Manual review
A senior specialist traces data from every entry point to where it is used, checking authentication, authorisation, input handling, cryptography and secrets. Each automated finding is confirmed or discarded.
Report and walkthrough
We present the findings to your developers, answer their questions and, if agreed, retest the fixes.
Findings tied to code
Each issue references the file and line, explains how it can be abused and carries a severity rating.
Fix guidance
A specific fix for each finding, written for the developer who will make the change. Where several findings share a root cause, we say so.
Management summary
What was found, what it puts at risk and what to fix first, in business language for people who will not read the code.
Retest and evidence
When agreed, we retest the fixes. That gives your ISO 27001 and PCI DSS auditors the evidence they ask for.
Tell us which ones handle identities, payments or personal data, and we will propose a scope.
What is the difference between a secure code review and a penetration test?
A penetration test attacks a running system from outside and shows what is exploitable. A code review reads the source, so it also finds flaws the test never triggered: forgotten endpoints, weak access checks, insecure cryptography. They answer different questions, and they can be combined in one white-box engagement.
What do you need from us to start?
Access to the repositories in scope (read access is enough), the architecture documentation and a development environment where the application can run. A short call with a developer who knows the codebase saves time. We sign an NDA before any code is shared.
How long does a code review take, and what does it cost?
It depends on the amount of code, the languages and how many modules are in scope, so we do not quote a standard duration or price. After a short scoping call and a look at the repository structure, we send a written estimate and confirm the scope before any work begins.
Who is a secure code review for?
Software product companies and SaaS teams preparing a major release or answering an enterprise customer’s security questionnaire. Banks, fintechs and payment providers that run custom-built applications, including those under DORA or PCI DSS. Organisations preparing for ISO 27001, SOC 2 or PCI DSS that need evidence of secure development. Companies that outsource development and want an independent check of what was delivered. Teams that already commission penetration tests and want to see what a black-box test cannot.
Should we order a code review or an OWASP ASVS audit?
A code review examines the source of the modules you choose. An OWASP ASVS audit checks the whole application against a verification standard and combines testing, configuration review and code review. If an auditor or customer wants assurance against a standard, choose ASVS. If you want flaws found in specific modules, start with a code review.
Is a code review required by DORA, PCI DSS or ISO 27001?
DORA and PCI DSS ask for it directly; ISO 27001 expects it in practice. For EU financial entities, the DORA technical standard on ICT risk management (Delegated Regulation (EU) 2024/1774, Article 16) calls for source code reviews covering static and dynamic testing. PCI DSS Requirement 6.2.3 requires custom software to be reviewed before release. ISO 27001:2022 expects secure coding and security testing in development (Annex A 8.28 and 8.29).
Our certificates
Team portfolio
Where to start?
You can copy our materials only after making sure that your services are safe.
This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.