Home/Services/Security review

Security review

Architecture, code and configuration, read by someone actively looking for the way in. A test tells you what is broken today. A review tells you what the design will keep producing.

Plan a review See what I test

What gets tested

Architecture

Trust boundaries, and what crosses them. Where authentication happens and where it is merely assumed, what one compromised component reaches, and which of your defences depend on a client behaving.

Code

The paths that matter rather than every line: authentication, authorisation, session handling, input handling at the edges, cryptography, and anything touching money or personal data.

Configuration

Cloud accounts, identity and permissions, network exposure, secret handling, logging, and defaults nobody revisited after the proof of concept became production.

Dependencies

What you pull in, what it pulls in, and which of it is actually reachable from your code. Reachability is the difference between a real problem and a long list.

How it runs

  1. 01

    Scope

    A call to work out what matters, then read access to what I need. You get a written scope and a fixed price before anything starts.

  2. 02

    Read

    Time in the material with the question held open the whole way through: how would I get in, and what would that reach. Questions go to your engineers as they come up rather than piling into the report.

  3. 03

    Report

    Findings ordered by what I would change first, each with where it lives, why it matters here specifically, and the change I would make.

  4. 04

    Talk it through

    A session with the people who have to act on it. A review lands badly as a document alone, because most of its value is in the reasoning behind each finding.

What you get

  • A written scope and a fixed price, agreed before the work starts.
  • Findings ordered by what to change first, each pinned to where it lives.
  • The reasoning behind each one, not just a verdict.
  • A separate list of what I looked at and considered sound.
  • A working session with your engineers to go through it.
  • Straight answers on which findings you can reasonably decide to live with.

What this is not

  • Not an audit against a standard. If you need to be measured against a named framework, this is not that engagement.
  • Not a full line-by-line read of the codebase. Scope buys depth in the places that carry risk; claiming complete coverage of a large codebase would be a lie.
  • Not a substitute for testing. A review reads intent, a penetration test finds out what the running system actually does. They catch different things.
  • Not a rewrite. I will tell you what I would change and why. Making the change is yours.

Common questions

When is the right moment for this?

Twice, ideally. Once at design, while changing your mind is still cheap, and once before you ship, when there is something real to read.

A review after launch still pays, it just arrives with more sunk cost attached.

Do you need access to our source code?

For a code review, yes: read access to the repository, and preferably the ability to run it. For an architecture review, diagrams and a conversation with whoever built it can be enough.

Read-only access is fine. I never need write access.

What languages and stacks do you read?

PERSONALISE: list the languages, frameworks and cloud platforms you are genuinely comfortable reviewing, and say plainly what you are not. Naming the boundary is worth more here than a long list.

How is this different from a penetration test?

A test attacks the running system from outside and finds what is exploitable today. A review reads the design and the code and finds what the system will keep producing.

A test finds the bug. A review finds the reason there will be another one.

Can you review someone else’s work?

Yes, and it is a common reason to call. Reviewing an outsourced build or an acquisition target is the same work with a different reader.

I will report what I find. I will not shape the wording to help either side of a negotiation.

Start a conversation

Tell me what you are building,
and what you are unsure about.

[email protected]

Replies within one working day. Dutch or English.

Other services