Skip to content
REDMAW

Perspective

Attackers don't see findings. They see paths.

Why lists of independent findings misrepresent risk, and what changes when exposure is measured by what it reaches.

RedMaw6 min read

Most security programs inherit their view of risk from their tooling. Scanners emit findings, each with a score, each in its own queue. The output is a list, and a list implies that items can be worked independently and in order.

Adversaries do not work from that list. They chain. A low-severity information disclosure becomes useful because it names an internal host. An over-broad OAuth grant becomes useful because it survives a password reset. The value of a weakness is defined by what follows it.

The measurement problem

When findings are scored in isolation, two exposures with identical scores can carry completely different consequences. One ends at a static marketing asset. The other is the first hop toward a records system.

Same first hop, different consequence
  1. Internet
  2. Application
  3. Credential
  4. Internal System
  5. Customer Data

Each hop validated by successful exploitation

What changes with paths

  • Prioritization follows reach instead of a generic score
  • Chokepoints emerge: the single hop that breaks many paths at once
  • Engineering receives a reason, not a ticket
  • Closure becomes testable: either the path can still be walked, or it cannot

Tags

  • attack paths
  • prioritization
  • validation

Keep going

Related

Further reading

Attack LibraryInternal Infrastructure

Kerberoasting

Any domain account can ask for the tickets. The weakness is the password behind the service account.

· 6 min read
GuidesProgram

From scanning to validation

You do not have to abandon scanning. You have to stop treating its output as a risk statement.

· 10 min read

Stop assuming you are secure. Prove it.

Continuously test what an attacker can actually reach across your applications, SaaS identities, internal infrastructure and AI systems.