How our secure code review process works

This page explains the working rhythm for our flagship Secure Code Review and related hardening work. Use it to brief stakeholders before you request a scoping call.

Stages

Scoping call

We confirm modules, threat concerns, out-of-scope areas, severity language, and the release date. You leave with a written estimate and access checklist.

Access & freeze

Read-only repository access or a tagged snapshot. Architecture notes and must-check journeys are collected before the review clock starts.

Review window

Practitioners inspect agreed paths: authentication, authorization, input handling, secrets, and sensitive business logic. Questions go to a single client channel.

Findings pack

Severity-ranked issues with file references, reproduction notes, and remediation suggestions ordered for sprint planning.

Debrief

A walkthrough with engineering owners. Disagreement is expected; we document residual risk you accept.

Optional hardening

If useful, we continue into an Application Hardening Advisory to sequence controls and configuration changes.

Artifacts you receive

Engagement letter and scope boundary
Findings pack (PDF or agreed format)
Debrief notes and residual-risk log
Optional hardening brief

What we ask of you

A responsive technical contact, a frozen branch or tag, and honesty about what will not be fixed before release. Hidden production hotfixes mid-review force a scope conversation.

Start here

Browse Consultations or go straight to Contact with your stack and window.