Authentication and session logic
Login, registration, password reset, multi-factor and token issuance — reviewed line by line, because these are the functions where a single wrong comparison is a total compromise.
Application Security
Find the vulnerability in the source.
A penetration test tells you the door is unlocked. A code review tells you why the lock was built that way, where else the same pattern was used, and what to change so it stops happening.
27Languages & runtimes
50Technology packs
SARIFPipeline-ready output
Manual+ automated analysis
Why code review finds what testing cannot
Black-box testing can only reach what is exposed. If a dangerous function is behind a feature flag that is currently off, behind an administrative role you were not given, or in a code path that only executes on the first day of the month, no amount of external testing will find it. The source has no such limits — every path is visible, including the ones that are not currently reachable but will be after the next release.
Code review is also the only assessment that finds patterns rather than instances. A test finds one endpoint missing an authorisation check. A review finds that the codebase has three different ways of checking authorisation, that two of them are correct, and that new endpoints are being written using the third. That is a far more useful thing to know, because fixing it prevents the next fifty instances rather than the one.
We combine both halves. Automated analysis provides breadth — our definition library covers 27 languages and runtimes across 50 technology packs, which catches dependency risk, unsafe API usage and configuration issues at scale. Manual review provides judgement, applied to the areas where judgement is what is needed: the authentication code, the authorisation model, the cryptography, the multi-tenancy boundary and anything handling money or personal data.
Coverage
Where we focus
Full coverage on the automated pass; manual effort concentrated where the consequences of an error are highest.
Authorisation model
How access decisions are made, whether they are made consistently, and whether the pattern is enforceable by anything other than developer discipline.
Injection and input handling
Query construction, command execution, template rendering, deserialisation and file path handling across every entry point.
Cryptography
Algorithm and mode selection, key generation and storage, randomness, and the custom encryption routine somebody wrote in 2019.
Secrets management
Credentials, keys and tokens in source, configuration, container images and version control history — the history matters, because a rotated secret that is still in the git log is still a secret.
Multi-tenancy and data isolation
Whether tenant separation is enforced at the data layer or hopefully applied in application code.
Dependency and supply chain risk
Third-party components matched against current vulnerability intelligence, with exploit probability so you can triage sensibly rather than chasing every advisory.
Business logic
The rules that make your product work, checked against the ways they could be made to work differently.
Approach
How a code review runs
Sized by codebase and by how much of it needs manual attention. Read-only repository access, and we can work in your environment if code cannot leave it.
-
01 · Understand the architecture
A session with a senior engineer: what the system does, where the trust boundaries are, what would be worst. Then we know where to spend the manual hours.
-
02 · Automated analysis
Full static analysis across the codebase, plus dependency and secrets scanning including version-control history.
-
03 · Triage
Automated output is triaged by a person. False positives are removed before you ever see them, which is the difference between a report and a tool export.
-
04 · Manual review
Deep review of authentication, authorisation, cryptography, tenancy and money-handling paths, plus anything triage flagged as worth a closer look.
-
05 · Pattern analysis
Recurring issues identified as patterns, with the root cause and the systemic fix, not fifty individual tickets.
-
06 · Report and walkthrough
Findings referenced to file and line, delivered with a session for your engineers, and exported as SARIF so they land in your existing tooling.
Run against recognised standards
- OWASP ASVSVerification requirements
- OWASP Top 10Risk categories
- CWEWeakness classification per finding
- SARIFMachine-readable output format
Deliverables
What you actually receive.
The report is the product. If it cannot be acted on by a developer and understood by a director, we have not finished.
Findings at file and line
Every issue referenced precisely, with the vulnerable code shown and the corrected version alongside it.
Pattern and root-cause analysis
The systemic issues behind the individual findings, with the change that prevents recurrence.
Dependency risk register
Third-party components ranked by exploit probability rather than by advisory count.
Secrets exposure report
What was found in code, configuration and history, with rotation guidance in priority order.
SARIF and JSON export
Loadable directly into GitHub, GitLab or your code-scanning dashboard.
Engineering walkthrough
A working session with the developers who will implement the fixes.
Is this for you?
Talk to us if any of these are true.
If none of them are, say so on the call and we will tell you honestly whether this is the right piece of work — or point you at the one that is.
Book a scoping call- You are about to launch, and testing alone will not cover code paths that are not live yet.
- A penetration test found something and you want to know where else the same mistake exists.
- You have inherited a codebase and need an honest assessment of what is in it.
- You are targeting ISO 27001 or SOC 2 and need secure development evidence.
- Your team is growing fast and security review is not yet part of how code gets merged.
How we work
Six steps, and no surprises.
The same engagement model applies to every piece of work we take on, so you always know what happens next.
01
Scope
A 30-minute call, then a written scope: what is in, what is out, what we need from you and what it costs. Nothing starts before you sign it.
02
Authorise
Rules of engagement, testing windows, escalation contacts and a signed authorisation. Out-of-hours windows where production cannot take the load.
03
Test
Automated coverage first, then manual testing where judgement is required. Critical findings are reported the day we confirm them, not at the end.
04
Report
One report a developer can act on and an executive can read, with evidence, reproduction steps, business impact and a fix for every finding.
05
Remediate
A walkthrough call with your engineers. We answer questions on the fix, not just the finding.
06
Retest
A free retest cycle to confirm the fixes hold, and a clean summary you can hand to a customer, auditor or board.
Questions
Secure Code Review — answered.
The questions clients actually ask during scoping. If yours is not here, ask it directly.
Do we have to give you our source code?
You have to give us read access to it, but it does not have to leave your environment. We can work over a screen-shared session, from a virtual machine you host, or from a read-only repository account, whichever your policy allows. Where code is handled by us, it is covered by an NDA, held only for the engagement and destroyed afterwards on request.
Is this the same as running a SAST tool?
No. Static analysis tools are one input, and we run them — they are excellent at breadth. But they produce a large volume of output, much of it false positives, and they cannot tell you whether an authorisation check is correct for your business rules. Our reports contain only findings a person has confirmed, and the manual review targets exactly the areas that tools handle worst.
Which languages do you cover?
Automated coverage spans 27 languages and runtimes across 50 technology packs, including PHP, Java, C#/.NET, JavaScript and TypeScript, Python, Go, Ruby, Rust, Kotlin, Swift, Dart, Scala, Elixir, C and C++. Manual review is language-agnostic in practice — the flawed authorisation patterns are the same everywhere, only the syntax changes.
How long does a code review take?
It depends on size and on how much needs manual attention. A focused review of the security-critical paths in a mid-sized application is typically five to ten working days. A full review of a large codebase is scoped in phases so you get the highest-value areas first rather than waiting weeks for everything.
Can you integrate this into our CI/CD pipeline?
Yes. Findings export as SARIF, which loads natively into GitHub code scanning, GitLab and most dashboards, and we can help configure automated analysis to run on pull requests so the baseline holds after we leave. Continuous scanning between manual reviews is part of what the platform does.
Will you review our git history for secrets?
Yes, and it is worth doing. Removing a credential from the current version of a file does not remove it from the history, and repository history is one of the first places an attacker looks after gaining any level of access. We report what is recoverable and in what order it should be rotated.
Next step
Get a written scope and a fixed price.
A 30-minute call, then a scope document with what is in, what is out and what it costs. No obligation, and no charge for the conversation.