Finding the commit that introduced a software vulnerability is deceptively difficult. Vulnerabilities are often discovered years after they were introduced, sometimes persisting for an average of 1,732 days before being patched. By the time a fix is issued, the original code that created the vulnerable condition has been touched by dozens of subsequent changes. The standard approach, called SZZ, traces vulnerable code backward through git blame and picks either the most recent or earliest modification. But the true culprit can sit anywhere in that history, and no positional heuristic can reliably identify it.
TraceVIC, from Fnu Tanish, Samiha Shimmi, Samikshya Chapagain, Hamed Okhravi, Mona Rahimi, and Lei Zhang at Northern Illinois University and MIT Lincoln Laboratory, addresses this problem directly. Submitted to arXiv on September 22, 2026, the paper introduces a temporal graph-based framework that reasons about how vulnerability-relevant code evolves across revisions rather than where a candidate commit sits in the history. The method achieves an F2 score of 0.814 when modeling the full revision history, up from 0.637 without it, and identifies a valid vulnerability-inducing commit for 78 out of 79 vulnerabilities across four unseen C/C++ projects.
Why Positional Reasoning Fails for Vulnerability Attribution
The SZZ algorithm and its variants have been the workhorses of vulnerability-inducing commit identification. B-SZZ selects the most recent commit that modified a vulnerable line before the fix. V-SZZ selects the earliest. Both assume that the inducing commit occupies a predictable position in the revision history. This assumption breaks down for vulnerabilities that are foundational, meaning they persist across multiple software versions. More than 50 percent of vulnerabilities are foundational, and their relevant code can evolve through multiple revisions before the fix is applied.
The paper illustrates this with CVE-2014-2309, a Linux kernel vulnerability that allows a remote attacker to exhaust system memory through unbounded allocation of routing entries. The relevant ip6_dst_alloc call was modified across several revisions. Early commits established the allocation logic without introducing unsafe behavior. A later commit introduced the semantic change that enabled route entries to bypass the relevant accounting mechanism, creating the vulnerable condition. Subsequent commits preserved and evolved this behavior before the fix. The ground-truth inducing commit occurred in the middle of the revision history, not at either boundary. B-SZZ would have selected a later commit, and V-SZZ would have selected an earlier one. Both would have been wrong.
This example motivates a fundamental reformulation. Rather than treating VIC identification as a positional selection problem, TraceVIC formulates it as a contribution-based ranking problem. The goal is to determine which change most strongly contributed to the emergence of the vulnerable condition, regardless of where that change appears in the timeline.
How TraceVIC Models Code Evolution
TraceVIC operates in two sequential stages, sharing a common graph encoder. The first stage localizes likely root-cause lines. The second stage ranks candidate commits.
The process begins with a vulnerability-fixing commit. TraceVIC identifies the source files modified by the fix and traces the relevant lines backward through revision history, constructing a candidate commit chain for each traced line. For each commit in the chain, it builds a revision-level Code Property Graph that captures program structure using AST-level units such as functions, control structures, statements, and expressions, augmented with control-flow and data-flow dependencies extracted via Joern. The graph is restricted to code changed by that commit.
Critically, TraceVIC then connects corresponding nodes across consecutive revisions using temporal edges. This requires a three-level matching strategy that first matches using both source-line range and code prefix, then falls back to source-line range alone, and finally code prefix alone. These temporal edges preserve correspondences between program elements across revisions, allowing the framework to track how code evolves rather than treating each revision in isolation.
The resulting temporal subgraph combines intra-revision structural edges with cross-revision temporal edges, yielding seven distinct edge types: CFG forward and backward, DFG forward and backward, LINEMAP, and temporal forward and backward. A graph encoder learns a separate bias for each edge type, so structural and temporal relationships remain distinguishable during message passing.
From Line Localization to Commit Attribution
In the first learning stage, TraceVIC ranks traced lines by how likely their histories are to contain the true vulnerability-inducing commit. A line receives a positive label if its candidate chain contains the ground-truth VIC. The model extracts the representation of each traced-line node and uses a RankNet scoring head to assign scores. At inference, the top-k lines are passed to the second stage.
The second stage is where the contribution-based ranking happens. For each candidate commit, TraceVIC collects all encoded nodes across the selected temporal subgraphs. It distinguishes between two types of nodes: correspondence nodes, which are connected to adjacent revisions by temporal edges and carry evolutionary information, and local nodes, which have no temporal correspondence and capture revision-specific structure.
Rather than pooling both types identically, TraceVIC uses attention with two separate learnable query vectors: one for correspondence nodes and one for local nodes. This correspondence-aware attention allows the model to preserve the distinction between cross-revision evolutionary information and revision-local structural information when building a commit representation. The resulting sequence of commit representations is processed by a two-layer Transformer encoder, and a ranking head assigns a scalar score to each candidate commit.
The training protocol is sequential. The graph encoder and line-ranking head are trained first using a pairwise ranking objective. After convergence, the graph encoder is frozen, and the commit-ranking components are trained using a combination of focal cross-entropy loss to handle class imbalance and a margin loss that encourages the ground-truth VIC to receive a score at least delta greater than other candidates.
Experimental Results
TraceVIC is evaluated on manually validated vulnerabilities from the Linux kernel. The dataset originally contains 1,349 instances. After filtering out oversized files, assembly files, missing repository files, and cases with no constructable candidate chain, the evaluation set contains 780 vulnerabilities. After removing duplicates, 755 cases are used for training and evaluation under 5-fold cross-validation.
Against state-of-the-art retrieval-based methods, TraceVIC improves F2 by 23.1 percent at top-3. Against selection-based methods, the improvement is 17.3 percent. Against ranking-based methods, it is 28.7 percent. The strongest retrieval baseline achieves an F2 of 0.637 when modeling a single revision; the same approach with full revision history modeling reaches 0.814.
Generalization is tested on 79 vulnerabilities from four unseen C/C++ projects: FFmpeg, ImageMagick, OpenSSL, and PHP-SRC. Without any training on these projects, TraceVIC identifies at least one valid VIC for 78 of the 79 vulnerabilities. The overall metrics are precision 0.855, recall 0.839, F1 0.847, and F2 0.842. Compared with the strongest baseline on this dataset at F1 of 0.700, TraceVIC achieves a 21.0 percent improvement in F1.
The ablation study confirms that the primary benefit comes from reasoning over the full revision history. Adding explicit cross-revision correspondences provides an additional recall-oriented improvement, indicating that temporal modeling helps recover inducing commits that would otherwise be missed.
Handling Addition-Only Fixes
A practical challenge is that some vulnerabilities are repaired entirely by adding previously missing code, leaving no deleted line to trace. In the dataset, 24.2 percent of cases are addition-only fixes. Conventional deletion-based tracing produces no candidates for these cases.
TraceVIC handles this through anchor-line extraction. For each contiguous block of added lines, it extracts up to three anchors from the pre-fix revision: the nearest meaningful lines above and below the insertion point and the enclosing function signature. These anchors initiate the same history-tracing procedure used for deleted lines. Multiple anchor types are extracted because no single neighboring line is reliable across fixes. For a missing guard, the operation requiring protection may sit either above or below the inserted check, and only one of the two may carry the relevant history. Extracting complementary anchors recovers the vulnerability-relevant history in cases where any individual anchor would fail.
Limitations and Practical Considerations
The paper evaluates TraceVIC primarily on C/C++ systems, where low-level memory and pointer operations make vulnerability attribution particularly challenging. The approach has not been validated on languages with different memory models or on vulnerabilities with different characteristics such as logic flaws or configuration errors.
The computational cost is significant. Building temporal Code Property Graphs requires reconstructing compilation contexts for each revision, extracting ASTs, computing control and data flow, and performing node correspondence matching across all candidate revisions. The graph encoding and ranking add further overhead. This makes TraceVIC more suitable for offline analysis than real-time deployment, though the paper does not provide detailed timing measurements.
The model is trained on Linux kernel vulnerabilities and evaluated on Linux kernel plus four additional projects. Generalization to entirely different software ecosystems, such as web applications or scripting languages, remains unverified. The anchor-line extraction for addition-only fixes, while effective, adds complexity and may not cover all edge cases.
There is also a dependency on the availability of manually validated ground-truth VICs for training. The paper uses expert-validated labels rather than SZZ-generated ones, which are more reliable but also more expensive to produce. Scaling to larger datasets without manual validation remains an open challenge.
What This Means for Practitioners
For security teams and vulnerability researchers, TraceVIC offers a concrete tool for identifying the origin of vulnerabilities in C/C++ codebases. Accurate VIC identification supports downstream tasks such as remediation, affected-version identification, and training better vulnerability detection models. The publicly available code and trained models lower the barrier to adoption.
For the broader software engineering community, the paper reframes a long-standing problem. Rather than asking where in the revision history the vulnerability-inducing commit is likely to be, the more productive question is what change contributed most to the vulnerable condition. The temporal graph approach provides a principled way to answer this question by reasoning over code evolution rather than relying on positional heuristics that can be systematically wrong.
The approach also highlights a general lesson for code analysis: the evolution of code matters as much as the code itself. A change that looks innocuous in isolation may create a vulnerable condition when combined with subsequent modifications. Modeling this temporal dimension, rather than analyzing revisions independently, is essential for understanding how vulnerabilities originate.