This is the working structure I use for a direct security review. The exact scope, review window, and deliverables are agreed before the review begins.
1. Scope and review plan
I start from the repository or reviewed commit, the components in scope, deployment context, threat model, and expected deliverables. Architecture notes, tests, documentation, and known assumptions help identify the boundaries that deserve the most attention.
The result is a focused review plan: what is included, what is excluded, which invariants matter, and how findings will be communicated.
2. Manual review
I trace the system through its proof, verifier, transcript, cryptographic, and implementation boundaries. The review follows assets, invariants, state transitions, malformed inputs, trust assumptions, and adversarial paths rather than relying on isolated pattern matching.
Automated tools may support the investigation, but they do not replace manual reasoning about the protocol’s intended security properties.
3. Fix verification
After findings are discussed, I review the agreed remediation changes against the original failure mode and the affected paths. The review window and patch scope determine the exact verification surface.
4. Final report
The final report records each finding’s impact, affected code, technical reasoning, reproduction details where applicable, and remediation guidance. It is written for the engineering team that must understand and close the risk.
Questions about scope, assumptions, or the review process stay in the same technical conversation throughout the engagement.