Introduction
Traditionally, vulnerability detection relied on manual code reviews and security audits, both labor-intensive and time-consuming practices. However, in the past decade, researchers have developed increasingly sophisticated approaches to automate this process. Automated Vulnerability Detection (AVD) now represents a potentially transformative advancement in software security, aiming to identify and support the remediation of security flaws within codebases.
AVD approaches have evolved from rule-based methods to machine learning-based solutions (ML4AVD), including deep learning and large language model (LLM)-driven techniques that now dominate more recent literature. Despite this sustained effort, the self-reported performance of ML4AVD solutions does not exhibit a clear upward trend.
| Dataset | Theil–Sen slope of F1 per year | 95% CI |
|---|---|---|
| Devign / CodeXGLUE | 0.003 | [−0.016, 0.021] |
| ReVeal | 0.013 | [−0.054, 0.068] |
| Big-Vul | 0.002 | [−0.275, 0.089] |
Appendix A. The results show that even self-reported performances for each dataset do not exhibit a clear upward trend as the confidence intervals for all three datasets include 0. Of the 87 articles reviewed in our survey, 28 reported the F1-score on at least one of the aforementioned datasets.
This demonstrates that even when working with the same dataset, measuring progress between papers is difficult as they apply different pre-processing steps and evaluation methodologies. More fundamentally, the ML4AVD field has become increasingly siloed, with studies often focused on isolated tasks and a narrow range of languages. A key driver is the disproportionate influence of a small number of highly cited works that shape the choices of subsequent research: which datasets to use, which problem formulations to adopt, and which evaluation protocols to follow.
Consequently, flawed assumptions embedded in foundational ML4AVD work are uncritically adopted by follow-up work and are propagated widely through the literature.
What are the key limitations of ML4AVD research that emerge from highly cited papers in the field, how do they interact, and what do they imply for future work?
Many of these issues have been raised individually in prior work, but their dissemination through the ML4AVD community is uneven, and their interactions remain underexplored. Our contribution is an integrated diagnosis: we show that the pain points are co-occurring and mutually reinforcing, that the feedback loops between them explain the state of the field better than any individual limitation, and that targeted fixes are therefore insufficient without breaking those loops.
Background
Vulnerability Management Life Cycle
Vulnerability detection does not exist in isolation; it is the first stage in a broader vulnerability management life cycle. This life cycle mirrors industry standards such as ISO 30111 and NIST SP 800-61.
Detection
Identifying vulnerable code within the codebase. The utility of detection depends not only on whether a vulnerability is found but also on the richness of the information provided.
Triage
Prioritizing detected vulnerabilities based on their likely impact and urgency. Effective triage requires more than a binary detection signal, as severity depends on contextual factors such as vulnerability type, affected assets, reachability, exploitability, and potential “blast radius”.
Exploitation
Validating the existence of a vulnerability by constructing a reproducible exploit. Although significantly more costly than detection, the exploitation phase eliminates false positives and yields a reusable test case to validate subsequent repair.
Repair
Applying a patch to remediate the vulnerability while preserving existing functionality. Detection informs repair by localizing the affected code, while exploitation provides the test cases needed to verify that the repair is effective.
Validation & Testing
Confirming that the patch has been applied successfully. Ensures that the vulnerability has been removed without degrading application functionality or introducing new vulnerabilities.
Program Analysis
Vulnerability detection is a branch of program analysis, the process of determining a program’s properties. However, static analysis of complex programs can be computationally expensive, and determining statically whether an arbitrary program is free of vulnerabilities is undecidable. Therefore, static AVD methods require approximation to be practical, leading to diverse approaches with different trade-offs. As universal approximators, neural networks have been increasingly applied to this setting.
Program Representation
Input and output granularity
ML4AVD solutions typically take a code snippet, the size and complexity of which determine the input granularity, to produce information about the presence and location of vulnerabilities; the level of detail at which solutions label the location of vulnerabilities determines the output granularity. In the literature, input and output granularities range from the project-level (the coarsest) to line-level (the finest).
Program slices
Subsets of code, possibly non-contiguous, that preserve the behavior of the full program with respect to a specified slicing criterion, such as the value of a variable at a particular program functionality. In the context of AVD, slicing is used as a preliminary step to simplify further analysis by excluding unrelated code in the resulting feature space.
Vectorization
A numeric representation of source code so it can be used as input to ML-based AVD solutions. In recent research, the most prevalent vectorization method is generating embeddings at the word, sub-word, or sentence level to capture code semantics.
Intermediate representations (IRs)
Compiler-oriented abstractions of source code, developed to support program analysis and optimization, that are now widely used beyond compilation. Code property graphs (CPG) combine information from the AST, CFG, and PDG into a single structure.
ML Approaches used for AVD
Convolutional Neural Networks (CNN)
Neural networks developed for grid-like data (e.g., images). CNNs apply learnable filters (called kernels) to sliding windows of the data and match patterns through a convolution operation.
Recurrent Neural Networks (RNN)
Neural networks designed primarily for sequential data. The core component of an RNN is the recurrent cell. It keeps a hidden state summarizing past inputs, enabling RNNs to learn what information to retain or forget.
Graph Neural Networks (GNN)
Neural networks that support learning from graph structures, where the information of each node is represented as a vector. GNNs can be applied to graphs irrespective of their dimensions (e.g., the number of nodes or edges).
Large Language Models (LLM)
Transformer-based neural networks that model natural language with a high number of parameters, from hundreds of millions to trillions. LLMs can be general purpose (e.g., ChatGPT) or specialized in a field (e.g., CodeBERT).
Methodology
Our methodology is designed to capture work that has had measurable influence on the field, rather than provide an exhaustive census of all AVD research. We searched four research databases that cover the vast majority of research venues in both the security and machine learning fields: IEEEXplore, ACM Digital Library, ScienceDirect, and arXiv. We applied the following search criteria: (i) The article title must include either “vulnerability detection” or “vulnerability discovery”, and (ii) The body of the article must include “software”. The cutoff is September 2024 to allow for the citation count, which we use in subsequent filtering, to stabilize.
Five reviewers screened the collected papers for topic relevance, with two reviewers per paper. Using these criteria, we reduced the selection to 395 articles and 76 empirical studies. We calculate citation frequency Rc for each article as Rc = Nc/A, where Nc is the number of citations achieved by an article as recorded in September 2025, and A is the article’s age in years from first publication or pre-print. As cited computer science articles had a mean of five citations after one year from publication, we set a threshold of Rc ≥ 5, resulting in 124 articles.
Although older articles have had more time to accrue citations, the publication-year distribution does not suggest that the citation-frequency threshold systematically favored older work. Newer surveys, datasets, and empirical studies are not included in the citation-filtered corpus. Instead, we incorporate them into the discussion where they help identify, corroborate, or refine the pain points and recommendations.
Systematization of AVD Literature
To inform our discussion of identified limitations, we first characterize the 87 influential ML4AVD articles in our corpus according to six key dimensions: problem formulation, input and output granularity, programming languages, evaluation metrics, datasets, and ML approaches. For each dimension, we report the distribution of choices made across the corpus. Papers may appear in multiple categories if they meet the criteria for each category.
Six key dimensions
Problem Formulation
All studied articles viewed AVD as a classification problem, with two prevalent formulations. (i) Binary: the ML4AVD solution returns whether the input software is vulnerable or not, without specifying the vulnerability type. (ii) CWE-ID: the ML4AVD solution returns the type of vulnerability (often represented by the Common Weakness Enumeration identifier, or CWE-ID) to which the input software is vulnerable, if any.
The binary formulation dominates the literature with 86% of the included articles. However, this dominance is not uniform over time, as CWE-based formulations become more prevalent starting in 2022, suggesting an emerging shift toward more informative problem formulations in more recent work.
Show as table
| Formulation | Articles |
|---|---|
| Binary classification | 75 |
| CWE-ID classification | 16 |
Input and Output Granularity
A vast majority (63%) of the solutions provided function-level labeling of function-level inputs. Beyond the function-level, this same-to-same relationship between input and output extends to other granularities, accounting for 82% of all configurations. Two notable articles use the coarsest input granularity, project-level, paired with the finest output granularity, line-level. Project-level inputs are predominantly associated with slice-level outputs, demonstrating the use of program slicing to refine the granularity of the code.
Show as table
| Input | Output | Articles |
|---|---|---|
| Project / executable | Project / executable | 2 |
| Project / executable | Function | 1 |
| Project / executable | Slice | 6 |
| Project / executable | Snippet | 1 |
| Project / executable | Line | 2 |
| Commit | Commit | 3 |
| File | Line | 1 |
| Function | Function | 55 |
| Function | Line | 4 |
| Function | Slice | 3 |
| Function | Snippet | 2 |
| Slice | Slice | 6 |
| Snippet | Snippet | 5 |
Programming Languages
The literature is dominated by works looking at a single language (92%), of which C/C++ is the overwhelmingly most common target (85% of single-language articles). Additionally, all articles that consider multiple languages include C/C++ as one of them. Non-C/C++ single-language articles appear only sporadically, with Java representing the most consistent alternative.
Show as table
| Language(s) | Articles |
|---|---|
| C/C++ | 70 |
| Java | 5 |
| Assembly / binary | 4 |
| JavaScript | 1 |
| PHP | 1 |
| Python | 1 |
| C/C++, Java | 2 |
| C/C++, Python | 1 |
| C/C++, Java, Swift, PHP | 1 |
| C/C++, JavaScript, Ruby, Go, Java, C#, Python | 1 |
Datasets
All of the most common datasets target C/C++ code, and all are at either the function or slice level of granularity. Big-Vul is the only dataset in the top nine to provide labels at more than one granularity, including both function-level and line-level annotations. Furthermore, two of the most widely used datasets (Devign/CodeXGLUE and ReVeal) do not provide CWE-IDs, which may directly contribute to the predominance of binary classification in the literature.
Show as table
| Dataset | Articles |
|---|---|
| Devign / CodeXGLUE | 27 |
| ReVeal | 17 |
| Big-Vul | 17 |
| VulDeePecker | 9 |
| SySeVR | 6 |
| Draper | 5 |
| D2A | 5 |
| µVulDeePecker | 4 |
ML Approaches
RNNs were the dominant approach from 2017 to 2020, reflecting their established capability for modeling sequential data. GNNs superseded RNNs as the dominant approach from 2021 to 2023 and represent 37.9% of all included articles. Finally, LLMs account for 23.0% of articles overall but represent 46.2% of the approaches in 2024 and 2025 articles, demonstrating a sharp and recent shift in the field. LLM-based solutions are applied either through prompting (12 articles) or fine-tuning (8 articles), with one article combining pre-training and fine-tuning.
Show as table
| Approach | Sub-approach | Articles |
|---|---|---|
| GNN | GCN 10, GGNN 7, GAT 5, RGCN 4, other 11 | 33 |
| LLM | Prompting 12, fine-tuning 8, pre-training and fine-tuning 1 | 20 |
| RNN | BLSTM 9, LSTM 7, BGRU 2 | 18 |
| CNN | – | 11 |
| Other | – | 8 |
Evaluation Metrics
The overwhelming majority of the works use the typical metrics for classification: Accuracy, Precision, Recall, False Positive Rate (FPR), and False Negative Rate (FNR). To capture the interaction between Precision and Recall, the F1-score is also frequently reported and is the single most common metric, being used in 68 of the 87 articles; much less frequently, the Precision-Recall Area Under Curve (PR-AUC) is used in two included articles. The Receiver Operating Characteristic Area Under Curve (ROC-AUC) is reported in seven works to show the trade-off between Recall and FPR.
Show as table
| Metric | Articles |
|---|---|
| F1-score | 68 |
| ROC-AUC | 7 |
| PR-AUC | 2 |
Pain Points and Recommendations
Building on the quantitative findings and a selection of empirical studies identified in the literature search, we qualitatively examine the motivations behind these limitations as articulated in the included papers and trace how they propagate through the field. While many of these issues have been raised individually in prior work, no existing source provides an integrated view.
Pain Point 1: Problem formulation focuses on binary classification
AVD is conceptualized as a standalone classification task, with a large focus on binary labels; this limits the value of the research in the wider context of the vulnerability life cycle.
- Description
- On the rare occasion this choice is motivated, it is justified with reference to classification being the prevailing formulation in the field. In this context, binary classification of code into vulnerable or benign classes is considered the de facto default. In contrast, articles that adopt a multi-class formulation motivate it as an improvement over binary classification, as each vulnerability type will have different features.
- Implications
- Although binary formulations are simpler to solve, simply classifying a unit of code as vulnerable does not provide the information required by subsequent steps. Providing the vulnerability type (CWE-ID) supports triage, replication, and repair, whether performed automatically or by a human expert. For this reason, most vulnerability detection tools currently used in industry provide the vulnerability type. Nevertheless, 10 of the 16 articles using CWE-based formulations were published in 2023 or later, suggesting an emerging interest in this more practical formulation.
- Recommendations
- The problem formulation of ML4AVD should take into account the vulnerability life cycle and the role detection plays in it. At a minimum, multi-label classification based on the CWE-ID (or similar) provides information on severity required for triage, which also allows algorithms to learn features specific to each type of vulnerability. Additional information for each vulnerability, such as conditions and code paths that can trigger it, would be valuable for triaging the severity of the vulnerability and replicating it. Furthermore, program analysis techniques such as symbolic execution, concolic testing, and guided fuzzing are complementary to ML4AVD.
Pain Point 2: Granularity does not differentiate between input and output
ML4AVD overwhelmingly uses the same granularity for both input and output, with function-to-function approaches being the majority of the field as a compromise between context and precision.
- Description
- This appears to be the ‘default’ in the literature and indicates that input and output granularities are conflated. Function-level granularities are argued to offer a useful level of detail while still retaining enough context, though this is obviously not always the case, as vulnerabilities that span multiple functions are sometimes discarded, and line-level detection is left as future work. Therefore, it is not surprising that coarser granularities, e.g., commit and slice, are motivated by the need for additional context for classification. In contrast, line-level output granularities are motivated as being more precise and usable.
- Implications
- A same-to-same relationship introduces an artificial trade-off: an increase in granularity that captures more contextual information would produce less specific output and vice versa. Real-world vulnerabilities frequently occur at inter-procedural boundaries where function-level solutions struggle, and a manual expert review of function-level datasets found that vulnerabilities are overwhelmingly context-dependent, most commonly on argument values or the behavior of other functions that are not included in the sample. Function-level granularity also lacks the precision to target subsequent repair, as functions may be arbitrarily complex and thus require significant additional effort to patch the vulnerable code.
- Recommendations
- Future work should separate input and output granularities. For inputs, solutions should include all required context, therefore, targeting project-level input granularity, which is known to produce better results compared to function-level. For outputs, solutions should aim for fine granularity to best inform subsequent steps in the vulnerability life cycle, pointing to one or more specific lines of code and the code paths and conditions required to trigger the vulnerability. Note that solving at a low granularity implicitly solves all higher granularities, as a function containing a vulnerable line is itself vulnerable, and so on, with the additional benefit of better contextualizing any findings. Future work should look to use multi-granularity datasets, such as ReposVul or VulEval.
Pain Point 3: Problem formulation is influenced by available dataset
The availability of function-level datasets and the focus of influential papers on binary classification have implicitly pushed the field into the most common formulation: function-to-function binary classification.
- Description
- The early focus on function-to-function classification has produced many prominent function-level datasets. The choice of dataset in the analyzed literature is sometimes motivated by existing high usage in the field. Creating high-quality datasets requires large time-investments (e.g., “600 hours” or “150 hours”); thus, using available datasets is a significant time-saving choice. Lack of available datasets is cited as a reason for coarse-grained detection and limited line-level baseline comparisons.
- Implications
- Popular datasets shape the direction of the field by making certain problem formulations more tractable to study, while prior work reinforces those formulations by motivating their use and providing established points of comparison. In turn, this further propagates the datasets, leading to a feedback loop that reinforces existing paradigms.
- Recommendations
- Datasets should attempt to be formulation-agnostic. Datasets need to contain full context, preferably (a way to reconstruct) repositories with version control history, and provide rich multi-class labeled data from project-level down to line-level. For work that consumes existing datasets, we recommend authors critically evaluate datasets and the influence their limitations might have on the work. Additionally, information about the CWE, explanations of the vulnerability, and conditions under which it is triggered may be useful in extending the task beyond pure classification.
Pain Point 4: Programming languages are not proportional to use or susceptibility
C/C++ is overrepresented compared to real-world usage or the prevalence of vulnerabilities, in part, influenced by pre-processing tools.
- Description
- As with previous pain points, this appears to be the ‘default’ in ML4AVD research, rarely being explicitly motivated. The availability of C/C++ datasets is one explanation, as is the focus on memory-related vulnerabilities. Due to the explicit memory management model, C and C++ are notorious for memory-based vulnerabilities, which make up 40% of the MITRE 2023 Top-25 dangerous software weaknesses. Additionally, for GNN-based solutions, the languages supported by the tools used to generate the graph-based IRs (e.g., Joern) are cited as a factor in the choice of language.
- Implications
- For each language, we compute a combined danger score by adding the danger scores of its vulnerabilities, then normalizing it by the sum of all the Top-25 vulnerabilities. From this, PHP is the most vulnerable language, followed by C/C++, Java, and JavaScript. Yet, PHP currently makes up less than 10% of AVD research, disproportionate to its relative vulnerability. Although the literature frequently claims that ML4AVD solutions proposed for C/C++ would simply transfer to other languages, this claim is not sufficiently backed by evidence.
- Recommendations
- To better reflect the diversity of real-world languages and vulnerabilities, future research should diversify its focus to include languages such as Python and JavaScript, due to their significant popularity, along with Java and PHP due to their susceptibility to vulnerabilities. Furthermore, we suggest that future work should propose ML4AVD solutions targeting more complex multi-lingual software projects, as a recent survey of professional developers found that a typical software project has an average of 7 different programming languages. Tooling no longer imposes as significant a limitation on which languages can be supported.
Pain Point 5: Widely used datasets are unrepresentative
Datasets do not represent a realistic distribution of labels, projects, and vulnerabilities, and some widely used datasets include synthetic samples.
- Description
- The most widely used dataset in the analyzed papers is Devign (or the CodeXGLUE derivative), which has an unrealistic balanced proportion of vulnerable and benign labels. Both the Devign and ReVeal datasets include samples from only two software projects each, which limits the diversity of code present in the dataset and the types of vulnerabilities. The VulDeePecker dataset only includes two vulnerability types, which motivates the introduction of the similar SySeVR dataset containing 126 vulnerabilities, though this is only a fraction still of the over 900 types listed on CWE. Some widely used datasets also include significant proportions of synthetic samples from SARD alongside samples collected from real-world data.
- Implications
- Real-world vulnerability distributions are heavily skewed, with the largest proportion of files being benign. Training deep learning methods on datasets that over-represent vulnerabilities may bias models, and training only on datasets containing vulnerable-patched sample pairs excludes features present in files that are not security-relevant. Both of these biases may produce more false positives. Conversely, the proportion of vulnerable samples in a truly realistic dataset may be too low to efficiently train models, biasing models towards benign predictions. Synthetic samples do not provide a realistic depiction of the complexity of real-world vulnerabilities and, thus, may not provide a useful signal for training ML4AVD models. Low variety in vulnerability types and source projects reduces models’ usefulness and generalizability to unseen code.
- Recommendations
- To handle imbalanced data for training, we recommend conservatively under-sampling benign samples rather than over-sampling vulnerable samples to avoid introducing unrealistic synthetic samples. When under-sampling, the corresponding patched sample for each vulnerable sample should be retained within the training set to provide fine-grained contrastive signals. Furthermore, the training distribution can also be tuned empirically: in the adjacent imbalanced classification domain of malware classification, tuning algorithms have been proposed to find the training class ratio that maximizes a target performance metric on a held-out validation set. Validation and testing sets must be kept heavily imbalanced to ensure accurate calibration and evaluation on realistic data.
Pain Point 6: Widely used datasets suffer from quality issues
Commonly used datasets include high proportions of mislabeled samples and duplicate data.
- Description
- In a manual review, Croft, Babar, and Kholoosi found that a subset of the Big-Vul dataset contained 45% mislabeled samples; Devign contained 20%, and D2A contained 71% mislabeled samples. This is partially attributed to the collection techniques used, which take security-related commits and label functions that have been changed as vulnerable pre-commit, even if the change is unrelated or not directly security-related. Additionally, datasets contained significant duplicate samples and had inconsistent labels for some duplicate entries.
- Implications
- Low-quality data produces less capable ML4AVD models which are affected by biases in the data, learning spurious features. Poor-quality datasets also make evaluating models’ true capabilities difficult, as incorrect labels in the evaluation set will impact the reported metrics. When duplicate samples occur between training and test data, it undermines the validity of the evaluation. When removing duplicates, model performance decreases compared to reported results.
- Recommendations
- If using these datasets, pre-processing steps may help remove some duplicate and mislabeled data, though any pre-processing should be clearly described, and any refined datasets created as part of the work should be made available in the service of fairly comparing work. Pre-processing steps, such as slicing, may also introduce duplication, so de-duplication may be required in such cases even when the underlying dataset has unique samples. We recommend critically assessing datasets and using those that resolve the limitations we identify; existing widely used datasets with known quality issues should be used only for evaluation to facilitate comparison with previous solutions.
Pain Point 7: Datasets lack important information
Widely used datasets do not contain CWE type, do not explicitly pair related vulnerable and fixed samples, and do not provide meta-information about the vulnerability (CVE, bug reports, discussions).
- Description
- The widely used Devign dataset and its derivatives do not include information about the vulnerability type. Only Big-Vul includes information about the vulnerability in the form of a CVE ID. No dataset includes other meta-information surrounding the vulnerability, such as bug tracker issues, mailing lists, or merge request discussions for the patch.
- Implications
- The lack of CWE ID contributes to the focus on binary formulations. Lacking explicit links between vulnerable/patched sample pairs prevents leveraging pairs during training to increase separation between classes, which leads to spurious correlations. As LLM-based solutions are being increasingly used, which can make use of additional non-code information, the lack of meta-data and vulnerability-related discussion in the datasets impedes this avenue of development.
- Recommendations
- Datasets should at least include all information that a human expert may use to identify a vulnerability, which allows novel methods to integrate code and non-code data (commit messages, bug tracker issues, mailing lists, or pull/merge request discussions). As most datasets include at least repository and commit information, it is possible for future work that uses datasets without explicit pairs to reconstruct the link between vulnerable and patched samples, then use them for training and evaluation. The VulZoo dataset, which enriches vulnerabilities with additional information, including mailing list discussions, can be used to source non-code data, which may especially benefit LLM fine-tuning.
Pain Point 8: Datasets leak test data
Many of the widely used datasets lack explicit train/test splits, and where they are present, assignment is random, ignoring temporal relations between code samples in the same project; duplicate samples and data snooping by pre-trained large language models aggravate these issues.
- Description
- The majority of datasets used in the included articles do not provide fixed training/validation/test subset splits. Where a fixed split is present in datasets used by the analyzed work, assignment is randomized; when using datasets without a fixed split, analyzed articles most commonly use random assignment, which is motivated by mirroring previous work and enabling better baseline comparisons and rarely use date-based splits. Additionally, synthetic samples from SARD, sampled by some datasets, include the label (“bad”) in the variable names, which requires pre-processing to remove.
- Implications
- Randomly splitting datasets into test and training sets is likely to leak test set information to the ML4AVD models, allowing models to ‘time travel’, which inflates reported results. When a time-based split is used instead of a random split, model performance is shown to decrease. Outside of ML4AVD, temporally consistent splits have become common practice in the adjacent domain of malware detection and, more widely across ML for cybersecurity, the necessity to capture the non-stationarity inherent in cybersecurity tasks has been raised. Agentic LLM-based solutions, which have been shown to exhibit reward hacking, may access openly available test data.
- Recommendations
- Future work should use datasets derived from real-world data with fixed train/test splits, especially recent datasets that explicitly account for temporal correlation between samples and split the test data chronologically. To minimize data leakage and memorization issues, especially with LLM-based solutions, we recommend future datasets retain a hidden test set for use with a public leaderboard.
Pain Point 9: Solutions suffer from overfitting and poor generalization
Poor training practices lead to models learning spurious correlations and, subsequently, poor generalization to unseen source code.
- Description
- Some of the analyzed works attempt to reduce the possibility of overfitting through generic deep learning methods, such as reducing the number of parameters, using dropout, early termination/low number of epochs, and other techniques. Only a minority of the included papers used ablation studies to analyze how different aspects of their ML4AVD solutions affect their results and validate that each component contributes to any claimed improvements over the state-of-the-art. Evaluating baselines on different datasets/projects than those used for training produces worse results, which is indicative of overfitting to training data. In general, test set leakage constitutes a significant cause of overfitting, including for LLM-based solutions, which appear to exhibit better performance on data before the training cutoff date.
- Implications
- Overfitting produces artificially inflated results that do not hold up in a real-world setting, as it produces models that are unable to generalize to unseen data. Data augmentation through semantics-preserving code mutations is used to demonstrate that existing techniques overfit to specific syntax and text tokens, rather than semantic features, with a large emphasis on memory allocation code. Evaluation on paired vulnerable/patched samples shows that ML4AVD solutions, including LLM-based solutions, are unable to consistently distinguish them correctly.
- Recommendations
- As a fundamental step, we recommend using representative, high-quality datasets that contain multiple granularities and context for each sample. Additionally, contrasting paired vulnerable and patched samples, which is supported by datasets that make such pairs explicit, may help models learn the specific differences between them, reducing spurious correlations. Evaluating on different projects, datasets, or with different data augmentations than the training set can provide better insights into how well the model generalizes to unseen code. Ablation studies can validate the chosen architecture and that no extraneous complexity exists in the system.
Pain Point 10: Evaluation makes it difficult to measure progress and applicability
Comparability across works is problematic, due to evaluation methodology, limitations of datasets, and difficulty in reproducing baseline results; evaluation does not give a sense of realistic performance.
- Description
- The poor reproducibility of results is noted early in the period we analyzed, with Chakraborty et al. not being able to reproduce the results of Zhou et al. Zhou et al. did not make their implementation public, which required it to be re-implemented, and the public Devign dataset contains code sourced from two open source projects (FFmpeg, Qemu), while the model was trained using a broader dataset containing samples from four projects (additionally, Linux and Wireshark). It is common (38/87) for code and other artifacts (e.g., model weights/checkpoints) not to be made available in the analyzed work. Finally, any use of closed-weight models through an API produces reproducibility issues, as models may change, even without public announcements.
- Implications
- Without effective evaluations, progress in the field of ML4AVD is difficult to measure. Evaluations do not convey how well the ML4AVD solutions can be applied in real-world settings. Additionally, poor evaluation hides the problems of overfitting and poor generalization to unseen data, and further undermines the practical utility of the solutions.
- Recommendations
- Future work should open-source all code, including any pre-processing steps, and model weights and checkpoints to aid reproducibility and future baselines. Furthermore, it should fully describe hyper-parameters, including setting and publishing random seed values. When using LLM-based methods, prompts should be considered a constituent part of the parametrization of the model. As datasets have been known to become unavailable when hosted independently, we strongly recommend using dedicated hosting platforms that support versioning for all open-sourced artifacts. Evaluation should occur on representative imbalanced real-world datasets with realistic time-based train/test splits. For new agentic LLM-based solutions, evaluation should ensure that results are valid, and agents are not reward-hacking or extracting correct answers from available data.
Pain Point 11: Metrics do not capture realistic performance
The majority of ML4AVD works use only classification metrics, without accounting for class imbalance or detecting overfitting.
- Description
- Frequently, the motivation for the choice of metrics, particularly F1-score, Accuracy, Precision, Recall, and ROC-AUC, is the task being (binary) classification; however, more commonly the choice of metrics is motivated as being ‘standard’, ‘popular’, or ‘widely used’ or with reference to specific prior work. Unbiased metrics are also used to handle imbalanced data, with MCC being used more than Informedness and Markedness. Paired accuracy, the number of paired vulnerable/patched samples that are both classified correctly, is used in one work to detect spurious correlations.
- Implications
- To understand how models may perform in real-world settings, evaluating on realistic, imbalanced test sets is paramount, and this requires metrics that can capture performance in imbalanced datasets. If not accounted for, this leads to the base rate fallacy, which causes accuracy to overestimate performance. Due to the label imbalance, even apparently low FPR can be misleading, as it may still lead to high absolute numbers of false alerts, which cause alert fatigue. Thus, the F1-score, which equally weighs Precision and Recall, does not capture the trade-off well, as it provides information at a specific threshold.
- Recommendations
- We recommend that future work evaluates on heavily imbalanced realistic test sets to establish real-world performance and report the PR-AUC curve to make the trade-off between Precision and Recall explicit in a threshold-independent manner. As even low FPR can incur substantial practical costs, we argue that Recall at a given FPR (denoted as Recall@FPR) provides a more actionable measure of effectiveness. When evaluating how well an ML4AVD solution can differentiate the vulnerable and patched samples in a pair, future work should report the proportion of pairs for which both samples were classified correctly. Although publishing new CVEs has been used as a metric for real-world applicability, it incentivizes spurious vulnerability reporting.
Pain Point 12: Solutions exhibit poor explainability and interpretability
Explainability and interpretability are not a consideration for many of the included articles, providing only a label without providing a motivation for why the model arrived at the classification.
- Description
- Although literature on interpretability and explainability has tried to separate the terminology – explainability meaning a post-hoc process, while interpretability is inherent to the process – the analyzed literature uses these terms interchangeably, even within the same article. Li, Wang, and Nguyen use subgraph-based explainability to provide finer output granularity. Similarly, attention-based explainability is also used to produce finer-grained output. Articles that performed user studies evaluated the explainability of the models, which indicates that it is an important consideration for real-world applicability.
- Implications
- Explainability and interpretability provide information linking vulnerability classification with potential causes. This can feed into further steps of the vulnerability life cycle, helping practitioners and improving real-world applicability. As language models have become more prevalent in the ML4AVD space, they have been seen as a potential solution for explainability, but self-explanation may not be faithful to those processes, producing plausible but misleading explanations. This has been observed in LLM-based ML4AVD applications as well, with correct categorization paired with incorrect explanations and vice versa.
- Recommendations
- A key component of explainability is implicitly resolved by following the recommendations in Pain Point 1 and Pain Point 2, as more precise and contextually informed outputs from ML4AVD systems enhance the explainability of classification results. Generic black-box explainability tools may provide some benefit. For GNN-based solutions, specific explainability solutions have been developed. Research using LLM-based methods should go beyond self-explanation, look at the ever-evolving field of LLM explainability, and apply mechanistic interpretability techniques, although such techniques are only applicable to open-weight models and not closed-weight models.
High proportions of mislabeled samples
Dataset quality is a well-known problem in the ML4AVD field, and poor-quality ground truth labels are cited as a motivation for choosing synthetic datasets. In a manual review, Croft, Babar, and Kholoosi found that a subset of the Big-Vul dataset contained 45% mislabeled samples; Devign contained 20%, and D2A contained 71% mislabeled samples. Similarly, Risse and Böhme found high proportions of false positive labels in random subsets of DiverseVul (35%), Devign (50%), and Big-Vul (61%).
Share of samples found to be wrongly labeled
Manual reviews of popular ML4AVD datasets, Pain Point 6.
Show as table
| Review | Dataset | Wrong labels |
|---|---|---|
| Croft, Babar and Kholoosi | Big-Vul (subset) | 45% |
| Croft, Babar and Kholoosi | Devign | 20% |
| Croft, Babar and Kholoosi | D2A | 71% |
| Risse and Böhme | DiverseVul | 35% |
| Risse and Böhme | Devign | 50% |
| Risse and Böhme | Big-Vul | 61% |
Comparison of vulnerability datasets
Much of the work that proposes new datasets is done in response to perceived flaws in existing datasets, with some articles explicitly refining previous datasets. The datasets show that, while there have been improvements, none of the identified datasets bring together all the recommendations we put forward.
| Dataset | Year | % vuln. | Granularity | CWE ID | Fixed split | Code pairs |
|---|---|---|---|---|---|---|
| Devign2019 | 2019 | 45.0 | function | No | No | No |
| ReVeal2021 | 2021 | 9.2 | function | No | No | Yes |
| Big-Vul2020 | 2020 | 5.7 | function, line | Yes | Random* | Yes |
| VulDeePecker2018 | 2018 | 28.8 | slice | Yes | No | No |
| SySeVR2018 | 2018 | 13.4 | slice | Yes | No | No |
| Draper2021 | 2021 | 9.5 | function | Yes | Random | No |
| D2A2021 | 2021 | 1.4 | slice | Yes | Random | Yes |
| µVulDeePecker2019 | 2019 | 23.7 | slice | Yes | No | No |
| Real-Vul2024 | 2024 | 0.3 | repository, function, line | Yes | Temporal | No |
| PrimeVul2024 | 2024 | 3.1 | function | Yes | Temporal | Yes |
| VulEval2024 | 2024 | 3.0 | repository, file, function | Yes | Temporal | No |
Selected rows of Table 6. Random: random splits; not accounting for temporal relationships. Temporal: split chronologically. *Fu and Tantithamthavorn provide a version with a random fixed test/train split. Code pairs: explicitly providing both vulnerable and patched code for each datapoint. VulDeePecker, SySeVR, Draper and µVulDeePecker contain both real-world and synthetic data; all rows are C/C++.
Overall Trends
Our analysis identifies twelve pain points spanning the ML4AVD pipeline and shows that they are not independent: they reinforce each other through feedback loops between datasets, formulations, baselines, and metrics. This integrated view explains the field’s most visible symptom, namely that ML4AVD research remains highly concentrated on binary classification of C/C++ vulnerabilities at the function level.
Programming language and dataset-related pain points fundamentally influence other aspects of the field, but the other pain points still stand as their own limitations for the field to overcome. Across many of the pain points we identified, we note a strong trend of following previous research among the analyzed articles, which we have already filtered to identify influential, highly cited work.
ML4AVD Preflight Checklist
We recommend that future work critically engages with previous work in the field, not just at the technical level, but also conceptually. Thus, future work should seek to answer the correct question, taking into account the very real-world problem of vulnerability discovery in the context of the vulnerability life cycle. We recommend that future work critically evaluate the datasets it uses, according to the criteria we lay out, and choose datasets that are useful in answering its research question, rather than allowing dataset availability to influence the direction of the research.
As a reference for future work, we present the main recommendations as an easy-to-follow checklist. Please note that these items are not independent and should be treated as a whole, rather than individual improvements.
- Contextualize vulnerability detection within the vulnerability life cycle and provide information required by subsequent stages: at least vulnerability type, but also code paths or trigger conditions.
- Separate input and output granularities; use rich input (e.g., repository-level, graph IRs) to provide context and specific output (line-level) to pinpoint the vulnerability.
- Choose datasets that support the research question, rather than the other way around; critically evaluate datasets to ensure they are high-quality and fit the research.
- Target languages that are underrepresented in the literature but widely used (e.g., PHP, Python).
- Target multi-language projects.
- Choose tools that support the research question, rather than allow the availability of tools to shape the choice of programming language.
- Evaluate, rather than claim, cross-language transferability.
- Choose real-world datasets that sample from multiple projects.
- Keep validation and test sets imbalanced; for training, under-sample benign data conservatively and retain each vulnerable sample’s patched counterpart; consider loss re-weighting.
- Use fixed temporal train/test splits; do not use random splits.
- Audit for poor labeling, duplicate data, and other quality issues; also de-duplicate after pre-processing, as some steps (e.g., slicing) can introduce duplicates.
- Prefer datasets that are context-rich, containing higher granularities, paired samples, and vulnerability type and metadata.
- Assume data leakage when working with pre-trained LLMs regardless of reported knowledge cutoffs; prefer leaderboards with hidden test data.
- Train contrastively on vulnerable/patched pairs to force class separation and prevent learning of spurious features.
- Run ablation studies to ensure each component of a solution is contributing to the output.
- Test generalization across projects, across datasets, and across code augmentations.
- Use explainability techniques diagnostically, to surface spurious correlations.
- Use generic regularization methods (e.g., dropout, early termination) alongside domain-specific methods to reduce overfitting.
- Provide a full replication package: code including pre-processing, weights/checkpoints, hyperparameters, random seeds, dataset versions (note: LLM prompts count as model parameterization); pin exact model versions and API parameters; prefer open-weight models where reproducibility matters.
- Host on versioned platforms (Zenodo, OSF, Hugging Face, GitHub/GitLab/Codeberg) as independently hosted datasets and code can disappear.
- Evaluate on realistic imbalanced test sets with time-based splits.
- Verify that agentic solutions are not reward hacking.
- Report PR-AUC and Recall@FPR across a range of FPR; keep F1 only for continuity; accuracy alone is invalid under realistic imbalance, and ROC-AUC is misleading because of its FPR dependence.
- Report paired accuracy: the proportion of vulnerable/patched pairs in which both samples are classified correctly.
- Provide a multi-class confusion matrix as additional material so any metric can be derived; provide a separate matrix for paired metrics.
- Do not use newly published CVEs as a success metric, as it incentivizes spurious reporting.
- Use interpretability and explainability techniques; do not rely on LLM self-explanation, which is often unfaithful; use black-box tools, GNN-specific explainers, or mechanistic interpretability.
ML4AVD in the Age of Agents
There have been two major changes in recent years that have the potential to shape the future of the AVD field: first, the AI Cyber Challenge (AIxCC), one of the largest initiatives to date aimed at making automated detection, exploitation, and repair of vulnerabilities practical through advancements in LLMs; second, the rise of agentic AI, which has demonstrated rapidly improving capabilities in both producing and analyzing code at scale.
Case Study: Was AIxCC a Step in the Right Direction?
AIxCC was a competition designed to advance the state of autonomous vulnerability detection, exploitation, and repair. Teams developed Cyber Reasoning Systems (CRSs) that operated on version-controlled repositories containing full source code in C/C++ or Java of real-world open-source projects, including the Linux kernel, nginx, and Jenkins. The vulnerabilities were synthetically introduced by the competition organizers into the commit history of these host repositories, and participants were required to identify the vulnerability-inducing commits. A perfect solution had to autonomously perform detection, exploitation, and patching (removing the vulnerability while preserving the functionality of the code).
The AIxCC scoring algorithm combines four assessed metrics to compute the overall team score: the Vulnerability Discovery Score (VDS), the Program Repair Score (PRS), a Diversity Multiplier (DM), and an Accuracy Multiplier (AM). The VDS and PRS are combined via a weighted logarithmic function, where patching is weighted approximately three times more heavily than discovery alone.
Most impactful contributions
- The decoupling of input and detection granularity (Pain Point 2).
- The evaluation of multiple languages (Pain Point 4).
- The in-competition enforcement of withheld test sets (Pain Point 8).
- The validation of labels through sanitizer-based verification (Pain Point 6).
- The use of an application-aware scoring function rather than generic classification metrics (Pain Point 11).
- The embedding of detection within a full vulnerability life cycle pipeline, which addresses the broader concern that AVD is too often treated as a standalone classification task (Pain Point 1).
Does not fully resolve
- Synthetic injection of disclosed CVEs may have leaked into LLM training (Pain Point 8).
- Commit-level output remains coarser than recommended (Pain Point 2).
- Explanation quality is not directly evaluated (Pain Point 12).
We contend that AIxCC is best understood not as a solution to the pain points of ML4AVD, but as a proof of concept that the research community can build upon: one that demonstrates how design can reshape research incentives toward more practical and operationally relevant approaches.
Is ML4AVD still needed?
The rise of capable agentic LLMs raises a fair question for the future of the field: if general-purpose code-capable agents can already locate vulnerabilities in real codebases, as AIxCC’s CRSs demonstrated, then is dedicated ML4AVD research still needed or will it be subsumed by progress in foundation models? We argue that it remains both relevant and necessary, for three reasons.
Pain Points are Approach-Agnostic
The methodological issues surfaced in section 5 are not artifacts of any single model architecture. They persist across the dominant approaches we observed (CNNs, RNNs, GNNs, and LLMs) and, in several cases, are aggravated by the move to LLMs: opaque training corpora make data contamination harder to rule out, agentic systems are vulnerable to reward hacking when test data is reachable, and LLM self-explanations are known to be unfaithful.
Specialized Models Complement Agents
Agentic detection pipelines are increasingly capable of integrating heterogeneous signals through tool use, which positions specialized ML4AVD models as components within broader systems rather than as standalone end-to-end solutions. Furthermore, specialization remains valuable beyond raw capability: it supports local deployment (privacy), low-latency in-IDE inference (cost), and reproducible evaluation through fixed open-weights.
Need for Open Research
Even as frontier models (e.g., Anthropic Mythos) push the commercial state-of-the-art on vulnerability discovery, their closed nature limits reproducibility, interpretability, and applicability in air-gapped or privacy-critical settings, which make sending code to an external API infeasible. Therefore, there is still scope for smaller open-weight models as they are needed both for scientific research and understanding as well as deployment scenarios where external large commercial models are not applicable.
Finally, as agentic coding frameworks are accelerating the rate at which software and vulnerabilities are produced, we argue that the demand for scalable and accurate detection grows as well. Therefore, what has changed is not whether AVD research is needed, but what shape it should take: less function-level binary classification on saturated benchmarks, more focused attention on building principled foundations.
Conclusion
- We analyzed 87 influential ML4AVD works across six dimensions – problem formulation, granularity, programming language, datasets, evaluation metrics, and ML approach – and identified twelve interconnected pain points that explain why the field has failed to show consistent progress despite a decade of sustained effort.
- Our analysis indicates self-reinforcing cycles are present in ML4AVD research, which require future work to critically evaluate what came before, rather than look at incremental improvements.
- The rise of agentic LLMs does not diminish the need for dedicated ML4AVD research.
- The methodological pain points identified here are approach-agnostic and, in several cases, are aggravated by LLMs.
- The need for improved open, small, and efficient ML4AVD models is still present, even if proprietary models are becoming increasingly capable.
The direction for detection is clear; what remains is the will to follow it.
Cite
@article{ristea2026direction,
title={Direction for Detection: A Survey of Automated Vulnerability Detection and all of its Pain Points},
author={Dan Ristea and Shae McFadden and Ezzeldin Shereen and Madeleine Dwyer and Sanyam Vyas and Chris Hicks and Vasilios Mavroudis},
journal={Transactions on Machine Learning Research},
year={2026}
}