Work with me

An application security review

I read the codebase you are worried about, tell you what is broken, and send you the fix. Here is what that covers, what it does not, and what I need from you before I start.

In short

I combine manual code review with systematic analysis of auth and access paths.
I reproduce issues with clear evidence and focus on impact, not noise.
I deliver fixes that work in your codebase and verify them after the change.

In short

A clear security review focused on real risk in your code.
Evidence, impact and fixes you can ship with confidence.
Verification after the fix, to confirm the issue is actually closed.

Reading as

This is the process written down before the work rather than after it. Every report published here follows the same shape: scope, authorisation, findings, fixes, and an explicit list of what was not covered.

If you want to see the shape of what comes back before you email, the automated sample reads a public repository for the same three things this review starts with — and stops where a person has to take over.

Run the automated sample

A single flawless slab of machined glass standing in dark stone. Water is held perfectly level against one face of it; the stone on the other side is dry and unlit. The light stops at the glass.

What an application security review covers

The scope is agreed in writing before anything starts. Unless we agree on something different, it is this:

Included

Authentication and session handling — who the application thinks you are, and whether it actually checks.
Access control — whether a signed-in user can read or change data that belongs to someone else.
Secrets — what is committed to the repository, what ends up in the client bundle, and what is sitting in environment files.
The fix for each of the above, written against your branch as a patch or a pull request.

Not included

A penetration test. I read code and configuration; I do not attack your running systems.
Compliance certification. I cannot sign you off against SOC 2, ISO 27001 or PCI DSS.
Incident response. If you are being attacked right now, that is a different job and a different person.
A guarantee. A review finds what it finds. Nobody can promise you a codebase with nothing left in it, and I will not pretend otherwise.

Fixes, not just findings

A finding is useful only when the problem is reproducible, the fix is concrete, and the fix is checked.

Finding
What is broken, and the exact code path that makes it broken.
Reproduction
The request or steps that show it, so it is demonstrated rather than asserted.
Fix
A diff against your branch, with a note on what it changes and why.
Verification
The same reproduction, run again against the patched code.

Authorisation

I review only code I am authorised to review.

Before I read anything

I need written confirmation from whoever owns the code that they want it reviewed, and a written scope naming the repositories and environments that are in it. If you are asking about a codebase you do not own, that confirmation has to come from the owner, not from you.

Every report published on this site carries the same scope and authorisation statement at the top of it.

Turnaround

I agree the turnaround with you in writing before I start, once I have seen how large the codebase is and what is in it. I do not put a date on a repository I have not opened.

Hire me for a security review

Email me with a link to the repository — or a description of it, if it is private — what it is built on, and what you are worried about. Tell me who owns the code.

Contact address not published yet.

Deliberately not a link. An address that bounces loses the enquiry, so nothing is clickable until the real one is here.