Scanners are very good at one job: finding known weaknesses in software. They are much less able to answer the question that matters most for prioritisation — can an attacker actually get to this?
Two kinds of reachability
Network reachability asks whether there is a route to the affected system: from the internet, from a partner connection, or from an internal zone that is commonly compromised. Firewalls, segmentation and access rules all change the answer.
Code reachability asks whether the vulnerable component is actually loaded and used by the application. Many dependency findings sit in code paths that are never executed.
Why it is hard
Answering either question means combining data that usually lives in different tools and teams: network configuration, asset inventory, application behaviour, ownership. No single scanner sees all of it, which is why reachability is so often skipped — and why backlogs stay full of theoretical issues.
Why it is worth it
Reachability is where most of the prioritisation value hides. Removing unreachable findings from the urgent queue — while keeping them recorded and scheduled — frees capacity for the issues that genuinely expose you.
A note of caution
Unreachable today is not unreachable forever. A good context-aware approach re-evaluates when the environment changes, and pays attention to attack paths that could make an internal weakness reachable through a chain of smaller issues.