From scope to report: how an engagement runs

Most of the risk in a security review is decided before anyone reads a line of code. If the scope is vague, the review is vague. So we fix the target first, then read it, then prove what we find. This note walks through the order we work in.

1. Intake

You send a request: what the system does, where the code lives, and roughly when you need it reviewed. We read it and reply with questions, not a quote. Typical questions: which commit, which contracts are upgradeable, which roles hold keys, what is already deployed, and what has changed since any earlier review.

A mutual NDA is available on request, and it is signed before any scope detail is shared.

2. Scope and threat model

We agree a fixed scope and a fixed version: a repository, a commit hash and a list of files. Anything outside that list is excluded, and the report says so. A review of a moving target is a review of nothing in particular.

Before the review starts we write down a threat model: the assets at stake, the actors who can touch them, and the trust assumptions the system relies on. For example: “the owner key is not compromised”, or “the oracle reports within a stated deviation”. You read it and correct it. Many design issues surface here, as assumptions nobody had written down.

For live-system work, such as web, API or cloud testing, written authorization comes first. Nothing is tested until it is signed.

3. Review

The review is time-boxed. It is manual reading, line by line, supported by tools. For smart contracts we write stateful invariant tests for the properties the system must never violate, and we use formal or symbolic methods where the code justifies the cost. Tools support the reading. They do not replace it.

A Critical finding is disclosed to you as soon as it is confirmed. It is not held for the report.

4. Draft report and walkthrough

Each finding states its location, a description, a severity with the reasoning behind it, and a recommendation. High and Critical findings come with a runnable Foundry proof of concept, so your team can reproduce the issue rather than take our word for it.

We then go through each finding with your team. This is where severity gets argued, and where context we lacked can change a rating. When it does, the report records why.

5. Fix review

Fixes are re-checked at the fix commit, against the original finding and against the invariants. A fix that closes one path and opens another is still a finding.

What you keep

• The findings, each with its severity rationale.
• Runnable PoCs for High and Critical findings.
• For smart contracts, the invariant harness, which you keep and can run in CI.
• A plain statement of residual risk: what was not covered, and why.

What a review is not

A review reduces risk. It does not certify that code is free of vulnerabilities. Key management, custody and operational security are out of scope unless named in the signed scope. Later changes are not covered. The report is delivered only to you, and publication is your decision.

If you want to start, the intake is the first step.