Reachability

​

Overview

Reachability helps you understand whether vulnerable code is actually used by your application. A dependency may contain a known vulnerability, but that does not always mean the vulnerable code can be invoked in practice. Backline analyzes the affected package, version, and vulnerable functions or APIs to determine whether the vulnerable logic is referenced by your application and whether it can be reached from an application entry point. This helps teams distinguish between vulnerabilities that are merely present in a library and vulnerabilities that are relevant to real application behavior.

​

Where to Find It

Open a vulnerability and navigate to: Vulnerability Side Panel → Risk Analysis The Risk Analysis tab includes reachability context, supporting evidence, and a per-symbol breakdown when available.

​

What Reachability Answers

To answer the reachability question, Backline analyzes vulnerable symbols, library usage, code references, and execution paths from entry points such as APIs and handlers. Reachability helps answer questions such as:

• Is the vulnerable function actually used by the application?
• Did Backline find a path from an API or handler to the vulnerable code?
• Is this vulnerability present but not reachable?
• Which functions or symbols are driving the result?
• How confident is the analysis?

​

Security-First Analysis Model

Backline uses a conservative, security-first approach when evaluating reachability. The system is designed to avoid false negatives. When evidence strongly suggests the vulnerable code may be used, Backline favors marking it as reachable rather than incorrectly assuming it is safe. This means:

• Reachability is assessed at the symbol level when vulnerable functions or APIs are known
• If symbol-level data is unavailable, analysis falls back to the library level
• Backline attempts to connect vulnerable code to application references and public or internal entry points
• If a vulnerable function is referenced in application code, it may be treated as Reachable even when a complete execution path cannot be proven

​

Reachability Statuses

Backline supports five reachability states:

​

What Reachability Shows

The Reachability section provides a high-level result for quick triage, along with evidence for deeper review. It includes:

• Reachability status: Calculating, Reachable, Not Reachable, or Uncertain
• Confidence score: 0 to 100
• Reasoning summary: Plain-language explanation of the result
• Evidence table: Per-symbol analysis when symbol data is available

​

Reachability Summary Card

The summary card is designed for quick decision-making.

​

Status

Displays the current reachability result.

​

Confidence Score

A numeric score from 0 to 100 representing how certain the analysis is, based on code evidence, path evidence, and analysis completeness.

​

Reasoning Summary

A concise explanation describing why the vulnerability received its current status. Example: Not Reachable: Vulnerable symbols were identified in the dependency, but no references were found in the application code and the analyzed service does not expose the execution path required for invocation.

​

Evidence Card

When vulnerable symbol data is available, Backline shows a table with the analysis for each vulnerable target. The table includes:

• Vulnerable Target
• Reference Count
• Status

This helps you understand exactly which vulnerable functions are relevant to the assessment.

​

How It Works

Backline evaluates reachability using three evidence dimensions:

​

Confidence Score

The confidence score reflects how strong and complete the reachability analysis is, based on symbol evidence, path evidence, and analysis completeness.

​

Why This Matters

Reachability helps you focus on vulnerabilities that are relevant to real application behavior. Not every vulnerable dependency creates the same level of risk. A CVE may exist in a package, but if the vulnerable code is never referenced or cannot be invoked, it may be less urgent than a vulnerability sitting directly on an active execution path. Reachability gives teams deeper context for:

• prioritizing remediation work
• understanding real application exposure
• validating whether vulnerable code is actually used
• explaining why a finding is or is not actionable

​

Best Practices

Use reachability together with exploitability, severity, and overall risk context. A common workflow is:

1. Review the reachability status
2. Read the reasoning summary
3. Check the confidence score
4. Review the vulnerable target table
5. Investigate referenced symbols and entry-point paths as needed

​

FAQ

​

Is reachability the same as exploitability?

No. Reachability focuses on whether the vulnerable code is used by the application. Exploitability focuses on whether the vulnerability can realistically be exploited in the environment.

​

Can a vulnerability be present but not reachable?

Yes. A vulnerable dependency may exist in the application, but the vulnerable code may not be referenced or executable.

​

Why can a CVE be marked Reachable without a full proven execution path?

Backline uses a conservative security model. If the vulnerable function is referenced in application code and no strong blocker exists, the finding may still be treated as Reachable.

​

What does Uncertain mean?

Uncertain means Backline could not complete enough reliable analysis to determine whether the vulnerable code is reachable.

​

What does the confidence score represent?

Confidence reflects the quality and completeness of the analysis, based on symbol evidence, path evidence, and analysis completeness.

​

Why is the evidence shown per symbol?

A single CVE may affect multiple vulnerable functions. Per-symbol evidence helps you understand which targets are actually relevant in your codebase.

​

Related Documentation