An Attacker Doesn't See Three Reports. They See a Path.

You have three findings this quarter.

The network scan flagged an external VPN appliance: medium, patch when convenient. The DAST tool logged something about session handling on an internal admin API: info, no user impact demonstrated. Last year's pentest PDF has a paragraph about a build runner that can reach further into the network than it should: low, defense in depth.

Three tickets. Three different owners. Nobody is losing sleep.

Now read those same three findings the way an attacker does.

The walk

Step one. The VPN appliance has an authentication-bypass flaw. The attacker does not "patch when convenient." They exploit it and get an unauthenticated shell as www-data. The scanner was right that it was a medium. It had no way to know what came next.

Step two. From inside that shell, they read config files and scrape process memory. Out comes a service-account password and a live session token. Nothing in your stack scored this, because the shell was the finding. The loot from the shell was never an input to anything.

Step three. They replay that token against the internal admin API - the one the DAST tool called "info, session handling." The auth check sees a well-formed, unexpired token and does what it is told. Now they have the admin console. The token from step two was the key. On its own it was noise. Chained, it was privilege escalation.

Step four. The admin console has a legitimate feature: it can queue a job on a CI build runner. The attacker queues a job that runs their code. That runner is joined to the domain. Two teams own these two systems. Neither team owns the edge between them, so neither test looked at it.

Step five. From a domain-joined host, the payment-processing database is reachable. Customer and cardholder data can be pulled out. This is the incident report. It was assembled from a medium, an info, and a low.

Why the tools missed it

Every scanner scores findings the way a teacher grades a stack of essays - one at a time, independently. CVSS is a property of a vulnerability, not of a route.

But an attack chain is defined by the thing the tools throw away: the artifact. The shell from step one. The token from step two. The console session from step three. Each one is the input to the next step. Take the artifact away and the chain does not exist. Score each finding in isolation and the chain is invisible.

This is also why "it's in compliance scope" is not the reassurance people think it is. The payment database was in scope. It was scanned, it was documented, it had controls. What was never in scope was the four-step path from the public internet to its front door - because that path crosses a network team, an AppSec team, an identity system, and a CI pipeline, and no single assessment owns all four.

What actually answers the question

To see the chain you have to do what the attacker does:

1. Verify step one is really exploitable, and keep what it produces.
2. Feed that artifact into step two. Verify. Keep what it produces.
3. Repeat until you reach something that matters to the business, or you run out of moves.
4. When a fix lands anywhere on that path, re-run the whole chain - not the one finding - and check that the path is actually broken now.

That is the difference between a list of vulnerabilities and a threat model. One is a spreadsheet. The other tells you which spreadsheet row an attacker uses first, and what they get for it.

A finding says something is wrong. A chain says here is how they get in, here is where they end up, and here is the one fix that costs them the most.

That is the report worth having.