Reachability (Pro)

A Critical CVE in code your application never calls is not the same risk as the same CVE on a live request path. Reachability captures that difference: DefectDojo Pro records whether each Finding’s vulnerable code can actually be reached, shows you where that conclusion came from, and feeds it into the Finding’s computed priority.

Reachability is on for every DefectDojo Pro instance, and there is nothing to enable. Verdicts are recorded as soon as a source reports them, and a Finding that no source covers stays at Unknown.

Verdicts#

Every verdict is normalized to the same five values, whatever produced it:

Normalizing matters because tools disagree about wording: one scanner’s “no path found” and another’s “not in use” mean different things, and DefectDojo records both as verdicts you can compare rather than flattening them into a single yes/no.

The rules reachability follows#

These behaviors are deliberate, and they do not change per tool:

• Unknown never counts against a Finding. Most instances start with little or no reachability coverage. A Finding nothing has analyzed is scored exactly as it would be with the feature off.
• Unreachable lowers priority. It never closes a Finding. An “unreachable” verdict dampens the score so genuinely live issues sort above it, but the Finding stays open and visible. Reachability analysis is not perfect, and a wrong “unreachable” that silently hid a live Critical would be the worst possible failure.
• 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 of them reports reachability, the verdict applies across that duplicate cluster, so you do not lose the signal by importing another tool.

Where verdicts come from#

You do not have to adopt a new scanner to get value here — DefectDojo reads reachability 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. No configuration is required beyond importing the report as usual.
• Connectors. A connector that supports reachability sends verdicts for the Assets 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.

Sources that report reachability#

A verdict from Sensei carries the call path govulncheck found, from your code down to the vulnerable function. It is shown on the Finding under Reachability Call Path.

How verdicts end#

A verdict lasts as long as its source keeps reporting it.

• A report that stops asserting a verdict retracts it. When you reimport a report into the same Test, the report covers every Finding it still contains. If it no longer carries a verdict for one of those Findings, that source’s verdict is removed and the Finding falls back to what the other sources say, or to Unknown. Verdicts from other tools, connectors, the Reachability API and manual verdicts are not affected.
• A verdict nobody re-asserts expires. Once a day, verdicts whose source has not reported them again within the staleness window are removed. The window is 30 days by default, set with the DD_REACHABILITY_STALENESS_DAYS environment variable. A source that reports more often can expire sooner: DD_REACHABILITY_SOURCE_STALENESS_DAYS takes a JSON object of source name to days, for example {"Sysdig Vulnerability Report": 7}. The source name is the one shown with the verdict on the Finding.

Manual verdicts are never removed by either.

Setting reachability by hand#

When no scanner or connector reports reachability, you can record a verdict yourself. The Reachability dropdown in the Threat Intelligence panel of the Add and Edit Finding forms (see Editing Findings) records a manual verdict source alongside any tool-reported ones.

A manual verdict is not special-cased above scanners: it competes in the same resolution as every other source, so a stronger scanner verdict still overrides it — the value shown as Resolved beneath the dropdown is the winner across all sources, which may differ from what you chose. What is different is that a manual verdict is never removed by the staleness sweep or by a reimport, because a human judgment should not silently decay the way an unrefreshed scanner verdict does. Choose No manual override to remove it.

Reachability describes the vulnerable code inside your application. For whether the asset itself can be reached from outside, and whether the code is deployed at all, see Asset Exposure. The two are independent and can be used together.

How reachability changes priority#

Reachability is one more input to the priority score described in Scoring & Prioritization. Reachable verdicts raise a Finding’s priority, unreachable lowers it in proportion to the source’s confidence, and unknown leaves it untouched.

The strength of that adjustment is tunable per prioritization engine, like every other factor: set the reachability scalar to 0 to record verdicts without letting them move scores at all, or raise it to weight reachability more heavily. You can preview the effect with the prioritization simulator before applying it.

Because enabling reachability shifts scores, review your engine’s risk thresholds after turning it on so Findings land in the buckets you expect.

Reachability risk rules#

That adjustment is proportional to a Finding’s severity, which means it cannot express two things you may want. A Low-severity Finding whose code is confirmed reachable still gets only a small bump and stays in a low band; a Critical reported unreachable can still sit at the top of the queue. Two optional rules on the prioritization engine set a band directly instead:

• Reachable risk floor — the minimum Risk band for Findings whose vulnerable code is confirmed reachable. It only ever raises a band.
• Unreachable risk ceiling — the maximum Risk band for Findings reported unreachable. It only ever lowers a band, and it never closes or hides a Finding; it just caps where it sorts.

Both are empty by default, so nothing changes until you set them. The ceiling also has a minimum confidence: it applies only when the unreachable verdict is at least that confident, because capping a band on a low-confidence verdict is how a live Critical gets buried.

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.

What you see#

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 views such as “Critical and reachable” and save them.

On an asset — a Reachability Coverage panel showing the verdict breakdown for that asset, how many of its Findings carry any verdict at all, and how many Criticals reachability has demoted or confirmed. Each figure links through to the matching Findings. The share still at Unknown is shown alongside the rest: it tells you how much of the asset reachability can currently speak to.