Read by a person, not a scanner.
Static analysis finds patterns. It cannot tell that a permission check is missing on one endpoint, because there is nothing there to detect.
We read your source code specifically for security flaws — access control, authentication, data handling, secrets. One to three weeks depending on size. Every finding comes with the exact location and a suggested fix.
Updated August 2026
The flaw is usually something absent.
Which is exactly what static analysis cannot detect.
The most serious flaws are usually something absent.
Static analysis is good at finding dangerous patterns — an unsafe query, a weak algorithm. It is poor at noticing that one endpoint out of forty never checks whether the requesting user owns the record, because there is no bad code to flag. There is simply no code.
A person reading with intent finds those, and they are consistently the most damaging category. Missing authorisation is how one customer ends up seeing another's data.
It pairs well with penetration testing rather than replacing it. Testing shows what is reachable from outside; code review shows what is wrong inside, including paths a tester would not reach.
What we look for.
Missing authorisation
Endpoints that check who you are but never whether the record is yours. The most common serious finding.
Authentication handling
Sessions, tokens, password reset, timeout. Where the damaging mistakes concentrate.
Secrets in the repository
Keys and credentials committed, including in history where people forget to look.
Input handling
Injection paths, unsafe deserialisation, template rendering with user data.
Sensitive data in logs
Card numbers, tokens and personal data written to logs many people can read.
Dependency risk
Known vulnerabilities, and packages nobody maintains any more.
Cryptography use
Not the algorithms, which are usually fine — how they are used, which often is not.
A fix per finding
File, line, and suggested change. So it becomes a pull request rather than a discussion.
Code review, or penetration testing?
They find different things. Most teams should do both, and this one is usually cheaper.
| Secure code review | Penetration test | |
|---|---|---|
| Perspective | Inside — reading the source | Outside — attacking the running app |
| Missing authorisation checks | Yes — the strongest case for it | Only where reachable |
| Hardcoded secrets | Yes | Rarely |
| Unreachable but dangerous code | Yes | No — cannot be reached |
| Configuration and deployment flaws | Partly | Yes |
| Proves exploitability | No — shows the flaw | Yes — demonstrates the attack |
| Needs source access | Yes | No |
How we read.
Authorisation absent on an endpoint. No scanner finds it, because there is nothing to find.
Our founder was CTO at two payment companies. Code near money gets read accordingly.
File, line, and the change. It should become a pull request, not a conversation.
When to review.
Before handling money or personal data
Cheaper to find now than after a disclosure.
You inherited a codebase
An acquisition, or an agency handover. You cannot trust what you have not read.
A test found something worrying
If one authorisation check was missing, review whether the others are there.
Not as a substitute for tests
If nothing is verified automatically, fixing that first will do more good. We will say so.
How we work.
We find where risk sits
Authentication, payments, personal data. We read those thoroughly rather than everything shallowly.
We run tooling in the background
It catches the obvious patterns and frees the reading for what tooling misses.
We read with intent
Following how data moves and where checks should be but are not.
We verify each finding
In the code, with the path shown. Nobody should chase a theoretical issue.
We rank by real impact
What this actually allows in your application, not a generic severity number.
We give a fix, not a lecture
File, line, suggested change — so your team opens a pull request rather than a debate.
Frequently asked.
5 questions answered. Still have one? Reach out.
Scanning finds dangerous patterns that exist in the code. It cannot find something that is absent — and a missing authorisation check is exactly that. There is no bad code to flag, just an endpoint that never verifies the record belongs to the requester. That category is consistently where the most serious findings come from, and it needs a person.