Skip to content

Technical Testing

Secure Source Code Review

Manual review, supported by static analysis, of the code paths that actually matter — authentication, authorisation, data handling and cryptography — with findings your developers can act on.

Tooling and standards

We use commercial and open-source static analysis to get coverage — SonarQube, Semgrep, and language-specific analysers as appropriate — then review manually, because static analysis cannot understand your business logic and generates a false positive rate that makes unreviewed output useless.

Findings are assessed against the OWASP Application Security Verification Standard and classified using CWE, with the CWE Top 25 and OWASP Top 10 as the priority lens.

Where we focus

  • Authentication and session management — credential handling, token generation and lifetime, session fixation and invalidation.
  • Authorisation — particularly broken object-level and function-level access control, which automated tools consistently miss.
  • Input handling — injection across SQL, command, LDAP and template contexts; deserialisation; file upload handling.
  • Output encoding and cross-site scripting across all rendering contexts.
  • Cryptography — algorithm selection, key management, random number generation, and data protection in transit and at rest.
  • Secrets management — hard-coded credentials, keys in source control, configuration exposure.
  • Business logic — the flaws unique to your application that no scanner has a rule for.
  • Third-party dependencies — known vulnerable components and supply chain exposure.

Where review adds value

WHERE REVIEW ADDS VALUE Commit Build Test Deploy Secrets &dependencies Static analysis(SAST) Manual review ofauth paths Configuration review
Static analysis for coverage; manual review for the authorisation and business-logic flaws no scanner has a rule for.

How we handle your code

Under NDA, on encrypted storage, with access limited to named reviewers. Review can be performed on your infrastructure if your policy requires the code never to leave your environment. All copies are destroyed at engagement close and we provide written confirmation.

How the engagement runs

  1. 1

    Scoping

    Identify the repositories, languages, frameworks and the critical code paths worth the review budget.

  2. 2

    Threat modelling

    Understand the application's trust boundaries so review effort concentrates where compromise matters.

  3. 3

    Automated analysis

    Run static analysis for coverage and to establish a baseline.

  4. 4

    Manual review

    Line-level review of security-critical paths. This is where the findings that matter come from.

  5. 5

    Validation

    Confirm exploitability where feasible, so nothing is reported on theory alone.

  6. 6

    Reporting and walkthrough

    Report plus a live session with the development team, which fixes far more than a document ever does.

What you receive

Findings with file, line reference and annotated code excerpt
CWE classification and OWASP ASVS requirement mapping
Risk rating based on exploitability in your deployment context
Corrected code examples in your own language and framework
Dependency and third-party component risk summary
Developer walkthrough session and retest of remediated findings

Frequently asked questions

Not necessarily. For a targeted review we need the security-critical modules plus enough surrounding context to follow data flow. For a full review, yes. We will tell you honestly at scoping which gives better value for your budget — usually a deep review of authentication, authorisation and data access beats a shallow pass over everything.

Commonly Java, C#/.NET, PHP, Python, JavaScript and TypeScript including Node, and Go, plus mobile in Kotlin, Java, Swift and Objective-C. If your stack is outside that, tell us at scoping and we will say plainly whether we can do it justice.

No — they find different classes of defect. Code review finds flaws that are hard to reach from outside, including logic errors and cryptographic mistakes. Penetration testing finds what is actually exploitable in the deployed configuration. Mature programmes do both.

Related services

Related regulatory frameworks

Need an independent view?

Tell us the scope, the regulator and the deadline. We will come back with an approach, a team and a fee estimate.

Request a proposal
Top