Services
Secure Development & Code Review
Find security flaws where they start — in the source code — and give your developers fixes that fit the way they already work.
Why review the code
Testing a running application shows what an attacker can reach from the outside. Reviewing the source code shows why: the missing authorization check, the query built from user input, the secret committed to the repository. Code review finds issues that are difficult to trigger in testing and points directly to the line that needs to change.
It is most valuable for security-critical areas — authentication, permissions, payment and data-handling logic — and for teams that want to stop the same class of flaw from reappearing. Findings are written for developers, with remediation that fits your framework rather than generic advice.
What we review
The repositories, components, and focus areas are agreed before the review. Typical areas include:
Input handling
How untrusted data enters the application and whether it is validated before reaching queries, commands, file paths, templates, or outbound requests.
Output encoding
Whether data is encoded correctly for the context it is rendered in, to prevent cross-site scripting and similar injection.
Authentication logic
Credential handling, password storage, session and token management, and account recovery flows.
Authorization logic
Whether permission checks are present, consistent, and enforced on the server for every sensitive operation and object.
Secret handling
Hard-coded credentials, API keys, or tokens in source and configuration, and how secrets are loaded at runtime.
Dependency risks
Third-party packages with known vulnerabilities, unmaintained components, and risky usage of otherwise safe libraries.
Security-relevant configuration
Framework security settings, cookie and header configuration, CORS, error handling, logging of sensitive data, and debug features left enabled.
Not every area applies to every engagement. The areas tested are listed in the scope we agree with you before work starts.
How a review works
We start by understanding the application's architecture and its most sensitive paths, then combine targeted manual review of those paths with tooling that helps cover the wider codebase. Manual review concentrates on logic — authorization, trust boundaries, and data flow — where automated tools are weakest.
Before scoping, tell us the languages, frameworks, and approximate size of the code to be reviewed. We will confirm whether it falls within the stacks we can review effectively before agreeing an engagement — and say so plainly if it doesn't.
Access to code
Code is shared through a method you control, such as temporary read-only repository access, and access is removed when the review ends.
Combined with testing
Code review pairs well with a penetration test: testing confirms what is exploitable, review explains why and finds similar issues elsewhere.
What you receive
A report written for the engineers who will make the changes:
- A summary of the codebase's security strengths and the most significant risks.
- Findings that reference the affected files and functions, with risk ratings and an explanation of the impact.
- Remediation guidance that fits your language and framework, including safer patterns to reuse.
- Recurring themes worth addressing across the codebase, not only individual instances.
- A review of fixes for reported issues, where it is part of the agreed engagement.
Before the review starts
- Details of the languages, frameworks, repositories, and approximate size of the code in scope.
- Read-only access to the code through a method you choose and can revoke.
- A short architecture overview or walkthrough, and a developer contact for questions.
Please don't send credentials, keys, or vulnerability details through the website form. We agree a secure channel once an engagement is confirmed.
Engagement process
From first conversation to verified fixes
A simple, predictable process. Actual timing and deliverables depend on the scope we agree.
Swipe to see all 6 steps
FAQ
Secure Code Review: common questions
Can't find your answer? Ask us directly, or browse every question in the full FAQ.
Tell us your stack during the initial discussion. We'll confirm whether we can review it effectively before any engagement is agreed, rather than accepting work outside our expertise.
No. Reviews are usually focused on the components and paths that matter most for security. We agree the repositories and focus areas during scoping and only need access to what is in scope.
Code is treated as confidential, accessed only through the method you provide, used only for the review, and access is removed at the end of the engagement. Specific handling requirements can be agreed in writing before work begins.
Want your code reviewed for security?
Tell us about your application, API, or software security requirements. We can discuss the appropriate scope and next steps.
What happens next
- 01We review your enquiry and reply by email
- 02An initial discussion about your application and goals
- 03A written scope — nothing is tested until it's agreed