Automated scanners are necessary and they are pattern matchers. They know what a SQL injection payload looks like and what an out-of-date library version means. What they cannot do is understand what your application is for, which is where an entire class of serious vulnerability lives.
Five classes that reliably survive a clean scan.
1. Insecure direct object references
The shape. A request contains an identifier - /invoices/4021 - and the
application returns the object without checking whether this user should see
it. Change the number, see someone else's invoice.
Why the scanner misses it. The scanner has no idea whose data it is looking
at. It sends the request, receives a 200 OK with a well-formed response, and
records a success. Nothing in the response says "this belonged to a different
tenant".
How to find it. Two authenticated sessions belonging to different users, and a systematic attempt to reach each one's objects from the other. It is tedious and it is where a real tester earns the engagement.
2. Business logic bypass
The shape. The application enforces a rule through a sequence of steps, and the sequence can be taken out of order. Add an item, apply a discount, remove the item, and the discount stays. Start a subscription change, abandon it midway, and end up on the new tier without the payment.
Why the scanner misses it. Every individual request is valid and returns a valid response. The flaw exists only in the relationship between them, which requires knowing what the flow is meant to achieve.
How to find it. Map the intended flow, then deliberately violate it - reorder, skip, repeat, abandon and resume. Ask what invariant each step assumes the previous one established.
3. Race conditions
The shape. A check and the action it authorises are separated in time, and a parallel request slips between them. One coupon submitted twenty times simultaneously and applied twenty times. A withdrawal validated against a balance that has already been spent by a concurrent request.
Why the scanner misses it. Scanners send requests sequentially. The vulnerability only appears under concurrency, so a sequential test of the same endpoint returns entirely correct behaviour.
How to find it. Send the same request in parallel at the moment of state change and check whether the invariant held. Anywhere a limit, a balance or a one-time use is enforced in application code rather than by a database constraint is a candidate.
4. Broken access control between roles
The shape. A viewer-role account calls an administrative endpoint directly and it works, because the authorisation check lived in the interface rather than in the API. The button was hidden; the endpoint was not protected.
Why the scanner misses it. Scanners are usually configured with one session, often an administrative one so they can reach the whole application - which is precisely the configuration that cannot detect a missing cross-role check.
How to find it. Enumerate the endpoints reachable by the highest-privilege role, then attempt every one of them with every lower-privilege session. It is mechanical, and it finds things almost every time.
5. Chains of low-severity findings
The shape. A verbose error message discloses a username format. A registration endpoint confirms which usernames exist. A password reset has no rate limit. Individually these are low or informational. Together they are account takeover.
Why the scanner misses it. Scanners score findings in isolation, because scoring a chain requires understanding what each link enables. A report of forty low findings gets triaged as forty low findings.
How to find it. Read the low findings together and ask what an attacker could build from them. This is the single highest-value hour in a report review and it is almost always skipped.
The reasonable conclusion
Scanning gives you breadth and frequency, and you should do it continuously. Testing gives you depth and intent, and you should do it periodically and after significant change. Neither substitutes for the other, and an organisation doing only the first has coverage without assurance.
Compliance requires scanning. Security requires someone thinking about what the application is for.