Secure code review versus a SAST scan: what each finds, and what neither does

NIST’s Secure Software Development Framework, SP 800-218, gives this its own practice. PW.7 asks software producers to review and/or analyse human-readable code to identify vulnerabilities, and its first task draws the line that matters here: code review is a person looking directly at the code, and code analysis is tools finding issues, either fully automated or alongside a person.

The framework does not rank them. It asks the organisation to decide which to use and when, then to perform the review or analysis against its own secure coding standards, and to record and triage everything found in the team’s issue tracker. One of its examples is the combination most teams should be running: a static analysis tool checking code automatically, with a human reviewing what it reports.

Executable code is a separate practice, PW.8 — testing the running software, up to and including penetration testing. That separation is a useful map. A scan and a review are two ways of reading code, and a test is something else again.

Static application security testing reads source code, or sometimes the compiled app, against a set of rules. It is fast, it is consistent, it runs on every commit, and it is good at the things that have a recognisable shape: input reaching a database call without sanitisation, a deprecated cryptographic function, a credential typed into the source.

Its limits come from the same place. It knows the code, not the purpose of the code. The OWASP Code Review Guide puts it directly: a scanner will not spot a design issue when looking at the code, where a human often can. OWASP’s mobile testing guide makes the same point from the other side — manual review is very good at business logic and design flaws, especially when the code is technically secure but logically flawed.

Then there is noise. Both guides warn that static tools produce false positives — the mobile guide adds, particularly when not configured for the target environment — and that a person has to review every result. A scan that is not triaged is not a finding list; it is a to-do list for whoever has to work out which items are real.

A reviewer reads code knowing what it is for. That is the whole difference, and it is why the flaws a review finds are so often absences: the authorisation check on thirty-nine endpoints and not the fortieth; the discount rule enforced in the interface and not on the server; the tenant identifier taken from the request instead of the session. None of these has a pattern, because each is correct-looking code missing one line.

It also lets the reviewer judge what a tool can only flag. Is this input reachable by an attacker, or only by an administrator on a private network? Is this weak hash used for passwords, or for a cache key? Triage of that kind is what turns the tool’s output from a long list into a short one.

The cost is time, which is why nobody reviews everything. A good review is scoped to the code that carries the risk — authentication, authorisation, session handling, input handling, cryptography and the business rules specific to the product — and says plainly what it did not read.

Neither reads your dependencies for known vulnerabilities by default. That is software composition analysis, a separate tool against a vulnerability database, and the SSDF lists it under a different task: verifying that third-party components comply with your requirements throughout their life, which includes regularly checking them for publicly known vulnerabilities.

Neither sees the running system. Configuration, deployment, infrastructure, secrets management in production and the way services are wired together are not in the repository, or not in the form they take when they run. That is what testing executable code is for, and why a review is not a replacement for a penetration test.

And neither proves an absence of flaws. Each covers what it covers. The ASVS, in its 5.0 release, makes the practical point: automated tools may catch the basic requirements but cannot fully verify the more complex ones, especially business logic and access control — and it recommends testing led by source code and documentation over testing without them.

The scope, pinned to something fixed: which repositories, at which commit. A report that cannot say what it reviewed cannot tell you what it missed.

The standard and the level. The OWASP Application Security Verification Standard 5.0, released in May 2025, has three levels, and says most applications should be striving for Level 2. It also asks that requirements be cited with the version — v5.0.0 followed by the requirement number — so a finding still means the same thing when the standard moves. A reviewer working to it can tell you which requirements were checked, which failed and which did not apply.

Whether the tool output was triaged, and by whom. Findings with a file, a line, the reasoning and a remediation for your framework. A statement of what was not reviewed. And a retest against a later commit, because the retest, not the report, is what shows a customer the findings were closed.