Knowledge · Software Supply Chain

Vulnerable Function Reachability

The distinction between component presence, vulnerable component relevance, vulnerable function usage, and exploitability. How reachability analysis provides evidence about code paths and usage, and why reachability does not by itself prove exploitability.

Primary question: How can security teams determine whether application code actually reaches vulnerable functionality inside a dependency?

Definitions

Vulnerable function reachability

A layered determination that proceeds through: (1) component presence - the vulnerable package is in the project; (2) import/module use - the vulnerable module is imported or referenced by application code; (3) call-graph reachability - a path exists from application code to the vulnerable function through imports and function calls; (4) data-flow or precondition satisfaction - attacker-controlled input can reach the vulnerable state, when separately supported by the analyzer. Import presence alone is not reachability. Call-graph reachability does not prove that attacker-controlled data reaches a vulnerable state. Data-flow reachability must not be assumed unless the analyzer explicitly supports it.

Call trace

A record of the code path from application code through import statements to the vulnerable function inside a dependency. A call trace shows the sequence of imports and function calls that lead to the vulnerable functionality.

Direct dependency reachability

Evidence that vulnerable functionality in a directly declared dependency is reached from application code through explicit imports and function calls.

Transitive dependency reachability

Evidence that vulnerable functionality in a transitive (indirectly declared) dependency is reached from application code through a chain of imports and function calls that passes through one or more intermediate dependencies.

The engineering problem

SCA analysis identifies vulnerable components but does not determine whether the vulnerable functionality inside those components is actually reached from application code. A vulnerable component may have many functions, and only some may be used by the application. [derscanner-sca]

Without reachability analysis, teams cannot distinguish between a vulnerable component that is imported and called from application code and a vulnerable component that is present but not used, making prioritization less accurate. [derscanner-sca]

Reachability analysis provides evidence about code paths but does not prove exploitability. Residual risks such as reflection, dynamic loading, configuration-dependent paths, and runtime behavior may make a static result of "not found reachable" an incorrect assessment in specific deployment contexts. [derscanner-sca]

Security controls

Each control inspects a different artifact and produces evidence for an engineering decision.

Import analysis

Dependency import detection
Artifact
Application source code import statements referencing dependency modules.
Risk
Vulnerable dependencies that are imported but not evaluated for reachability of their vulnerable functions.
Output
List of all dependency imports in the application code, with version information.

Evidence: DerScanner software composition analysis documentation

Function call tracing

Call trace analysis
Artifact
Application source code, dependency source code, and call graph data.
Risk
Vulnerable functions inside dependencies that are called from application code but not identified through import analysis alone.
Output
Call trace data showing the sequence of imports and function calls from application code to vulnerable functions inside dependencies.

Evidence: DerScanner software composition analysis documentation

Reachability assessment

Vulnerable function reachability analysis
Artifact
SCA findings correlated with SAST findings to determine which vulnerable dependency functions are actually reached.
Risk
Vulnerable components whose vulnerable functionality is not reached from application code, leading to over-prioritization.
Output
Reachability evidence for each vulnerable component, indicating whether its vulnerable functionality is reached, and if so, through which code path.

Evidence: DerScanner software composition analysis documentation

Verification workflow

  1. Run SCA analysis to identify all vulnerable components in the project.
  2. Run SAST analysis to identify all import statements and function calls in the application source code.
  3. For each vulnerable component, determine whether its modules are imported by application code.
  4. For each imported vulnerable module, trace the function calls from application code to the vulnerable function inside the dependency.
  5. Construct call traces showing the full code path from application code through imports to vulnerable functions.
  6. Assess direct vs. transitive dependency reachability — determine whether the vulnerable function is reached through a direct import or through a chain of intermediate dependencies.
  7. Use reachability evidence for prioritization — reachable vulnerable functions are higher priority than unreachable ones.
  8. Evaluate residual risks — consider reflection, dynamic loading, configuration-dependent paths, and runtime behavior that may make a static result of "not found reachable" a false negative in specific contexts.

Limits of verification

  • Reachability analysis provides evidence about code paths but does not by itself prove exploitability. A static result of "not found reachable" may be a false negative because unsupported dynamic behavior, reflection, native boundaries, framework behavior, or configuration can create runtime paths not represented in the static model.
  • Dynamic imports and framework-level dependency injection may introduce code paths that are difficult to trace statically.
  • Production acceptance remains an organizational engineering decision.

Canonical terms used: Vulnerable function reachability; Call trace; Direct dependency reachability; Transitive dependency reachability.

Evidence and references

  1. DerScanner software composition analysis documentationDerScanner SCA identifies component vulnerabilities, dependencies, software supply chain risks, and license risks. DerScanner provides hybrid SAST+SCA analysis to correlate SCA findings with SAST findings for dependency vulnerability prioritization, including reachability analysis.derscanner-sca

Analyze vulnerable function reachability

Trace the code path from application code to vulnerable functions inside dependencies.

Tell us about your dependency security workflow and reachability analysis requirements. The DerScanner team will help you implement call trace analysis.

Analyze vulnerable function reachability

Discuss vulnerable function reachability analysis for your organization

Share your language ecosystem, dependency security requirements, and prioritization needs. We will respond with the next practical step for implementing reachability analysis.

Engineering knowledge for building and operating trustworthy systems.

DerSecur Recognition · build 821af10 · 2026-08-09 16:41:16Z · system