Skip to content
SecuriFii

Technical testing

Secure Code Review

A static analysis tool reads code for patterns. A reviewer reads it for intent: what this endpoint is supposed to allow, who is supposed to reach it, and whether the code actually enforces that. The first is fast and broad and produces noise. The second is slow, finds the flaws that matter most, and is the part most teams have never bought.

Discuss this
Standard
OWASP ASVS 5.0 · NIST SP 800-218 PW.7
Verification standard
ASVS 5.0.0
ASVS levels
L1 · L2 · L3
SSDF practice
PW.7
Retest
Included

Two kinds of reading

NIST’s Secure Software Development Framework draws the line cleanly. Practice PW.7 asks producers to review and/or analyse human-readable code, and it distinguishes code review, where a person looks directly at the code, from code analysis, where tools find issues either automatically or alongside a person. Both are legitimate. They find different things.

Static analysis is good at what it can trace: tainted input reaching a query, a known-dangerous function, a hardcoded credential. It is poor at anything that depends on what the code is for. A missing authorisation check on one endpoint out of forty looks, to a tool, exactly like the thirty-nine that are correct — there is nothing to match, because the flaw is an absence.

So we use both, in that order. Tooling first for breadth, with every result triaged by a person so you receive findings rather than a scanner export. Then manual review of the code that carries the risk — authentication, authorisation, session handling, input handling, cryptography, and the business logic specific to your product — verified against the OWASP Application Security Verification Standard 5.0 at the level you have chosen.

What it will ask of you

A review is only as good as the code it is given and the context around it. These four decide whether the result is worth having.

  • Read access to the actual code

    The repositories in scope, pinned to a named branch or commit so the report refers to something fixed. A zip of selected files is a review of what somebody chose to share.

  • A target level

    ASVS 5.0 has three levels, and the standard leaves the choice to you on risk. Level 2 is where it says most applications should be striving to be; deciding before we start decides what is checked.

  • An hour with the people who wrote it

    A walkthrough of the architecture, the roles and the trust boundaries. It turns days of reconstruction into an hour of conversation, and it is where the design questions surface.

  • Somebody who owns the fixes

    Findings land in your issue tracker with a file, a line and a remediation. They still need an engineer to own them and a date for the retest.

What it is used for

  • Evidence for ISO/IEC 27001 and SOC 2 that secure development is practised, not just written down.
  • Assurance on a security-critical component — authentication, payments, a multi-tenant boundary — before it ships.
  • Customer and procurement requests that name source code review or an ASVS level.
  • A triaged view of what your existing static analysis is actually telling you, and what it is missing.

Not sure this is the standard you need?

Tell us what triggered the question — a customer, an auditor, a contract clause — and we will say which of these applies, including when the answer is none of them.

Ask a practitioner

Where we come in, and where we stop

As with penetration testing, we are the assessor here — we review, report and retest ourselves, and there is no third party behind us. The impartiality rule that keeps us out of certification does not apply to technical review. What we will not do is review code we wrote, or a control we designed, and present that review as independent assurance — and OWASP does not certify anyone against the ASVS, so neither will we claim to.

Ours

  • Scope, the target ASVS level and the review plan
  • Running and triaging static and dependency analysis
  • Manual review of the code that carries the risk
  • The report, remediation guidance and the retest

Yours

  • Access to the code and the people who wrote it
  • Writing and merging the fixes, with our support
  • Deciding what is fixed first, on your risk appetite

How an engagement runs

We review a fixed commit, and the report names it. Code that changes during the review is reviewed as it stood at that commit, and the retest is run against a later one you name.

  1. 01Scope and walkthroughAgree the repositories, the commit, the ASVS level and what is out of scope. Then an hour with your engineers on architecture, roles and trust boundaries.
  2. 02Automated analysisStatic analysis and a review of third-party dependencies for known vulnerabilities. Every result is triaged by hand; false positives are discarded rather than passed on.
  3. 03Manual reviewReading the code that carries the risk — authentication, authorisation, session handling, input handling, cryptography, logging and the business logic specific to you — against the chosen ASVS level.
  4. 04ReportingFindings with file and line, severity, the reasoning, and a remediation specific to your framework. A statement of what was and was not reviewed, and which requirements did not apply.
  5. 05Remediation support and retestWe review the fixes at the commit you name and issue a retest letter, finding by finding, that you can hand to a customer or an auditor.

What you get from us

  • Executive summary written for a non-technical reader
  • Findings with file, line, severity and the reasoning behind each
  • Remediation guidance specific to your language and framework
  • Triaged static and dependency analysis results, false positives removed
  • A coverage statement: what was reviewed, at which commit, against which ASVS level
  • Retest of remediated findings and a retest letter for third parties

Common questions

We already run a SAST tool. Why pay for a review?

Because the tool finds what it can match, and the most serious flaws are often absences — an authorisation check that is not there, a business rule enforced in the interface but not on the server. We start from your tool’s output, triage it, and spend the review on what it cannot see.

Do you need all of our code?

No. We need the code that carries the risk and enough of the rest to follow data through it. Most reviews are scoped to the services handling authentication, authorisation, payments or personal data, and the report says exactly what was in scope.

Which standard do you review against?

The OWASP Application Security Verification Standard 5.0, released in May 2025, at the level you choose — with requirements cited in the versioned form ASVS asks for, so a finding still means the same thing when the standard moves.

Can you certify our application as ASVS compliant?

No, and nobody can in OWASP’s name: OWASP does not certify vendors, verifiers or software. What we provide is a report stating which requirements were verified, which failed, and which did not apply — which is what a customer asking about ASVS actually wants to see.

Is a code review a replacement for a penetration test?

No. A review reads the code; a penetration test exercises the running system, including its configuration and deployment, which the code alone does not show. They are strongest together, and the ASVS itself recommends testing led by source code and documentation over testing without them.

Ready to scope it?

Send the date you are working to and roughly how large the organisation is. You will get a reply from a practitioner with an honest read on whether the date is reachable.

Start the conversation

Related services

All services

Related insights

All insights