What Automated Scanners Miss (and Manual Review Catches)

Automated scanners (SAST for source code, DAST for running applications) are genuinely useful, they're fast, consistent, and catch a real class of issues cheaply. They're also not sufficient on their own, and the gap between "scanned" and "actually tested" is where a lot of real risk hides.

Business logic flaws have no generic signature

A scanner can recognize the pattern of a SQL injection, untrusted input flowing into a query without parameterization is a detectable shape. It cannot recognize that your checkout flow lets a discount code be applied twice by hitting "back" and resubmitting, or that a multi-step approval workflow can be short-circuited by calling step three directly. These aren't pattern-matchable because they depend entirely on what the application is supposed to do, which only a human reviewer who understands the intended behavior can evaluate.

Authorization is contextual, not structural

This is the same gap discussed in our piece on common API security mistakes: a scanner can confirm an endpoint requires authentication, but confirming it requires the right authorization, that user A can't access user B's specific resource, requires understanding the data model and testing with two different authenticated identities. That's a workflow, not a pattern match.

Chained, low-severity findings

A scanner reports individual findings in isolation. An information disclosure rated "low," combined with a rate-limiting gap rated "low," combined with a predictable ID scheme rated "informational," can chain into full account takeover, but only a human tracing the actual exploitation path sees that the three "low" findings combine into something critical. Automated tools don't chain findings; they report a list.

False positives that erode trust in the tool

A high false-positive rate is one of the most common reasons scanner output gets ignored, teams get burned by triaging a dozen "critical" findings that turn out to be non-issues, then start deprioritizing scanner output wholesale, including the genuine findings mixed in. Manual validation of scanner output is part of what makes it actionable rather than noise.

Configuration and architecture decisions

A scanner analyzing a single repository has no visibility into how that service is actually deployed, whether it's exposed to the internet, what trust boundary it sits behind, whether the database it talks to allows connections from anywhere. Architectural review, the kind covered in our Cloud Security and Network Security services, operates at a layer scanners structurally can't reach from source code alone.

Where automated tools genuinely earn their place

None of this is an argument against automated scanning, it's an argument for using it for what it's actually good at: triaging effort. Running SAST/DAST first means a manual reviewer's time gets spent on validating and extending real findings and hunting for the logic-level issues tools can't see, instead of manually re-discovering the pattern-matchable ones a tool would have caught in seconds. That's exactly how our Secure Code Review engagements are structured, automated tooling narrows the field, senior reviewers do the part that actually requires judgment. Blind SQL injection is a concrete example of exactly this gap, see our piece on why SQL injection still works, and for the broader manual-vs-automated distinction, see manual penetration testing vs. automated vulnerability scanning.