Access control
Ownership and tenancy checks on every state-changing path, IDOR and BOLA at source level, role and permission enforcement, and the endpoints where the check exists in the middleware but not in the handler.
Services · Source-level analysis
Secure
Secure
code review.
Static analysis tools are good at the classes with a shape: an unescaped sink, a known-bad function. They are weak precisely where breaches happen, because no tool knows that this endpoint should have checked ownership and does not. That judgement is what a review buys you.
01
Who this is for
Built for teams who would rather find it before it ships.
01
Teams drowning in scanner output
Thousands of findings, mostly noise, and no way to tell which three matter. We review what the tool flagged, assess exploitability in your actual code path, and separate the real issues from the pattern matches.
02
Products at a design inflection point
A new authorisation model, a payments flow, a tenancy change. Reviewing the design and the implementation together is dramatically cheaper than discovering the flaw in a penetration test six months after it shipped.
03
Companies preparing for diligence
Investors and enterprise buyers increasingly ask about secure development practice, not just about test results. A source-level review with documented remediation is stronger evidence than a scan report.
02
Coverage
What we actually look for.
Weighted toward the classes automated tools consistently under-report, because those are the ones that need a human reading the logic.
Injection classes
SQL and NoSQL injection including dynamic query construction, command injection, SSTI, and unsafe deserialisation. We trace from source to sink rather than flagging a function name.
Authentication and session
Registration, login and reset flows, token generation and validation, JWT handling and algorithm confusion, session fixation and invalidation, and MFA enforcement gaps.
Cryptography and secrets
Algorithm and mode selection, key management and rotation, randomness sources, password storage, and credentials committed to the repository or leaked into logs and error paths.
Server-side request and file handling
SSRF including the cloud metadata case, path traversal, upload validation and storage, and XML processing with external entities enabled.
Dependencies and configuration
Known-vulnerable dependencies assessed for whether the vulnerable path is actually reachable in your code, plus framework configuration, debug settings, and error handling that leaks internals.
03
How the engagement runs
Six steps, every time.
The same disciplined sequence on every engagement, so you know what is happening and when, and so nothing reaches your report unproven.
01
Scope
A conversation, not a form. We agree the boundary, the accounts, the timing and the escalation contact, and it is enforced technically.
02
Map
We build the real picture of what is reachable, which is almost always larger than the inventory you were given.
03
Prove
Every candidate finding is actively validated against a baseline. Anything that fails is demoted or dropped before it reaches you.
04
Chain
Confirmed findings are linked into the routes an attacker would walk. One finding is a ticket. A path is a breach.
05
Report
Evidence, reproduction steps, prioritised remediation and detection content, as SARIF, JSON and HTML mapped to MITRE ATT&CK.
06
Retest
You fix, we verify, and the report is updated. A finding is not closed because someone said it was.
04
Straight answers
The questions we actually get.
What do you need from us?
Read access to the repository, a short walkthrough of the architecture and the authorisation model, and a note on which areas concern you most. Where a runnable environment is available we will use it to confirm exploitability.
Which languages do you cover?
Web and API stacks: JavaScript and TypeScript, Python, Java, C#, Go, PHP and Ruby. If your stack is outside that, say so during scoping and we will tell you honestly whether we are the right fit rather than learning on your budget.
Do you review the whole codebase?
Rarely, and it is usually the wrong use of the budget. We prioritise authentication and authorisation, anything handling money or personal data, external input boundaries, and recently changed code. Coverage is agreed explicitly and stated in the report.
Is this instead of a penetration test?
No, they see different things. A review finds flaws with no external symptom and explains root cause. A penetration test proves what an attacker reaches without your source. Teams that can do only one usually get more from the test first, and we will say so.
How do you handle our source code?
Under NDA, on encrypted storage, and never submitted to third-party services for analysis. Access is removed and working copies destroyed at the end of the engagement, and the retention terms are written into the agreement.
Start here
Scoping is
Scoping is
a conversation.
Tell us what you are protecting and what worries you. You will get an honest answer on whether this engagement is the right next step, who would run it, and what it would cost, before you commit to anything.