Vulnerability-Contributing Commits Overview

Updated 13 January 2026

Vulnerability-Contributing Commits (VCCs) are atomic code changes in version control that are later linked to exploitable vulnerabilities, emphasizing historical causality.
They employ methods like the SZZ algorithm, context-based mappings, and noise filtering techniques such as ESC to enhance detection accuracy and dataset quality.
VCC datasets empower secure development pipelines by enabling machine learning models, refined static analysis benchmarks, and proactive vulnerability triage in CI/CD systems.

A Vulnerability-Contributing Commit (VCC) is the atomic code change in a version control system that—when identified retrospectively—can be demonstrated to have introduced, directly or indirectly, code responsible for a subsequently exploitable vulnerability. VCCs are recognized as critical analysis units in secure software engineering, underpinning both empirical vulnerability benchmarking and learning-based vulnerability detection frameworks. Their rigorous identification, dataset construction, evaluation, and exploitation in automated vulnerability assessment and triage comprise an active domain at the intersection of software engineering, static analysis, and applied machine learning.

1. Formal Definitions and Identification Procedures

The defining property of a VCC is historical causality: it is the commit whose code introduction or modification later forms the locus of a CVE-remediating fix. Formally, let $C = \{C_1, ..., C_n\}$ denote a Git repository’s commit history; given a vulnerability-fix commit $C_f$ , the set of lines $L^-$ deleted by $C_f$ are mapped (via git blame) to the earliest commit(s) $C_k$ that last introduced those lines. Each such $C_k$ is designated a VCC. Alternative equivalent definitions appear across the literature:

Line-Based SZZ Formulation: For each $l \in L^-$ , $\operatorname{blame}(l, \operatorname{parent}(C_f))$ yields $C_k$ . The union over all $l$ gives the VCC set for $C_f$ (Lu et al., 13 May 2025, Wu et al., 7 Jan 2025). If $C_f$ adds but does not remove vulnerable code (e.g., for newly introduced features), context line mapping is invoked.
Function- and Hunk-Aware VCCs: In post-2024 works, VCC granularity is further refined by intersecting modified functions in VCC and fixing commits, establishing not only which commit but which specific function is “vulnerable” (Charoenwet et al., 2024).

The SZZ algorithm remains the canonical tool for automated VCC discovery, implemented in various systematizations (Lu et al., 13 May 2025, Charoenwet et al., 2024). Enhancements such as multi-hunk, context-based, and path-sensitive blame aim to ameliorate limitations in detecting subtle or inter-procedural vulnerabilities.

2. VCC Dataset Construction and Quality Assurance

The accuracy and utility of VCC datasets depend critically on robust linking of CVEs, fix-commits, and their traced “culprit” commits. Exemplary methodologies exhibit the following stages and safeguards:

Filtering and Normalization: Restriction to projects/languages of interest (e.g., C/C++), requirement of explicit CWE mapping, and buildability validation are necessary to ensure relevance and consistency (Charoenwet et al., 2024, Lu et al., 13 May 2025).
Noise Mitigation via ESC: The Eliminate Suspicious Commit (ESC) technique in ICVul exemplifies quality filters: flagging fix commits that are themselves blamed, those mapping to multiple CWEs, merge or unclear messages, and outliers by modified function count. ESC filtering has removed 9.6% of reachable fix commits and 23.8% of functions, demonstrably improving labeling integrity (Lu et al., 13 May 2025).
Relational Dataset Schemas: Datasets store VCC–fix mapping, function/file-level metadata, and vulnerability labels in normalized schemas to support scalable research (Lu et al., 13 May 2025).

The result is ground truth datasets (e.g., ICVul, CommitVulFix) with thousands of rigorously evidenced CVE–fix–VCC tuples, where functions, files, and precise code hunks can be definitively labeled as vulnerable or non-vulnerable.

3. Empirical Characteristics and Limitations

Empirical studies reveal both the strengths and persistent limitations of current VCC identification and exploitation:

Metric/Aspect	Value / Observation	Source
Median VCC-per-CVE	Typically 1–2 (C/C++), higher in large/legacy projects	(Charoenwet et al., 2024)
Function-level vulnerability	1,060 of 34,541 changed functions confirmed vulnerable	(Charoenwet et al., 2024)
High-label quality (post-filtering)	41% of changed functions in ICVul labeled as vulnerable	(Lu et al., 13 May 2025)
ESC-filter: impact	Removes ≈24% of candidate functions, reduces multi-CWE and merge noise	(Lu et al., 13 May 2025)
Manual validation	85% true positive VCC rate in Java (DeepCVA)	(Le et al., 2021)

A key limitation is SZZ’s sensitivity to code churn, file renames, and non-semantic changes, which may cause both false positives (non-security bug fix) and false negatives (missed VCCs especially in multi-file/inter-procedural fixes). Additionally, some vulnerabilities are fixed by code addition rather than deletion, which challenges line-based tracing (Wu et al., 7 Jan 2025).

4. Automated Detection and Assessment Using VCCs

VCCs underpin a variety of empirical and learning-based vulnerability detection and assessment pipelines:

Static Analysis Benchmarks: SAST tool evaluation uses VCC datasets to establish whether tools can warn on true vulnerable lines/functions in VCCs. For example, Flawfinder flagged at least one vulnerable function in 52% of VCCs, but 22% of VCCs went undetected, and 76% of SAST warnings in VCCs were irrelevant (false positives) (Charoenwet et al., 2024). Warning-based prioritization can increase reviewer precision by 12% while reducing review effort (IFA) by 13%.
Machine Learning for VCC Classification: Recent systems (e.g., CLNX, DeepCVA, CommitShield) utilize deep learning and LLMs for VCC identification and assessment:
- CLNX bridges C/C++ patch commits and LLMs via structure- and token-level naturalization. CodeBERT + CLNX achieved 75.2% precision and 60.6% F1 in VCC detection, outperforming prior work and static tools (Qin et al., 2024).
- DeepCVA performs multi-task joint prediction of seven CVSS v2 metrics for each VCC, achieving up to 59.8% higher MCC than previous baselines (Le et al., 2021).
- CommitShield combines static program analysis (Tree-sitter, Joern) and expanded natural language context as LLM prompts, reaching up to 0.81 precision and 0.88 F1 in fix detection, and 0.74 precision, 0.82 recall, 0.78 F1 for VID (Wu et al., 7 Jan 2025).
Database-Driven Analysis: ICVul provides schema-mapped function/file-level metadata, supporting fine-grained review and enabling JIT prediction paradigms (Lu et al., 13 May 2025).

5. Applications in Secure Development Pipelines

VCC knowledge is foundational for both retrospective insight and proactive secure development:

Reviewer Guidance: By prioritizing code review to lines/functions implicated in VCCs or flagged by SAST, developers can reduce false negatives and total review effort (Charoenwet et al., 2024).
Vulnerability Prediction Models: VCCs support both “one-shot” learning from past vulnerabilities and just-in-time (JIT) models that score new commits for VCC-likeness, surfacing risk in CI/CD (Lu et al., 13 May 2025).
Dataset Development for Learning: Function-, file-, and commit-level VCC annotations enable robust, reproducible evaluation in machine learning for vulnerability detection (Qin et al., 2024, Lu et al., 13 May 2025).
Severity and Triaging: Commit-level assessment of VCCs (e.g. DeepCVA’s mapping to CVSS metrics) facilitates automated triage, prioritization, and response (Le et al., 2021).

A plausible implication is that further improvements in VCC identification, especially for subtle, distributed, or context-dependent vulnerabilities, could substantially enhance the real-world efficacy of secure development pipelines.

6. Methodological Challenges, Evaluation, and Open Issues

Key methodological and evaluation aspects include:

Ground Truth Uncertainty: SZZ lineage tracing–while standard–is not infallible and is less reliable for code with frequent refactoring, ambiguous intent, or insufficient historical data (Lu et al., 13 May 2025, Wu et al., 7 Jan 2025).
Label Quality Assurance: Manual audits (e.g., 85% true positive rate in DeepCVA) remain essential for dataset credibility, but scale poorly (Le et al., 2021).
Cross-Language and Domain Generalizability: Approaches validated in one language (Java or C/C++) may not transfer cleanly to others (e.g., Rust, embedded C) due to differences in construct expressivity, code idioms, and project histories (Qin et al., 2024).
Threats to Validity: Several works cite threats from data selection, bias in negative sampling, and dependency on specific LLMs or static tools. Mislabeled negatives or multiple distinct VCCs per CVE can distort precision/recall/F1 evaluations (Wu et al., 7 Jan 2025).

Open challenges include: reducing high SAST false positive rates, context-aware selection of SZZ parameters for diverse repository characteristics, and integrating richer, graph-based code representations to resolve complex inter-procedural or multi-file VCCs. Future research directions encompass development of more precise severity assessment, ensemble detection heuristics, and extension to new language ecosystems (Charoenwet et al., 2024, Lu et al., 13 May 2025).