Menu
Dev.to #architecture·July 3, 2026

Enhancing Vulnerability Management with Reachability Analysis and Call Graphs

This article critiques current vulnerability management practices, highlighting their inefficiency due to a lack of "reachability context." It argues that existing tools and processes, from SCA scanners to VEX, fail to determine if vulnerable code paths are actually invoked by an application, leading to significant developer fatigue and misprioritized security efforts. The proposed solution involves generating a machine-readable "reachability map" or call graph to enable risk-driven prioritization.

Read original on Dev.to #architecture

The core problem in modern vulnerability management stems from a fundamental structural gap: the absence of a reachability map or call graph. Current practices, like scanning every dependency for CVEs, operate under the assumption that all reported vulnerabilities are equally critical and exploitable. However, applications rarely invoke every function within every dependency. This leads to a flood of alerts, many of which pertain to unreachable code, causing significant developer fatigue and misallocation of resources.

Key Mismatches in Current Vulnerability Management

  • Granularity Mismatch: Scanners report vulnerabilities at the package level (e.g., `libpng` version X has CVE-Y), while actual risk exists at the function level. An application might use `libpng` but never call the specific vulnerable function, rendering the CVE non-exploitable in that context.
  • Time Mismatch: CVEs are published continuously and flagged rapidly by scanners. However, the critical context of reachability (whether the vulnerable function is actually called) is typically determined manually, if at all, creating a significant delay in accurate risk assessment.
  • Composition Mismatch: Scanners evaluate individual packages in isolation. They fail to identify complex exploitation chains that involve multiple vulnerabilities across different packages interacting through the application's call graph, thereby missing critical combined risks.
ℹ️

The Missing Call Graph

The most significant missing artifact in vulnerability management is a machine-readable reachability map that details which packages, libraries, and functions an application actually calls at runtime. This artifact would bridge the gap between reported vulnerabilities and actual exploitability, enabling truly risk-driven security prioritization.

Proposed Solution: The Reachability Map

Instead of merely knowing *which packages* are present (SBOM) and *which packages have CVEs* (scanner output), the critical missing piece is knowing *which packages are invoked by the application's execution paths*. This "reachability map" would provide granular insights into function-level usage, allowing security teams and developers to focus on vulnerabilities that actually pose a threat. Implementing such a map requires advanced static or dynamic analysis to trace application execution flows and dependency interactions, fundamentally shifting vulnerability management from a volume-based approach to a context-aware, risk-prioritized one.

yaml
REACHABILITY_MAP:application: order-servicereachable:- package: express@4.18.2functions_called: [createServer, Router, json, urlencoded]call_depth: direct- package: pg@8.11.3functions_called: [Pool.connect, Pool.query, Client.end]call_depth: direct- package: jsonwebtoken@9.0.1functions_called: [verify, sign]call_depth: direct
vulnerability managementsoftware supply chainCVEapplication securitycall graphreachabilityDevSecOpsSCA

Comments

Loading comments...