Why the fix at the shared hop beats the worst finding

Most vulnerability output is sorted one way: by the severity of each individual finding. A critical-rated flaw sits above a medium-rated one regardless of where either lives in the environment. That ordering is easy to produce and easy to defend, and it is often the wrong list to work from first.

The reason is that findings don't act alone. Your environment is a graph: once an intruder has a foothold, identities, assets, exposures, and controls can connect them to the systems they actually want. Two findings that look unrelated in a severity table can turn out to be two ways into the same room. If that's true, the room — not either route individually — is what determines how much risk actually goes away when something gets fixed.

SCARP models attack paths as chains of hops: an entry route, the exposure that makes it reachable, the control that is supposed to stop it, and the crown jewel it leads to. A single control gap can sit underneath several different entry routes at once. A credential-spray route and a single-factor sign-in fallback might look like two separate weaknesses, but if both cross the same weak access policy on their way to the administration plane, they share a choke point.

The point is not to remove paths in the abstract. It is to block access to the assets that matter most with the smallest change set. That is the case for prioritizing the choke point over either individual entry route: one change can block every route to the target that depends on it. A queue sorted by severity has no way to represent that relationship — it can only tell you which finding scored higher, not which changes protect the crown jewel.

Once a shared hop is identified, the next question is whether the proposed change set blocks every route to the crown jewel — and the route count is a projection until it's tested. Say four distinct routes reach a sensitive asset, and three of them are modeled as crossing one specific control. Enforcing a fix at that control is expected to block those three routes in a single change, while the fourth stays visible as work still needed to protect the target.

Expected and realized are not the same number, and SCARP keeps them separate on purpose. Sometimes the gap is by design: a route that never crossed the fixed control stays open, and it is queued for a fix of its own. Sometimes the gap is a discovery: a route the fix was expected to cover survives the retest, because the model missed something or the change did not hold in production. Both cases carry the same lesson. The difference between projected and confirmed is information worth keeping, not noise to round away, and reporting a fix as fully closed because it shipped, rather than because a retest confirmed it, is the failure mode this arithmetic exists to prevent.

None of this means severity is irrelevant — it's still one of the inputs into which paths matter and how urgently. But treated as the only sort key, it optimizes for the wrong unit. A critical finding sitting on a single, hard-to-reach path can matter less than a medium-rated control gap if that gap is part of the smallest change set needed to block access to a crown jewel. Choosing the changes that protect the target, and then confirming afterward which routes are actually blocked, is a different discipline than working a queue top to bottom.