1. Scope and review inputs
The engagement starts with the repository, branch or commit, main entry points, deployment model and the product flows that would cause the most harm if abused. Authentication, authorization roles, tenant boundaries, administrative actions, file handling, outbound requests and external integrations are mapped before findings are prioritized.
Only authorized assets enter the scope. Temporary read-only repository access or a supplied ZIP is sufficient; production credentials, customer data and database dumps are not required.
2. Threat model and code map
The reviewer identifies actors, assets and trust transitions: anonymous to authenticated, member to administrator, tenant A to tenant B, browser to API, application to an external service, and untrusted input to an interpreter or network client.
Routes, middleware, data-access helpers, authentication/session code, deserializers, upload handlers, webhook consumers and security-relevant configuration are traced so that controls are evaluated where data is actually used.
3. Automated mapping and manual review
Automated analysis can surface dangerous APIs, dependency signals, secret patterns and missing checks. It is used as a map, not as proof. In the expert offer, a human reviewer follows data and identity across files, compares sibling endpoints and evaluates whether a control can be bypassed in the product's context.
The automated-only plan is reported separately and does not claim human validation.
4. Validation and severity
A candidate becomes a confirmed finding only when the evidence supports a credible path from attacker-controlled input or identity to impact. Validation may use a minimal request, payload, unit test or local reproduction against the submitted code. Unsafe actions against production systems are outside the process.
Severity considers exploitability and impact in the scoped application. A missing authorization check that crosses a tenant boundary is treated differently from a defensive hardening suggestion with no demonstrated impact.
5. Reporting and remediation
A finding names the weakness, affected code, preconditions, impact, reproduction steps and a concrete remediation direction. The aim is to let a developer confirm the issue and add a regression test without reverse-engineering the report.
The report also records reviewed areas and explicit limitations. The expert offer includes a debrief and direct questions about the findings.
6. Limits of coverage
A code review is evidence about a defined snapshot, not a guarantee that an application is secure. It does not replace a full black-box or infrastructure pentest, a compliance audit, operational cloud review, social-engineering exercise or review of code added after the scoped commit.
Runtime-only behavior, production configuration and external systems can change risk. When those elements matter, they require a separately authorized scope and suitable testing method.