What a Manual Secure Code Review Finds That Your SAST Pipeline Reports as Clean

Your SAST pipeline is green. Your last app pentest came back with a handful of mediums and nothing critical. Then a tester on a scoping call suggests a secure code review, and the fair question is what a human reader adds to a pipeline you already pay for.

Your scanner is not failing. Static analysis does work no human can match on speed or frequency, and it does it on every commit. The two are looking for different classes of problem. A scanner matches patterns across your whole codebase. A reviewer reads how your app decides things: who is allowed to touch which record, what the code treats as already validated, whether a valid token means the right person.

One of those costs money per engagement and the other costs money per year, so the difference is worth knowing in specifics.

What static analysis is good at

Most teams asking about secure code review already have SAST running and working. Nothing here is an argument against it.

Static analysis wins on coverage. It reads every file, including the ones nobody has opened in two years and the ones a reviewer would deprioritize. It wins on regression, because a class of bug you fixed in March stays fixed while the rule that caught it keeps running. It runs on every pull request at close to zero marginal cost. And it is dependable on known patterns: injection sinks reached by unsanitized input, unsafe deserialization, weak hash functions, dependencies with published CVEs. Modern secret scanners catch plainly hardcoded credentials, and a reviewer who spends your engagement grepping for API keys is wasting your money.

A secure code review does not replace any of that. What the list leaves out is everything that depends on knowing what your app is supposed to do.

What a reviewer reads that a pattern does not match

A rule engine checks your code against a description of a known bad shape. An application security code review checks it against your app's intent. Most of the findings a buyer cares about live in the second category.

Authorization decisions

This is the biggest gap and the one that surprises buyers most. A scanner can tell you a query is parameterized. It cannot tell you the query should have been filtered by tenant, or that the endpoint checks whether you are logged in and never checks whether the record is yours.

Broken access control took the top spot in the OWASP Top 10 in 2021 and held it again in the 2025 update, and it stays there for a structural reason: correct behavior is specific to your data model. An insecure direct object reference is not a syntax error. It is a missing comparison, and it only reads as missing if you know which two values were supposed to be compared. A reviewer builds that model from your code, then checks the routes in scope against it.

We have written separately about the authorization and authentication flaws that come up most often in testing. Static analysis catches some of them, and a well-written custom rule catches more. The ones that turn on application context are the ones a reviewer is there for.

Trust boundaries

Every app draws a line between input it validates and input it assumes is already safe. That line is rarely written down. It lives in a developer's memory of which service calls which, and it moves as the system grows.

A reviewer maps it. The findings usually look like a validation routine that runs on the public API but not on the internal one a partner integration now reaches, or a queue consumer that trusts its payload because there was only ever one producer. Static analysis sees both paths reaching the same sink and, if the sink is safe, reports both clean.

Session and token handling

Whether a token is signed is checkable. Whether it is signed correctly is a reading problem. Algorithm confusion, an expiry validated in one middleware and skipped in another, a refresh flow that reissues without re-checking revocation, a reset token built on a predictable seed: these have right and wrong answers that look identical to a rule engine.

Our breakdown of JWT vulnerabilities covers the mechanics. What a review gives you back is which of them your implementation is actually open to.

Secrets management, past the obvious cases

Scanners find the key committed in plaintext. A reviewer finds the more common version: a secret stored correctly in a manager, then loaded into an environment variable that child processes inherit and that turns up in crash dumps, logs and container inspection, or scoped to a role far broader than the one function that needs it, or still valid in git history after being rotated in production.

Automate the tooling side of this. Secret-scanning tooling earns its place in the process and we run it. The judgment side, including moving credentials out of .env files into something with a real scope model, is what a review adds.

Multi-tenancy and data isolation

If you run a shared-tenant platform, this finding class can justify the engagement on its own. Tenant isolation is usually enforced in a handful of places and assumed everywhere else. It breaks in background jobs, export routines, admin tooling, cache keys and search indexes, because those were written after the isolation pattern was established and did not inherit it. A reviewer traces tenant identity from request to storage and finds where it stops being carried.

Logic and state

Order-of-operations problems do not look like bad code. A refund that can be issued twice if two requests arrive together. A multi-step flow where step three can be called without step two. A quota decremented after the action instead of before. Every line is correct and the sequence is not. Runtime testing finds plenty of these, and a good tester will go looking for them, but it only finds the ones whose paths and state transitions get exercised during the engagement. Reading the code reaches the rest.

Cryptography in practice

A pipeline flags a weak cipher. A reviewer catches the strong cipher running in a mode that leaks structure, an IV reused across records, a key derived from something guessable, or a secret comparison that returns early and leaks timing.

Triage, in both directions

Practitioners ask constantly how to tell which scanner findings are real, and it is a fair problem. A backlog of a few hundred unresolved static analysis alerts is not a working security program, so teams learn to suppress by rule instead of by case.

That habit produces the failure mode worth naming, and there is good measurement of it. An empirical study presented at ISSTA 2024 ran five static analysis tools against 815 commits that introduced real, exploitable vulnerabilities across 92 C and C++ projects. A single tool produced warnings in the vulnerable functions of 52% of those commits. All five together reached 78%, and 22% went undetected, which the authors attribute to the limits of the tools' rules. At least 76% of the warnings raised in vulnerable functions were irrelevant to the vulnerability that was actually there.

Those figures come from C and C++ code, so read them as a shape rather than a forecast for your stack. The shape is the useful part. Tools catch a majority of a certain class of bug, they miss a real minority, and most of what they report even in vulnerable code points somewhere else.

A security code review that starts from your existing SAST output can confirm which flagged findings are actually reachable in your deployed configuration, which closes tickets rather than opening them. They can tell you whether a suppressed rule was suppressed for a reason that still holds. And they can separate a clean report that reflects a real absence of the bug from one that reflects a rule nobody ever wrote for your architecture.

Vulnerability triage of this kind can leave a team with a shorter backlog than it started with, depending on how much of the existing output turns out to be reachable.

That is also how our own reviews run. Automated static analysis feeds the process, and a reviewer owns the analysis and the conclusions, so tool output does not become a finding on its own.

Where "white box penetration testing" fits

Buyers searching for white box penetration testing, or asking whether to move from black box to grey box scope, are asking a scoping question: should the testers have the code?

Two different things get bundled into that question.

Giving a pentester credentials, architecture documentation or read access to a repository changes how a penetration test is run. The tester still works against a running system, still proves exploitability, still reports what an attacker can do. Code access gives that work more context and lets the tester target it better.

A secure code review is a separate engagement with a separate deliverable. The reviewer's subject is the codebase. The methodology is a read of implementation against your intended design, and the output is findings tied to files and functions, with remediation guidance a developer can act on directly. That includes findings nothing can reach from outside today but that may become reachable as the app changes.

At Red Sentry, Source Code Review is a standalone service. It pairs well with web app penetration testing and API penetration testing, and running both on the same target is a common and sensible choice. Paired that way, the code guides deeper runtime validation. It is not a scope option inside an app pentest and it is not sold as one. You can buy either without the other.

What a reviewer needs from you before starting

A secure code review is only as good as its inputs, and missing inputs are what usually pushes a start date. The checklist:

• Repository access for the components in scope, plus build configuration and infrastructure-as-code if the deployment shapes the risk

• An architecture walkthrough with an engineer who can explain how the pieces talk to each other

• The authorization model as it is meant to work: roles, tenancy, who can see whose data. Written or verbal is fine, it just has to be stated

• Data-flow context for whatever matters most, whether that is payment data, PHI or credentials

• Your current SAST and dependency output, suppressions included, so the review starts where the tooling stopped

• A named contact for questions that come up mid-review

Access gets scoped with you before the engagement starts. The source code review service page lists which languages we cover and what comes back in the report, including one round of remediation testing within 90 days.

If your source maps are shipping to production, part of your code is already readable by anyone who wants it. Our post on JavaScript source maps covers what that exposes, and it is a cheap thing to check before you scope anything.

Where a review tends to earn its place

Scoping depends on your stack, your risk and your budget, so read these as situations where a secure code review is worth putting on the table, not as a verdict:

• SAST runs in CI and nobody has read the security-relevant code by hand. A review covers the context-dependent classes a pipeline is not built to catch, and holding multi-tenant data raises what that is worth

• A pentest is already scheduled against a codebase nobody has reviewed. Running both on the same target gives you exploitability from one and implementation detail from the other

• You are pre-launch with no external surface to test yet. A review is the option that works before you ship

• You have a large backlog of unresolved static analysis findings. A review scoped to triage plus your higher-risk components may do more for you than a broad one

• You have no static analysis at all. Automated scanning and dependency checks cover ground cheaply and repeatedly, and a manual review is not the economical way to find unpatched libraries, so the question is usually how to have both rather than which to buy

Scope, stated plainly

A secure code review is scoped to agreed repositories and components, over an agreed period, against the code as it exists at an agreed commit. It reads implementation. It does not prove exploitability against your running environment, and it does not cover anything outside the agreed scope.

Dynamic testing and code review answer different questions, which is why we have also written about how pentesting and vulnerability scanning work together and where the two differ. Neither one substitutes for the other.

Book a scoping call and tell us which components matter and why. We will tell you whether a secure code review earns its cost on top of the pipeline you already run, or whether something else should come first. The Source Code Review service page has the full scope and deliverables if you want those first.