Secure Source Code Review

1.1. Define Objectives

• Agree the goals of the review (e.g. "achieve ASVS Level 2", "audit the authentication and payment modules", "pre-release security gate for a new feature").
• Identify the most sensitive components — authentication, authorisation, cryptography, payment, and data-handling logic.

1.2. Define Scope

• Identify the repositories, branches, and services in scope, and the primary languages and frameworks in use.
• Determine coverage: full-codebase review, or a targeted review of specific modules, microservices, or a single pull request.

1.3. Establish Access & Environment

• Obtain read access to source repositories, build configuration, and dependency manifests.
• Where useful, gain access to design documents, data-flow diagrams, and a runnable build to confirm findings dynamically.

1.4. Establish Rules of Engagement (ROE)

• Confirm data-handling and confidentiality requirements for the source code (a highly sensitive asset).
• Agree how and where AI analysis is performed, ensuring code is processed within approved, isolated environments and never retained or used for model training.

This is the core of our modern methodology. Our AI engine ingests and reasons over the entire codebase to detect and prioritise vulnerabilities before any manual review begins.

2.1. Codebase Ingestion & Mapping

• The full codebase is parsed into an abstract representation (ASTs and code property graphs) so the AI can understand structure, control flow, and relationships across files and modules.
• Entry points, trust boundaries, sources of untrusted input, and sensitive sinks are automatically mapped.

2.2. AI-Powered Static Analysis (SAST)

• AI models detect vulnerability classes across the whole codebase — injection (SQL, command, LDAP), Cross-Site Scripting (XSS), insecure deserialisations, broken access control, SSRF, path traversal, and weak or misused cryptography.
• Unlike signature-based scanners, the AI performs semantic analysis — it reasons about what the code intends to do, so it catches context-dependent and previously-unseen flaws rather than only known patterns.

2.3. AI Taint & Data-Flow Analysis

• The engine traces tainted data from source (untrusted input) to sink (dangerous operation) across function, class, and file boundaries, identifying exploitable paths a human might overlook in a large codebase.
• It flags missing or ineffective sanitisation, encoding, and validation along each path.

2.4. Secret & Dependency Analysis (SCA)

• Automated detection of hardcoded secrets — API keys, credentials, tokens, and private keys — across code and history.
• Software Composition Analysis identifies vulnerable and outdated third-party libraries (mapped to known CVEs) and risky licences.

2.5. AI Triage & Prioritisation

• The AI correlates and de-duplicates raw findings, then ranks them by likely exploitability and business impact — not just theoretical severity.
• Low-confidence and non-reachable findings are down-ranked or filtered, producing a clean, high-signal queue for expert review.

AI provides breadth; our specialists provide judgement. Every finding that reaches the report is reviewed by a human — this human-in-the-loop step is what separates a credible review from a raw scanner dump.

3.1. Validating AI Findings

• Reviewers confirm each AI-identified issue is real and reachable, discarding false positives so the final report is trustworthy and actionable.
• Where confidence is high but context is missing, reviewers inspect surrounding code and configuration to establish true impact.

3.2. Business Logic & Design Review

• Manual analysis of business-logic flaws that tools cannot infer — broken workflows, insecure state transitions, authorisation gaps, and abuse of legitimate functionality.
• Assessment of architectural and design weaknesses (insecure defaults, missing security controls, trust-boundary errors).

3.3. Deep-Dive Manual Audit

• Focused, expert line-by-line audit of the most critical modules identified in scoping — authentication, session management, cryptography, and payment handling.
• Hunt for subtle backdoors, logic bombs, and chained weaknesses that only emerge when a human connects several small issues.

4.1. Confirming Exploitability

• Where a runnable build is available, validated findings are demonstrated against a test instance to prove real-world impact and remove any doubt.

4.2. Proof-of-Concept Development

• For significant findings, we produce a safe proof-of-concept (e.g. a benign payload or request) and capture evidence, giving developers an unambiguous reproduction case.

5.1. Risk Assessment

• Each validated finding is scored using CVSS v4.0 and assigned a severity of Critical, High, Medium, Low, or Informative.

5.2. Reporting

• Deliverables include an executive summary of business risk and a detailed technical section for engineers.
• Every finding includes the exact file and line references, a clear explanation of the root cause and impact, and specific remediation guidance — including corrected code snippets where appropriate.
• Findings are tracked through statuses — Open, Closed, Partially Remediated, or Risk Accepted.

• We support your engineers through remediation and answer questions on the recommended fixes.
• Once fixes are applied, we re-review the affected code to verify the vulnerability is genuinely resolved and no regression has been introduced.
• For teams shipping continuously, our AI-driven analysis integrates into CI/CD pipelines to catch new issues on every pull request — turning a point-in-time review into continuous assurance.