VulPathFinder: Vulnerability Path Explanation

• VulPathFinder is an explainable vulnerability path discovery framework that uncovers bug-triggering paths in C/C++ code using learned GNN-based sink detection.
• It replaces rule-based sink identification with a trained GNN, enhancing precision through program slicing and detector-aware ranking.
• Empirical results on the SARD dataset demonstrate near-perfect detection metrics and superior explanation quality compared to baseline methods.

VulPathFinder is an explainable vulnerability path discovery framework for open-source code whose objective is to move beyond binary vulnerability labels and identify the most probable vulnerable execution path leading to a bug-triggering statement. The framework enhances SliceLocator by replacing rule-based sink identification with a learned Graph Neural Network (GNN) that predicts Potential Sink Points (PSPs), then applies program slicing and detector-aware ranking to select the path that best explains the original vulnerability prediction (Atashin et al., 23 Jul 2025).

1. Problem setting and explanatory objective

VulPathFinder is designed for a specific deficiency in graph-based vulnerability detection: strong predictive performance does not by itself explain the root cause of a detected vulnerability. The framework addresses the need to locate vulnerable statements and discover paths leading to the activation of the vulnerability, rather than merely labeling a function or graph as vulnerable (Atashin et al., 23 Jul 2025).

The motivating critique has two parts. First, graph-based detectors are described as powerful but opaque. Second, existing explanation methods often operate at the graph or subgraph level and do not recover program execution paths in a form suitable for root-cause analysis. The paper therefore positions vulnerability explanation as a path-discovery problem: identify a likely sink statement, recover candidate backward slices leading to it, and select the path whose vulnerability score is most consistent with the prediction of a target detector (Atashin et al., 23 Jul 2025).

This framing distinguishes VulPathFinder from methods that explain model behavior without explicitly representing taint flow, slicing, and program dependence. It also distinguishes it from systems that rely on manually specified sink rules. The central claim is that explanation quality improves when sink identification is learned from code context rather than predetermined by a rule set.

2. Code representation and learned sink-point detection

The framework operates on C/C++ source code and converts code into a Code Property Graph (CPG) using Joern and SVF. The CPG integrates AST, CFG, CDG, and DDG, thereby encoding both syntactic and semantic dependencies in a unified graph representation (Atashin et al., 23 Jul 2025).

Training labels are derived from the SARD dataset, where ground-truth annotations for vulnerability-triggering statements are used to label CPG nodes as sink or non-sink. The benchmark covers six buffer-overflow CWEs—CWE-121, CWE-122, CWE-123, CWE-124, CWE-125, and CWE-126—and includes 9,660 vulnerable functions, with duplicates removed via MD5 hashing (Atashin et al., 23 Jul 2025).

VulPathFinder trains a Graph Convolutional Network (GCN) for node classification. The architecture comprises 6 GCN layers; each hidden layer is followed by BatchNorm, ReLU, and Dropout(0.5), and the final output layer predicts 2 classes. Node features are 128-dimensional Word2Vec embeddings, trained using random walks over the graph to encode both node type and node content. The output is binary: 1 for sink and 0 for non-sink, with predicted sink nodes treated as Potential Sink Points (PSPs) (Atashin et al., 23 Jul 2025).

The methodological significance of this stage is that VulPathFinder does not search for sinks by matching predefined API, pointer, array, or arithmetic patterns. Instead, it learns sink likelihood from graph-structured code context. This supports the paper’s claim that VulPathFinder is more context-aware and more capable of generalizing to unseen sink statements than rule-based alternatives.

3. Path generation and detector-aware path ranking

After PSP detection, VulPathFinder performs backward slicing from each predicted sink point to generate candidate vulnerable paths. The slicing procedure is explicitly described as proceeding from the sink “all the way up to the source of the path,” producing a list of candidate explanations rather than a single deterministic trace (Atashin et al., 23 Jul 2025).

The paper illustrates the idea with a buffer-overflow example in which line 8 is the sink, memmove(data, source, 100*sizeof(int));, and candidate paths include 1 -> 5 -> 8, 1 -> 6 -> 8, and 7 -> 8. In this formulation, slicing is the step that turns sink prediction into path-level explanation by connecting source of taint or relevant values, intermediate dependencies, and the sink statement (Atashin et al., 23 Jul 2025).

Candidate paths are then ranked using a previously trained graph-based vulnerability detector treated as a black box. The paper evaluates three target detectors: Devign, Reveal, and IVDetect. The vulnerability probability of the original graph is defined as

$p_G = \Phi(\text{vec}(G))$

where $\Phi$ is the target detector, $\text{vec}$ is the Word2Vec embedding function, and $G$ is the original code graph. For a candidate-path subgraph $g$, the path importance score is defined as

$\text{IS}_g = 1 - (p_G - p_g)$

where $p_g$ is the detector probability for the subgraph. The selected explanation is the path with the highest importance score, reflecting the paper’s principle that a path is more plausible when its vulnerability score is close to that of the full graph (Atashin et al., 23 Jul 2025).

The framework is organized into four phases: Training GNN model for Sink Point Detection, Identification of PSPs, Flow Path Generation via backward slicing, and Flow Path Selection via scoring. Although the paper notes that class imbalance is handled by oversampling the minority class and a weighted loss function is used, it does not provide an explicit mathematical loss formula for the GCN training (Atashin et al., 23 Jul 2025).

4. Position relative to SliceLocator and GNNExplainer

VulPathFinder is presented as a direct methodological extension of SliceLocator. Both systems use backward slicing and a graph-based detector to rank candidate paths, but they differ at the sink-identification stage. SliceLocator uses rule-based sink identification; VulPathFinder uses a trained GNN to identify PSPs (Atashin et al., 23 Jul 2025).

The paper also compares VulPathFinder with GNNExplainer, a general-purpose GNN explanation technique that seeks a minimal subgraph and a subset of node features sufficient to preserve a model’s prediction. The distinction is not merely implementation-level but objective-level: GNNExplainer explains a model’s prediction, whereas VulPathFinder aims to explain the vulnerability path and root cause (Atashin et al., 23 Jul 2025).

Method	Sink identification	Explanation target
VulPathFinder	GNN-predicted PSPs	Vulnerability path/root cause
SliceLocator	Rule-based sinks	Vulnerability path/root cause
GNNExplainer	Not path-specific	Minimal predictive subgraph

This comparison clarifies the paper’s main claim of novelty. VulPathFinder retains the slicing-and-ranking logic of SliceLocator but replaces its most brittle component, namely predefined sink rules. At the same time, it departs from generic explainers by embedding taint-flow and slicing semantics into the explanatory procedure. The result is an explanation framework that is domain-specific rather than model-generic.

5. Dataset, training setup, and empirical results

The empirical study uses the SARD benchmark with the six buffer-overflow CWEs listed above, with a 70% training, 10% validation, and 20% test split. Training is reported on a single NVIDIA RTX 3070 Ti GPU with batch size 64 and the Adam optimizer (Atashin et al., 23 Jul 2025).

For PSP detection, the trained GCN achieves Precision = 0.97, Recall = 0.99, and F1-Macro = 0.98. The paper highlights the high recall as particularly important because missed sinks cannot be recovered by later slicing stages (Atashin et al., 23 Jul 2025).

For explanation quality, the paper uses Triggering Line Coverage (TLC). The metric is defined using $s^e$ for statements in the predicted vulnerable path and $s^v$ for ground-truth triggering statements, so TLC measures overlap between the predicted explanation and the true vulnerability-triggering lines (Atashin et al., 23 Jul 2025).

Approach	IVDetect	Devign	Reveal
VulPathFinder	0.98	0.99	0.98
SliceLocator	0.90	0.97	0.91
GNNExplainer	0.71	0.86	0.86

These results support two claims stated in the paper. First, VulPathFinder outperforms SliceLocator across all three target detectors. Second, it substantially outperforms GNNExplainer as a general GNN explanation baseline. The best reported TLC is 0.99 with Devign, and the paper summarizes overall explanation quality by stating that VulPathFinder achieved an average TLC score of 98% (Atashin et al., 23 Jul 2025).

6. Limitations and relation to adjacent research directions

The paper explicitly identifies three limitations. First, the SARD dataset is an academic dataset with synthetic code and may not reflect real-world software perfectly. Second, the evaluation covers only six types of CWEs, all mostly related to buffer overflow vulnerability. Third, the study is restricted to C/C++ and has not been evaluated on languages such as Java or Python (Atashin et al., 23 Jul 2025).

These limitations constrain external validity. A plausible implication is that VulPathFinder’s reported effectiveness is strongest for path explanation within graph-represented buffer-overflow settings, and less established for heterogeneous vulnerability classes, multilingual codebases, or production-scale software ecosystems.

In the broader literature, VulPathFinder occupies the explanation layer of vulnerability analysis rather than the detection-only or exploit-confirmation layers. VFArchē focuses on localizing vulnerable functions (VFs) for reachability analysis in Software Composition Analysis pipelines, especially when patch links may or may not be available (Zhang et al., 22 Jun 2025). VulMatch addresses repeated vulnerability detection in binaries through source-guided binary signature generation and binary matching, which is orthogonal to source-level path explanation (Liu et al., 2023). Vulnsage uses source-to-sink path information in a multi-agent Automated Exploit Generation loop, while PBFuzz formulates PoV generation as solving reachability constraints and triggering constraints over vulnerable execution paths (Chen et al., 6 Apr 2026, Zeng et al., 4 Dec 2025). In CLI software, PILOT uses potential call paths and execution feedback to generate semantically valid command-line options and input files that reach deep target functions (Shiraishi et al., 25 Nov 2025).

Taken together, these neighboring directions suggest a larger research continuum: function localization, path discovery, vulnerability explanation, exploit generation, and exploit validation. Within that continuum, VulPathFinder is specifically concerned with turning graph-based vulnerability predictions into path-level, root-cause explanations by combining learned sink detection, backward slicing, and detector-aware path ranking (Atashin et al., 23 Jul 2025).