A Critical CVE You Can't Reach Is Not Your Biggest Problem: Introducing Reachability in DefectDojo Pro

A Critical CVE in an application that is never called is not the same risk as the same CVE sitting on a live request path. Every AppSec team knows this instinctively, but most vulnerability queues treat both findings identically. The result is a triage backlog where theoretical risk crowds out real risk.

DefectDojo Pro now closes that gap. Reachability, available in beta, records whether each Finding's vulnerable code can actually be reached, shows you exactly where that conclusion came from, and feeds it into the Finding's computed priority.

What Reachability does

Reachability answers a simple question for every Finding: can an attacker actually get to this code? DefectDojo Pro normalizes the answer into five verdicts, no matter which tool produced it:

• Reachable (runtime): The vulnerable code was observed executing.
• Reachable (static): A call path to the vulnerable code exists from an application entry point.
• Potentially reachable: Partial evidence exists. For example, the vulnerable package is used, but the specific function could not be confirmed.
• Unreachable: Analysis found no path to the vulnerable code.
• Unknown: No reachability analysis covers this Finding yet.

Normalization matters because scanners disagree about wording. One tool's "no path found" and another's "not in use" mean different things. DefectDojo records both as verdicts you can compare side by side, rather than flattening them into a single yes or no.

No new scanner required

You do not have to adopt another tool to get value here. DefectDojo reads reachability data that tools you may already run are producing:

• Scanners that report it in their output. Several supported parsers carry reachability, either as structured data or in their report text. Import the report as usual, and the verdicts come with it.
• Connectors. A connector that supports reachability sends verdicts for the products it syncs, refreshed on its normal schedule.

Coverage is normally partial, and that is expected. Tools that do not report reachability simply leave their Findings at Unknown, and Unknown never counts against a Finding.

Built with guardrails, not shortcuts

Reachability analysis is useful, but it is not perfect. A wrong "unreachable" verdict that silently hid a live Critical would be the worst possible failure, so DefectDojo follows a set of deliberate rules that do not change per tool:

• Unknown never penalizes a Finding. A Finding nothing has analyzed is scored exactly as it would be with the feature off.
• Unreachable lowers priority. It never closes a Finding. The verdict dampens the score so genuinely live issues sort above it, but the Finding stays open and visible.
• Every verdict shows its source. No verdict appears without the tool that produced it, its confidence, and the commit it analyzed where one is known.
• Verdicts follow deduplication. When several scanners report the same vulnerability and only one reports reachability, the verdict applies across the entire duplicate cluster. Importing another tool never costs you the signal.
  
  

Tunable prioritization, with a simulator

Reachability is one more input to DefectDojo Pro's priority score. Reachable verdicts raise a Finding's priority, unreachable verdicts lower it in proportion to the source's confidence, and unknown leaves it untouched.

How strongly it moves scores is up to you. The reachability scalar is tunable per prioritization engine: set it to zero to record verdicts without letting them influence scores at all, or raise it to weigh reachability more heavily. You can preview the effect with the prioritization simulator before applying anything. And because enabling reachability shifts scores, it is worth reviewing your engine's risk thresholds afterward so Findings land in the buckets you expect.

For teams that want harder guarantees, two optional risk rules set bands directly:

• Reachable risk floor: A minimum Risk band for Findings whose vulnerable code is confirmed reachable. It only ever raises a band, so a confirmed-reachable Low can no longer hide at the bottom of the queue.
• Unreachable risk ceiling: A maximum Risk band for Findings reported unreachable. It only ever lowers a band, never closes or hides anything, and it applies only when the verdict meets a minimum confidence you set.

One more safeguard: a Finding whose CVE is reported as actively exploited in the wild is never capped by the ceiling. Exploitation evidence takes precedence over an absence-of-path claim, every time.

What you see in the platform

Reachability shows up where triage actually happens:

• On a Finding: a reachability badge and a Reachability Sources panel listing every source that reported on it, each source's verdict and confidence, and which one currently applies. Where a tool supplies a call path, the supporting evidence is shown with it.
• On the Findings list: a Reachability column and filter, so you can build and save views like "Critical and reachable."
• On an asset: a Reachability Coverage panel showing the verdict breakdown, how many Findings carry any verdict at all, and how many Criticals reachability has demoted or confirmed. Each figure links through to the matching Findings.

That last panel also shows the share still at Unknown, which tells you honestly how much of the asset reachability can currently speak to.

Getting started

Reachability is a beta feature in DefectDojo Pro and is off by default. A superuser can enable it under Settings > Feature Flags. While it is off, no verdicts are recorded, priority is unaffected, and no reachability UI appears, so turning it on is a deliberate choice you make when you are ready.

For full details, see the Reachability docs or reach out to our team in #help in the community slack.

Your scanners already know which vulnerabilities matter. Now DefectDojo makes sure that knowledge shows up in your priority queue.