PaperlayerView exact revision on arXiv

Source-linked AI summary

TraceVIC: Causal Reasoning over Code Evolution for Identifying Vulnerability-Inducing Commits

Fnu Tanish, Samiha Shimmi, Samikshya Chapagain, Hamed Okhravi, Mona Rahimi, Lei Zhang

arXiv:2609.26711v1cs.SEcs.AI

TL;DR

VIC identification is difficult because vulnerabilities may be discovered long after introduction and relevant code can evolve across revisions, while existing approaches often choose the earliest or latest modification. TraceVIC models that evolution in temporal graphs and ranks candidate commits by contribution to the vulnerable condition. It improves on existing baselines and identifies a valid VIC for 78 of 79 vulnerabilities across four unseen C/C++ projects.

  • Problem

    Existing VIC methods trace relevant code but often use earliest/latest positional heuristics, although vulnerable behavior can evolve across revisions and the true inducing commit may occur anywhere in the history.

    Source: §1 · pp. 1–2

  • Method

    TraceVIC builds temporal graph representations of vulnerability-relevant code across revisions, localizes likely root-cause lines, and ranks candidate commits by their contribution to the vulnerable condition.

    Source: §1 · p. 2

  • Results

    At top-3, TraceVIC improves F2 by 23.1%, 17.3%, and 28.7% over the strongest retrieval-, selection-, and ranking-based baselines, respectively, and identifies a valid VIC for 78 of 79 vulnerabilities across four unseen C/C++ projects.

    Source: §1 · p. 2

  • Takeaways & Limitations

    The ablation results show that modeling the full revision history provides the primary improvement over single-revision analysis, with explicit cross-revision correspondences providing additional gains.

    Source: §1 · p. 2, §9 · p. 13

    TraceVIC traces code associated with the fixing region, so relevant context outside that region may be missed; addition-only fixes also make anchor selection uncertain.

    Source: §8 · p. 13

Abstract

from arXiv · show

Software vulnerabilities are often discovered long after they are introduced, making it difficult to identify the vulnerability-inducing commit (VIC) responsible for introducing the underlying vulnerable condition. Existing VIC identification techniques largely rely on git blame to trace vulnerable code through revision history and use positional heuristics, such as selecting its earliest or most recent modification. However, the true VIC may occur anywhere within this history, and vulnerable behavior may depend on code that evolves across multiple revisions. We therefore argue that VIC identification requires reasoning about how vulnerability-relevant code evolves, rather than simply where a candidate commit appears in the revision history. We present TraceVIC, a temporal graph-based approach for identifying and ranking VICs by reasoning over code evolution. TraceVIC first localizes likely root-cause lines and traces their histories across revisions, constructing graph representations that capture program structure within each revision and the evolution of vulnerability-relevant code across the history. It reasons over the resulting revision history, using temporal edges to preserve correspondences between program elements across consecutive revisions, and directly ranks candidate commits according to their contribution to the vulnerable condition. Ablation results show that modeling the full revision history improves F2 from 0.637 to 0.814. TraceVIC improves F2 by up to 28.7% over state-of-the-art methods and identifies a valid VIC for 78 of 79 vulnerabilities across four unseen C/C++ projects.

1 Introduction

VIC identification matters for remediation, affected-version identification, and vulnerability detection, but existing approaches often select the earliest or latest traced modification despite vulnerable behavior evolving across revisions. TraceVIC instead ranks commits by their contribution to the vulnerable condition, using temporal graph representations to model code evolution.

Motivation

  • Vulnerabilities persist for an average of 1,732 days before patching, and incorrect attribution can lead to incomplete fixes, inaccurate affected-version information, and noisy training labels.Source: §1 · p. 1
  • Existing SZZ-based methods select the most recent or earliest modification, but neither positional rule reliably identifies a VIC when relevant code evolves across revisions.Vulnerabilities can remain latent across multiple software versions before discovery.Source: §1 · p. 1

Approach

  • TraceVIC traces relevant code from a fixing commit, models within-revision structure and cross-revision evolution, then ranks root-cause lines and candidate commits by contribution to the vulnerable condition.This contribution-based formulation does not assume a predefined position for the VIC.Source: §1 · p. 2

Ablation study

  • Full-history reasoning raises F2 from 0.637 to 0.814 over single-revision analysis, while explicit cross-revision correspondences provide an additional recall-oriented improvement.Source: §1 · p. 2

Empirical evaluation

  • At top-3, TraceVIC improves F2 by 23.1%, 17.3%, and 28.7% over the strongest retrieval-, selection-, and ranking-based baselines, respectively.The evaluation uses manually validated Linux kernel vulnerabilities.Source: §1 · p. 2

Generalization

  • For 79 vulnerabilities across four unseen C/C++ projects, TraceVIC identifies at least one valid VIC for 78 and achieves F1=0.847, a 21.0% improvement over the strongest baseline (F1=0.700).The projects are FFmpeg, ImageMagick, OpenSSL, and PHP-SRC; TraceVIC was not trained on them.Source: §1 · p. 2

2 A Motivating Example for CVE-2014-2309: Why Positional Reasoning Fails?

The CVE-2014-2309 example shows why the true vulnerability-inducing commit need not be at either end of a traced history. Ranking candidates by their semantic contribution can identify an intermediate commit that positional heuristics miss.

Positional reasoning

  • Existing SZZ-based approaches choose the earliest or latest modification, although the true VIC can occur anywhere in the history.Source: §2 · p. 3

CVE-2014-2309

  • In CVE-2014-2309, commit 957c665 changes allocation semantics so route entries bypass accounting, creating the vulnerable condition; later commits preserve and evolve that behavior.The ground-truth VIC is in the middle of the history chain.Source: §2 · p. 3, Figure 1 · p. 3

Why positional reasoning fails

  • Because B-SZZ favors later changes and V-SZZ earlier ones, the example motivates ranking candidates by which change introduced the vulnerable condition.The ranking places 957c665 above the other commits in the history.Source: §2 · p. 3

3 Problem Formulation

The paper formulates VIC identification as contribution-based ranking over candidate histories rather than selection by temporal position. Histories begin from lines associated with the fixing commit, with anchors used when a fix adds code only.

Tracing inputs

  • For deletion-involving fixes, history tracing starts from deleted lines; for addition-only fixes, TraceVIC uses nearby pre-existing code as anchors.Addition-only fixes make up 183 of 755 cases (24.2%) in the dataset, for which deletion-based tracing yields no candidates.Source: §3 · p. 3

Anchor-line extraction

  • For addition-only fixes, anchors initiate tracing but are not themselves treated as VICs; the traced commits are subsequently evaluated and ranked.Complementary anchors can reach relevant histories when the defect structure makes one neighboring line uninformative.Source: §3 · pp. 3–4

Candidate histories

  • For each traced line, TraceVIC follows its modification history backward to form a candidate commit chain, retaining per-chain context when a commit appears in multiple chains.The overall candidate set is a multiset union of the chains.Source: §3 · p. 4

VIC definition

  • TraceVIC defines a VIC as the commit that introduces or modifies program semantics creating the vulnerable condition addressed by the fixing commit.A commit that merely exposes an existing vulnerability, or adds code later involved in it without creating the condition, is not the VIC.Source: §3 · p. 5

Ranking objective

  • The identification task is to score candidate commits and select the highest-scoring one as the predicted VIC.A commit may receive contributions from all chains in which it appears.Source: §3 · p. 5

Contribution-based formulation

  • TraceVIC learns commit scores from temporal-structural representations, so revision order supplies evolutionary context without imposing an earliest- or latest-change rule.Source: §3 · p. 5

4 Temporal-Structural Representation

TraceVIC represents each candidate history as a temporal graph built from revision-level code structure and links between corresponding code across revisions. The resulting graph preserves both within-revision relationships and the evolution of traced code for downstream scoring.

4.1 Revision-Level Structure

  • For each traced line, TraceVIC retrieves its candidate history, constructs a CPG for the associated file at each commit, and restricts it to code changed by that commit.Source: §4.1 · p. 5
  • Revision-level CPGs use AST-level program units augmented with control- and data-flow dependencies, retaining relationships among nodes overlapping changed lines.The implementation reconstructs compilation context to parse C/C++ accurately.Source: §4.1 · p. 5

4.2 Cross-Revision Node Correspondence

  • Across consecutive revisions, TraceVIC matches traced-code nodes using line range and code prefix, then falls back to either criterion alone when needed.If a CPG exists but no corresponding node is identified, no temporal edge is added; an empty CPG receives a synthetic node to preserve the revision.Source: §4.2 · pp. 5–6

4.3 Temporal Subgraph Formation

  • Each line’s temporal subgraph retains intra-revision CFG, DFG, and LINEMAP relationships and adds bidirectional temporal edges between corresponding code across revisions.Separate edge-type biases keep structural and temporal relationships distinguishable during message passing.Source: §4.3 · p. 6
  • TraceVIC builds a separate temporal subgraph for each traced line and assigns its traced-code node index 0 for subsequent line-level scoring.Source: §4.3 · p. 6

5 Learning Framework

TraceVIC uses a shared graph encoder in two sequential stages to localize vulnerability-relevant lines and rank candidate commits. Its representations combine within-revision structure with code evolution across revisions.

5 Learning Framework

  • The two sequential stages share a graph encoder, which is trained for line ranking and then frozen for commit ranking.Training uses manually verified VIC labels, so the ranking objective does not impose an earliest- or most-recent-commit rule.Source: §5 · p. 6, §5.4 · p. 7

5.1 Shared Graph Encoder

  • Edge-aware graph attention combines code-element embeddings, commit-position encodings, and typed structural and temporal relationships.The positional encoding preserves revision order as context without requiring the VIC to occur at a particular position.Source: §5.1 · p. 6

5.2 Relevant Line Localization

  • A pairwise RankNet head ranks traced lines by whether their candidate chains contain the ground-truth VIC, passing the top-k lines to commit attribution.Line-level positive labels are assigned when a traced line’s candidate chain contains the ground-truth VIC.Source: §5.2 · pp. 6–7

5.3 Commit-Level Attribution

  • Commit attribution pools nodes by candidate commit, distinguishes temporal-correspondence nodes from revision-local nodes, and uses a Transformer to contextualize the complete candidate history.A scoring head returns the highest-scoring candidate as the predicted VIC; training combines focal cross-entropy and a margin loss.Source: §5.3 · p. 7

5.4 Training Protocol

  • The stages train sequentially: after line localization converges, the shared graph encoder is frozen and only commit-attribution components are trained.UniXcoder’s bottom eight layers are frozen during line localization.Source: §5.4 · p. 7

6 Evaluation

The evaluation compares TraceVIC with retrieval-, selection-, and ranking-based methods, tests the contribution of code-evolution modeling, and assesses transfer to unseen projects. Results cover a manually validated Linux-kernel dataset and four unseen C/C++ projects.

6.1 Dataset and Metrics; 6.2 Experimental Protocol

  • The Linux-kernel evaluation uses manually validated VIC instances, reports Precision@k, Recall@k, F1@k, and F2@k, and emphasizes recall because missing the true VIC is more consequential than extra candidates.Filtering reduced the dataset to 780 vulnerability instances; 25 duplicated VIC-VFC pairs were then removed for the 755-case learning-method protocol.Source: §6.1 · p. 8, §6.2 · p. 8

6.3 Impact of Temporal Modeling (RQ1)

  • Retrieval, selection, and ranking methods are evaluated separately because their outputs differ, and raw metric comparisons across these tasks would conflate different prediction goals.Retrieval returns candidate sets, selection makes one prediction, and ranking orders candidates.Source: §6.3 · p. 8

6.3.1 Retrieval-based Methods

  • Against retrieval-based methods, TraceVIC achieved F1 of 0.741 at @2 and F2 of 0.820 at @3, versus the strongest baseline’s 0.599 and 0.666.At @3, recall reached 0.909 with three ranked candidates.Source: Table 2 · p. 9, §6.3.1 · p. 9

6.3.2 Selection-based Methods

  • For single-commit selection, TraceVIC@1 achieved F1 of 0.732 and F2 of 0.723, the highest among directly comparable methods.Against AgenticSZZ, its F1 rose from 0.695 to 0.732 and F2 from 0.686 to 0.723.Source: §6.3.2 · pp. 9–10, Table 4 · p. 10

6.3.3 Ranking-based Methods

  • Against NeuralSZZ+B-SZZ, TraceVIC@1 raised recall from 0.534 to 0.717 and F1 from 0.615 to 0.732; at @3, F2 was 0.820 versus 0.637.NeuralSZZ’s deletion-line ordering was transferred to commits through SZZ tracing, while TraceVIC ranks candidate commits directly.Source: §6.3.3 · pp. 10–11, Table 5 · p. 11

6.3.4 Ablation: Code-Evolution Modeling

  • At top-3, full-history modeling raised F2 from 0.637 to 0.814 versus a single revision; temporal edges further raised F2 to 0.820.The additional edges increased recall from 0.891 to 0.909 while precision fell from 0.604 to 0.590.Source: Table 6 · p. 11, §6.3.4 · p. 11

6.4 RQ2: Generalizability

  • The unseen-project dataset excludes Linux-kernel cases used for training and covers FFmpeg, ImageMagick, OpenSSL, and PHP-SRC; performance varied across projects.FFmpeg had F1@3 of 0.912, while PHP-SRC had F1 of 0.765.Source: §6.4 · pp. 11–12
  • TraceVIC identified at least one valid VIC for 78 of 79 vulnerabilities across four unseen C/C++ projects and achieved F1 of 0.846 versus TSE-SZZ’s 0.695.The 79 cases have 135 ground-truth VICs, so the evaluation reports both CVE-level success and commit-level metrics.Source: Table 8 · p. 12, §6.4 · p. 12

7 Related Work

VIC research has progressed from SZZ heuristics to learning-based and history-aware methods, but prior approaches generally do not directly rank candidates by their contribution across code evolution.

7.1 SZZ Algorithms and Variants

  • TraceVIC replaces predefined SZZ history heuristics with evolution-sequence modeling and direct ranking of candidate commits.Earlier variants use filtering, recency, change-size, or earliest-modification heuristics.Source: §7.1 · p. 13

7.2 Learning-Based SZZ Approaches

  • Learning-based approaches add structural or semantic reasoning, but do not explicitly model code evolution across candidate sequences for direct commit ranking.NeuralSZZ ranks root-cause lines; LLM4SZZ ranks suspicious statements; LLM-SZZ ultimately selects the earliest reached commit.Source: §7.2 · p. 13

7.3 Temporal Reasoning over Code History

  • FONTE relies on runtime test coverage, AgenticSZZ reasons over a temporal knowledge graph, and CommitShield classifies individual commits.These approaches incorporate history but differ from TraceVIC’s target and representation.Source: §7.3 · p. 13
  • TraceVIC models vulnerability-relevant code evolution using within-revision structure and cross-revision correspondences, then ranks candidates without an earliest- or most-recent-commit rule.This contrasts with approaches that use history without directly ranking candidate VICs over the evolution of the vulnerable code.Source: §7.3 · p. 13

8 Threats to Validity

The evaluation is bounded by fixing-region-based tracing, uncertainty in ground truth and candidate construction, and the tested repositories and languages.

Internal Validity

  • Tracing focuses on deleted lines or nearby anchors, so relevant context outside the fixing region may be missed.Broader context introduced false positives and reduced precision in experiments; addition-only fixes can omit relevant histories or introduce unrelated candidates.Source: §8 · p. 13

Construct Validity

  • Evaluation inherits possible ground-truth attribution errors and may favor vulnerabilities with cleaner revision histories.Different output forms across methods may also affect cross-method comparisons despite separate evaluation.Source: §8 · p. 13

External Validity

  • The evaluation centers on Linux vulnerabilities and four unseen C/C++ projects, so findings may not generalize to other languages or ecosystems.Coding practices, commit granularity, and vulnerability-report quality may also affect performance.Source: §8 · p. 13

9 Conclusion and Future Work

The paper reformulates VIC identification as reasoning over code evolution and presents TraceVIC, a temporal-structural framework for modeling vulnerability-relevant code across revisions.

Conclusion

  • TraceVIC replaces positional commit selection with a temporal-structural framework that models vulnerability-relevant code across revisions.The formulation evaluates commits through code evolution rather than revision-history position.Source: §9 · p. 13
  • Ablations show that multi-revision reasoning provides the primary improvement over single-revision analysis, with explicit cross-revision correspondences adding further gains.The conclusion attributes the main improvement to the broader evolution history.Source: §9 · p. 13

Conclusion and Future Work

  • TraceVIC outperforms retrieval-, selection-, and ranking-based methods and generalizes to unseen C/C++ projects.Future work targets interacting inducing commits, large refactorings, and languages beyond C/C++.Source: §9 · p. 13

Ethical Considerations

The study analyzes publicly available source code, commit histories, and previously disclosed vulnerabilities without human participants or interaction with deployed systems.

Ethical Considerations

  • The study uses public code, commit histories, and previously disclosed vulnerabilities, with no human participants or deployed-system interaction.These are the stated materials and setting of the analysis.Source: Ethical Considerations · p. 16
  • The principal ethical concern is the potential dual use of vulnerability-history analysis.The paper identifies dual use as its central ethical consideration.Source: Ethical Considerations · p. 16
  • The authors mitigate dual-use risk by evaluating only disclosed vulnerabilities and withholding undisclosed vulnerability and exploit information.The stated mitigation is limited to the evaluation and release choices described.Source: Ethical Considerations · p. 16

Open Science

The paper makes its evaluation artifacts and reproduction materials available through an anonymous repository.

Open Science

  • The anonymous repository provides the end-to-end VIC identification implementation, including CPG construction, the graph-attention encoder, and CommitTransformer.Source: Open Science · p. 16
  • Preprocessed benchmark datasets and evaluated model checkpoints are available for direct reproduction without retraining.Source: Open Science · p. 16
  • Evaluation scripts, configuration files, and instructions support reproducing all reported experimental results.Source: Open Science · p. 16

A Dataset Filtering

This material documents dataset filtering, graph construction and attribution components, addition-only anchor handling, and computational cost. It reports a runtime comparison on 755 Linux kernel cases.

A Dataset Filtering

Compilation Context Reconstruction

C Node Correspondence Matching

  • Node correspondence matches history entries by line range plus code prefix, then by line range, then by code prefix; unmatched revisions omit temporal edges, while empty CPGs receive synthetic nodes.The code-prefix length is λ = 20 characters.Source: C Node Correspondence Matching · p. 17

D Evaluation Metrics

  • Root-cause-line evaluation reports precision, recall, and F1 at ranks 1, 2, and 3, defining precision and recall over the top-k ranked lines.Source: D Evaluation Metrics · p. 18

E Graph Encoder Equations

G Addition Cases Structural Pattern

  • For addition-only fixes, TraceVIC extracts up to three neighboring or function-signature anchors, filters boilerplate, maps anchors to pre-fix coordinates, and treats them as synthetic deletions for candidate-chain construction.Source: G Addition Cases Structural Pattern · p. 19
  • In addition-only examples, both anchors match an independent maintainer attribution in one case, while two surviving anchors agree on a single candidate in another.Source: G Addition Cases Structural Pattern · p. 20

H Computational Cost

  • 4.4 minutes (0.35 seconds per case) ranks all 755 cases, versus 10.8 hours for AgenticSZZ and 28.7 hours for LLM4SZZ, speedups of roughly 147× and 391×.TraceVIC caches graph construction and node encodings per repository revision, then ranks each vulnerability with one forward pass over cached temporal subgraphs.Source: H Computational Cost · p. 20

I Failure Analysis

Failure analysis links TraceVIC’s errors mainly to structural changes that obscure the vulnerability signal, with large deletions and refactoring among the recurring patterns.

I Failure Analysis

  • Among 21 analyzed Linux-kernel failures, large-deletion fixes were the most common pattern (7 cases, 1.1%), followed by large refactoring with the fix (6 cases, 0.9%).Later-refactoring propagation accounted for 3 cases (0.4%); code movement and downstream extensions each accounted for 2 cases (0.3%).Source: I Failure Analysis · p. 20
  • Fixes deleting 16 or more lines can bury the semantically critical line in non-root-cause deletion noise.Source: I Failure Analysis · p. 20
  • Major cleanup or refactoring alongside a fix can produce stronger representational signals than the vulnerability fix, allowing refactoring deletions to outrank the root cause.Source: I Failure Analysis · p. 20
  • Line reordering, later refactoring, and downstream extensions can obscure the origin through stronger structural or contextual similarity to the fixing commit.The paper identifies robustness to structural changes as a future-work target.Source: I Failure Analysis · pp. 20–21

Related papers

Loading 2609.26711v1…