A scanner grades each finding alone. An attacker never uses one alone. That difference is where most real breaches live, and it is invisible to any tool that reports a list.
How a list hides a breach
Take three findings, none of which would wake anybody up. An informational disclosure on a staging host. A password reset that does not invalidate existing sessions. An internal admin panel reachable if you already hold a session cookie.
- Low: staging host leaks a list of internal usernames.
- Medium: password reset does not rotate the session token.
- Medium: admin panel trusts any authenticated session.
Individually: one low, two mediums. A quarter of the way down a report. Together they are a full account takeover with administrative access, and the path takes about four steps.
Why tools stop at the list
Chaining is expensive. To know that finding A enables finding B, something has to actually try it, hold state between the two, and know what to do with what came back. A scanner is stateless by design: it fires a check, records a response, and moves on. That is what makes it fast and what makes it blind.
01 RECON staging.acme.io -> 12 internal usernames
02 ACCESS password reset -> session retained after reset
03 PIVOT reuse session -> admin.acme.io accepts it
04 PROVE read-only action -> scoped, logged, revertedThe step that matters is 03. Nothing in the first two findings predicts it. You only learn that the admin panel trusts a stale session by carrying that session to it, which means the tool has to still be holding it three steps later.
What to ask for instead
The useful question is not how many findings came back. It is how many of them were connected to each other. A report of forty unlinked findings and a report of one four step chain describe very different amounts of risk, and the second one is the one that tells you what to fix first.
Findings are the input. The path an attacker could actually walk is the output.