Pith. sign in

REVIEW 3 major objections 6 minor 34 references

VulGuard: An Unified Tool for Evaluating Just-In-Time Vulnerability Prediction Models

T0 review · 3 major / 6 minor · reviewed 2026-08-06 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read VulGuard is an automated tool that carries out an entire just-in-time vulnerability prediction study, from raw git history to trained model scores.

desk verdict VulGuard is a real, installable end-to-end JIT-VP pipeline, but its automated commit-labeling step is the load-bearing flaw that the demo numbers inherit; the authors admit the noise but never quantify it. read the letter →

arxiv 2507.16685 v1 pith:CDRXZ7KI submitted 2025-07-22 cs.SE

Duong Nguyen , Manh Tran-Duc , Thanh Le-Cong , Triet Huynh Minh Le , M. Ali Babar , Quyet-Thang Huynh This is my paper · ORCID
classification cs.SE
keywords just-in-timevulnerabilitypredictionV-SZZcommitminingdatasetsreproduciblebenchmarkingdeeplearningdetectioncontinuousintegrationFFmpeg
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper presents VulGuard, an installable tool that automates the entire just-in-time vulnerability prediction (JIT-VP) pipeline, from mining raw commit histories on GitHub through extracting features and labeling commits to training and evaluating prediction models. The tool is demonstrated on FFmpeg and the Linux kernel, processing 1,081,882 commits in roughly one hour and twelve hours respectively, using eight models ranging from logistic regression to graph-based and deep-learning approaches. The point of the exercise is reproducibility and scale: JIT-VP research is currently hampered by repository-specific, error-prone data curation, and VulGuard is an attempt to replace that with a standardized, command-line driven workflow that can also plug into CI/CD. The paper also reports that under a realistic evaluation setting that includes security-unrelated commits, all models perform substantially worse than under an idealized vulnerable-only setting.

What carries the argument

The load-bearing object is the commit-annotation chain at the center of the extraction module: a regular expression from prior work selects candidate vulnerability-fixing commits, and the V-SZZ algorithm traces those fixes back through blame information to the vulnerability-inducing commits that become the positive training labels. V-SZZ is an enhanced variant of the classic SZZ algorithm designed for vulnerability-inducing changes. Everything downstream—dataset balance, model training, and the ideal-versus-realistic comparison—depends on this chain producing trustworthy labels; the paper notes that the regular expression may introduce noise and recommends complementing it with a manual patch list.

What would settle it

Take a repository with a manually verified list of vulnerability-fixing commits, run VulGuard's mining command once with the built-in regular expression and once with the manual list as the patch source, and compare the resulting vulnerability-inducing commit sets and the rankings of the eight models; poor agreement between the two sets, or a different model ranking under the manual list, would show that the automated annotation is the fragile step.

Watch

Extended reading notes

Core claim

The central claim is that one tool can carry a complete JIT-VP study without hand-built data pipelines. VulGuard's extraction module filters merge, whitespace-only, and comment-only commits, keeps source files in the repository's primary language, extracts commit messages, diffs, blame data, expert features, and code property graphs in parallel, and serializes everything as JSONL. Its annotation step flags fixing commits with a regular expression drawn from prior work or with a user-provided patch list, then runs V-SZZ to trace each fix to the commits that introduced the vulnerability; the data are split chronologically to avoid leakage. The evaluation module trains and scores eight models—VCCFinder, CodeJIT, logistic regression, LAPredict, TLEL, DeepJIT, SimCom, and JITFine—and computes classification and effort-aware metrics. Applied to FFmpeg and the Linux kernel, the tool produces over one million labeled commits and reveals a consistent drop in every model's PR-AUC, MCC, F1, and ROC-AUC when moving from the idealized to the realistic setting.

Load-bearing premise

The entire tool's output depends on the automated assignment of vulnerability labels: a regular expression picks fixing commits, and V-SZZ traces them back to the commits that supposedly introduced the vulnerability, so any systematic error in that chain makes the datasets and all model comparisons built on them unreliable.

Editorial extensions

If this is right

  • Researchers can construct new JIT-VP datasets from any supported C/C++, Java, JavaScript, or Python repository using two command-line commands, and can substitute their own patch-commit list when the default regular expression is not trustworthy.
  • Eight published JIT prediction models can be trained, evaluated, and run for inference in a common framework, which makes direct comparison of machine-learning, deep-learning, ensemble, and graph-based model families possible without reimplementing each one.
  • Adopting the realistic evaluation setting, which includes security-unrelated commits, changes conclusions about model quality: every metric in the reported tables drops substantially relative to the idealized setting, so evaluations that omit unrelated commits are likely over-optimistic.
  • Because the tool outputs JSONL datasets and integrates a graph builder, the same mined data can be reused for other vulnerability analysis tasks such as fine-grained localization or message-based detection.
  • Trained models can be embedded in CI/CD workflows, so a developer can score a new commit at push time rather than in a batch research pipeline.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • If the regular-expression-based annotation is noisy, the size of the reported ideal-to-realistic gap could be partly an artifact of labeling errors rather than true model behavior; rerunning the pipeline with a manually verified patch list would separate the two effects.
  • The same pipeline could serve as the seed of a standardized JIT-VP benchmark: fixing the commit cutoff, the model implementations, and the chronological splitting rule would make cross-paper comparisons meaningful only when those settings are shared.
  • Because VulGuard also ships B-SZZ, AG-SZZ, and MA-SZZ, it can be used directly to compare defect-inducing versus vulnerability-inducing labels on the same commit history, which would test whether JIT-defect and JIT-vulnerability prediction are the same underlying problem.
  • The realistic Linux dataset contains well under one percent vulnerability-inducing positive commits among non-fixing commits, so cost-sensitive and class-imbalance techniques are a natural next testbed for these models.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 6 minor

Summary. The paper presents VulGuard, an installable Python package and CLI that mines Git repositories, filters commits, labels vulnerability-inducing commits using a keyword regex plus V-SZZ, extracts features, and trains/evaluates eight JIT vulnerability prediction models. The authors demonstrate the pipeline on FFmpeg and the Linux kernel (1,081,882 commits) and report results under 'ideal' and 'realistic' settings. The engineering contribution is concrete and the release is referenced, but the empirical demonstration rests on an automated labeling step that the paper itself acknowledges may introduce noise, and the reported metrics are not accompanied by validation or error bars.

Significance. VulGuard addresses a real gap in JIT-VP research: end-to-end, reproducible dataset construction and model evaluation. If the label-quality concern is resolved, the tool would be a valuable community asset, with parallel extraction, support for eight models, a customizable pipeline, and large-scale demonstration data. The paper's honest reporting of the realistic-setting performance drop is also useful. However, the current manuscript does not establish that the default annotation path produces trustworthy labels, so the benchmark numbers in Tables IV and V cannot yet be taken as reliable.

major comments (3)
  1. [III-A3, Tables IV-VI] The default annotation pipeline (Zhou et al. regex for fixing commits, then V-SZZ for vulnerability-inducing commits) is load-bearing for the paper's demonstration. The paper itself states that the regex 'may introduce noises' and recommends complementing it with a manual patch list, but every downstream result in Tables IV and V and the dataset statistics in Table VI are produced without that validation. With a 0.9% positive rate (9,715 VICs out of 1,081,882 commits, Table VI), even modest false-positive or false-negative rates from security-keyword matching or V-SZZ misattribution inject hundreds of wrong labels into the training and test splits, directly biasing the reported PR-AUC, MCC, F1, and ROC-AUC values. The manuscript should provide a manual audit of a random sample of labeled VICs (precision) and, ideally, a rerun with a manually verified patch list or an NVD/CVE-based ground truth to show that model rankings and absolute metrics are stable.
  2. [Table I] The printed regular expression is not a valid regex specification. In the medium-vulnerability row, the token 'de)?serializ' contains an unmatched closing parenthesis, which would cause a regex compiler error in standard engines such as Python re or grep -E, and the tokens 'bopen.redirect' and 'privelege' appear to be typos for 'open.redirect' and 'privilege'; similar issues include '\bcross--origin\b' with a double hyphen. Since Table I is the specification of the tool's default patch-commit filter, the paper must provide the exact, tested regex and confirm that the released code matches it. If the code contains the same typo, the filter silently fails to match intended patterns; if the code differs, the paper's specification is misleading.
  3. [V-B, Tables IV-V] The evaluation reports single-run metric values without error bars, seeds, or hyperparameter details. For deep learning models (DeepJIT, JITFine, SimCom), and especially for the near-degenerate Linux realistic results (e.g., MCC and F1 of 0.000 for DeepJIT and JITFine in Table V), the reader cannot determine whether the reported values are stable or artifacts of a single run. Since standardized evaluation is a central selling point of the tool, the paper should report multiple runs with variance or provide fixed seeds and full training configurations.
minor comments (6)
  1. [Abstract and title] 'An Unified' is grammatically incorrect; change to 'A Unified'.
  2. [Table VI] 'Vulnerability-neural commits' should be 'vulnerability-neutral commits'; the prose in Section V-A calls them 'security-unrelated changes', and the abbreviation 'VNC' is not defined in the table.
  3. [Table III] The threshold-dependent and threshold-independent labels appear inconsistent; the caption says 'ED is threshold dependent' while the table rows are marked 'DE' and 'ID'. Please correct the abbreviations.
  4. [V-A] Report the hardware configuration used for the stated extraction times (about 1 hour for FFmpeg, 12 hours for Linux) so the timing claims are reproducible.
  5. [IV-B] The example JSON for custom patch commits is not displayed with matched braces; format it consistently with the JSON example in Section IV-C.
  6. [III-A3 and V-B] The realistic evaluation setting is inherited from the companion ICSME 2025 paper [7], but this manuscript does not define VNC commits or the exact construction of the ideal/realistic splits; either include the definitions or point to a freely accessible version of [7].

Circularity Check

0 steps flagged · score 0.0 of 10

No circular derivation: VulGuard is a tooling paper whose model evaluations and data-construction steps are independent of any fitted-parameter-as-prediction loop.

full rationale

VulGuard is a tooling and evaluation-framework paper, not a derivation. The commit-annotation step (Section III-A3) uses the Zhou et al. regex and V-SZZ to label vulnerability-inducing commits, but this is an inherited data-construction assumption, not a quantity that is then renamed as a prediction. The paper itself flags the limitation: the regex 'may introduce noises' and the authors 'recommend complementing the tool with a manual list of patch commits.' This is a data-quality caveat, not a circularity. The model evaluations in Tables IV and V are honest held-out performance numbers produced by training and testing the implemented methods; no fitted parameter is dressed up as an independent prediction. The realistic evaluation setting is adopted 'in accordance with the findings of our empirical study [7]', and the demonstration tables are explicitly drawn from that same ICSME 2025 paper. This is prominent self-citation, but it is provenance of an evaluation protocol and a reuse of the authors' own prior experiment, not a load-bearing argument that reduces the tool's claim to a self-citation. The central claims, that VulGuard can mine repositories, extract features, train eight models, and evaluate them, are supported by the publicly released tool, standard models, and concrete large-scale runs on FFmpeg and the Linux kernel. No step in the paper makes Eq. X equal Eq. Y by construction, and no uniqueness theorem from the authors is invoked to forbid alternatives. The appropriate finding is no significant circularity.

Assumptions & free parameters 1 free parameters · 3 assumptions · 0 invented entities

The central claim of VulGuard does not rest on a derivation with fitted constants; the tool integrates established labeling algorithms and models. The main assumptions are the reliability of automated labeling (regex + V-SZZ) and the validity of the realistic evaluation protocol, both of which affect the demonstrative results.

free parameters (1)
  • Default data split ratio (75/5/20) = 0.75 / 0.05 / 0.20
    Chosen by hand as a default for the training/validation/testing split in Section III-A4. It is a configuration choice that affects the demonstration results, but it is not fitted to data to achieve a target outcome.
assumptions (3)
  • domain assumption V-SZZ correctly traces vulnerability-fixing commits back to vulnerability-inducing commits.
    Central to the labeling step in Section III-A3. If V-SZZ produces inaccurate traces, the resulting datasets and model evaluations are unreliable.
  • domain assumption The regular expression proposed by Zhou et al. adequately identifies vulnerability-fixing commits.
    Used in Section III-A3 to filter patch commits. The authors themselves note it 'may introduce noises', acknowledging the assumption is imperfect.
  • domain assumption Including vulnerability-neutral commits as negatives yields a realistic evaluation setting.
    Adopted from the authors' companion ICSME 2025 paper [7] and used in Section V-B. This is a design assumption about how real-world development data should be represented; it is not independently validated within this paper.

how reviews work

0 comments
Cite this review

Pith. "Pith review of VulGuard: An Unified Tool for Evaluating Just-In-Time Vulnerability Prediction Models." pith.science (2026). https://pith.science/paper/CDRXZ7KI

@misc{pith2026250716685,
  author       = {Pith},
  title        = {Pith review of: VulGuard: An Unified Tool for Evaluating Just-In-Time Vulnerability Prediction Models},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/CDRXZ7KI}},
  note         = {Machine review of arXiv:2507.16685}
}
read the original abstract

We present VulGuard, an automated tool designed to streamline the extraction, processing, and analysis of commits from GitHub repositories for Just-In-Time vulnerability prediction (JIT-VP) research. VulGuard automatically mines commit histories, extracts fine-grained code changes, commit messages, and software engineering metrics, and formats them for downstream analysis. In addition, it integrates several state-of-the-art vulnerability prediction models, allowing researchers to train, evaluate, and compare models with minimal setup. By supporting both repository-scale mining and model-level experimentation within a unified framework, VulGuard addresses key challenges in reproducibility and scalability in software security research. VulGuard can also be easily integrated into the CI/CD pipeline. We demonstrate the effectiveness of the tool in two influential open-source projects, FFmpeg and the Linux kernel, highlighting its potential to accelerate real-world JIT-VP research and promote standardized benchmarking. A demo video is available at: https://youtu.be/j96096-pxbs

Figures

Figures reproduced from arXiv: 2507.16685 by the authors.

Figure 1
Figure 1. Architecture of VulGuard II. RELATED WORKS Zeng et al. [11]’s replication study is the closest to our work, which provides a codebase for extracting commit-level features and metadata. It also includes implementations of several Just-in-Time (JIT) defect prediction baselines: CC2Vec [12], DeepJIT [13], DBN-JIT [14], LR-JIT [8], and their proposed method, LAPredict. We include some models from their work, including D… view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

34 extracted references · 33 canonical work pages

  1. [7]

    Toward realistic evaluations of just-in-time vulnerability pre- diction,

    D. Nguyen, T. Le-Cong, T. Huynh Minh Le, M. A. Babar, and Q.-T. Huynh, “Toward realistic evaluations of just-in-time vulnerability pre- diction,” in the 41st International Conference on Software Maintenance and Evolution . IEEE, 2025

    work page 2025

  2. [1]

    Crowdstrike outage report,

    CrowdStrike, “Crowdstrike outage report,” 2024. [Online]. Available: https://www.crowdstrike.com/wp-content/uploads/2024/08/ Channel-File-291-Incident-Root-Cause-Analysis-08.06.2024.pdf

    work page 2024

  3. [2]

    Crowdstrike outage damage,

    TechTarget, “Crowdstrike outage damage,” 2024. [Online]. Available: https://www.techtarget.com/whatis/feature/ Explaining-the-largest-IT-outage-in-history-and-whats-next

    work page 2024

  4. [3]

    Vccfinder: Finding potential vulnerabilities in open-source projects to assist code audits,

    H. Perl, S. Dechand, M. Smith, D. Arp, F. Yamaguchi, K. Rieck, S. Fahl, and Y . Acar, “Vccfinder: Finding potential vulnerabilities in open-source projects to assist code audits,” in the 22nd ACM SIGSAC conference on computer and communications security , 2015, pp. 426–437

    work page 2015

  5. [4]

    Code-centric learning-based just-in-time vulnerability detection,

    S. Nguyen, T.-T. Nguyen, T. T. Vu, T.-D. Do, K.-T. Ngo, and H. D. V o, “Code-centric learning-based just-in-time vulnerability detection,” Journal of Systems and Software , vol. 214, p. 112014, 2024

    work page 2024

  6. [5]

    Vuldigger: A just-in-time and cost-aware tool for digging vulnerability-contributing changes,

    L. Yang, X. Li, and Y . Yu, “Vuldigger: A just-in-time and cost-aware tool for digging vulnerability-contributing changes,” in GLOBECOM 2017- 2017 IEEE Global Communications Conference . IEEE, 2017, pp. 1–7

    work page 2017

  7. [6]

    Just-in-time software vulnerability detection: Are we there yet?

    F. Lomio, E. Iannone, A. De Lucia, F. Palomba, and V . Lenarduzzi, “Just-in-time software vulnerability detection: Are we there yet?” Jour- nal of Systems and Software , vol. 188, p. 111283, 2022

    work page 2022

  8. [8]

    A large-scale empirical study of just-in-time quality assurance,

    Y . Kamei, E. Shihab, B. Adams, A. E. Hassan, A. Mockus, A. Sinha, and N. Ubayashi, “A large-scale empirical study of just-in-time quality assurance,” IEEE Transactions on Software Engineering , vol. 39, no. 6, pp. 757–773, 2012

    work page 2012

Show all 34 references
  1. [9]

    V-szz: automatic identifi- cation of version ranges affected by cve vulnerabilities,

    L. Bao, X. Xia, A. E. Hassan, and X. Yang, “V-szz: automatic identifi- cation of version ranges affected by cve vulnerabilities,” in the 44th International Conference on Software Engineering , 2022, pp. 2352– 2364

    2022

  2. [10]

    Vulguard: An unified framework for evaluating just-in-time vulnerability prediction models,

    D. Nguyen, M. Tran-Duc, T. Le-Cong, T. Huynh Minh Le, M. A. Babar, and Q.-T. Huynh, “Vulguard: An unified framework for evaluating just-in-time vulnerability prediction models,” 2025. [Online]. Available: https://github.com/AI4Code-HUST/VulGuard

    2025

  3. [11]

    Deep just-in-time defect prediction: how far are we?

    Z. Zeng, Y . Zhang, H. Zhang, and L. Zhang, “Deep just-in-time defect prediction: how far are we?” in the 30th ACM SIGSOFT International Symposium on Software Testing and Analysis , 2021, pp. 427–438

    2021

  4. [12]

    Cc2vec: Distributed representations of code changes,

    T. Hoang, H. J. Kang, D. Lo, and J. Lawall, “Cc2vec: Distributed representations of code changes,” in the ACM/IEEE 42nd international conference on software engineering , 2020, pp. 518–529

    2020

  5. [13]

    Deepjit: an end-to-end deep learning framework for just-in-time defect prediction,

    T. Hoang, H. K. Dam, Y . Kamei, D. Lo, and N. Ubayashi, “Deepjit: an end-to-end deep learning framework for just-in-time defect prediction,” in 2019 IEEE/ACM 16th International Conference on Mining Software Repositories (MSR) . IEEE, 2019, pp. 34–45

    2019

  6. [14]

    Deep Learning for Just-in-Time Defect Prediction,

    X. Yang, D. Lo, X. Xia, Y . Zhang, and J. Sun, “Deep Learning for Just-in-Time Defect Prediction,” in 2015 IEEE International Conference on Software Quality, Reliability and Security . Vancouver, BC, Canada: IEEE, Aug. 2015, pp. 17–26. [Online]. Available: http://ieeexplore.ie...

    2015

  7. [15]

    When do changes induce fixes?

    J. ´Sliwerski, T. Zimmermann, and A. Zeller, “When do changes induce fixes?” ACM sigsoft software engineering notes , vol. 30, no. 4, pp. 1–5, 2005

    2005

  8. [16]

    Tlel: A two-layer ensemble learning approach for just-in-time defect prediction,

    X. Yang, D. Lo, X. Xia, and J. Sun, “Tlel: A two-layer ensemble learning approach for just-in-time defect prediction,” Information and Software Technology, vol. 87, pp. 206–220, 2017

    2017

  9. [17]

    Simple or complex? together for a more accurate just-in-time defect predictor,

    X. Zhou, D. Han, and D. Lo, “Simple or complex? together for a more accurate just-in-time defect predictor,” in the 30th IEEE/ACM International Conference on Program Comprehension , 2022, pp. 229– 240

    2022

  10. [18]

    The best of both worlds: integrating semantic features with expert features for defect prediction and localization,

    C. Ni, W. Wang, K. Yang, X. Xia, K. Liu, and D. Lo, “The best of both worlds: integrating semantic features with expert features for defect prediction and localization,” in the 30th ACM Joint European Software Engineering Conference and Symposium on the F oundations of Softwar...

    2022

  11. [19]

    JITBot: an explainable just-in-time defect prediction bot,

    C. Khanan, W. Luewichana, K. Pruktharathikoon, J. Jiarpakdee, C. Tantithamthavorn, M. Choetkiertikul, C. Ragkhitwetsagul, and T. Sunetnanta, “JITBot: an explainable just-in-time defect prediction bot,” in the 35th IEEE/ACM International Conference on Automated Software Enginee...

    2020

  12. [20]

    Github action

    GitHub, “Github action.” [Online]. Available: https://github.com/ features/actions

  13. [21]

    Automatic identifi- cation of bug-introducing changes,

    S. Kim, T. Zimmermann, K. Pan, E. James Jr et al., “Automatic identifi- cation of bug-introducing changes,” in the 21st IEEE/ACM international conference on automated software engineering (ASE’06) . IEEE, 2006, pp. 81–90

    2006

  14. [22]

    Are fix-inducing changes a moving target? a longitudinal case study of just-in-time defect prediction,

    S. McIntosh and Y . Kamei, “Are fix-inducing changes a moving target? a longitudinal case study of just-in-time defect prediction,” in the 40th international conference on software engineering , 2018, pp. 560–560

    2018

  15. [23]

    Deepcva: Automated commit-level vulnerability assessment with deep multi-task learning,

    T. H. M. Le, D. Hin, R. Croft, and M. A. Babar, “Deepcva: Automated commit-level vulnerability assessment with deep multi-task learning,” in 2021 36th IEEE/ACM International Conference on Automated Software Engineering (ASE) . IEEE, 2021, pp. 717–729

    2021

  16. [24]

    Automated identification of security issues from commit messages and bug reports,

    Y . Zhou and A. Sharma, “Automated identification of security issues from commit messages and bug reports,” in the 11th joint meeting on foundations of software engineering , 2017, pp. 914–919

    2017

  17. [25]

    Are latent vulnerabilities hidden gems for software vulnerability prediction? an empirical study,

    T. H. M. Le, X. Du, and M. A. Babar, “Are latent vulnerabilities hidden gems for software vulnerability prediction? an empirical study,” in the 21st International Conference on Mining Software Repositories , 2024, pp. 716–727

    2024

  18. [26]

    Snopy: Bridging sample denoising with causal graph learning for effective vulnerability detection,

    S. Cao, X. Sun, X. Wu, D. Lo, L. Bo, B. Li, X. Liu, X. Lin, and W. Liu, “Snopy: Bridging sample denoising with causal graph learning for effective vulnerability detection,” in the 39th IEEE/ACM International Conference on Automated Software Engineering , 2024, pp. 606–618

    2024

  19. [27]

    A framework for evaluating the results of the szz approach for identifying bug-introducing changes,

    D. A. Da Costa, S. McIntosh, W. Shang, U. Kulesza, R. Coelho, and A. E. Hassan, “A framework for evaluating the results of the szz approach for identifying bug-introducing changes,” IEEE Transactions on Software Engineering , vol. 43, no. 7, pp. 641–657, 2016

    2016

  20. [28]

    Systematic literature review on application of learning-based approaches in contin- uous integration,

    A. K. Arani, T. H. M. Le, M. Zahedi, and M. A. Babar, “Systematic literature review on application of learning-based approaches in contin- uous integration,” IEEE Access , 2024

    2024

  21. [29]

    Automated software vulnerabil- ity assessment with concept drift,

    T. H. M. Le, B. Sabir, and M. A. Babar, “Automated software vulnerabil- ity assessment with concept drift,” in the 16th International Conference on Mining Software Repositories (MSR) . IEEE, 2019, pp. 371–382

    2019

  22. [30]

    Available: https://github.com/joernio/joern

    Joernio, “Joern.” [Online]. Available: https://github.com/joernio/joern

  23. [31]

    Mitigating data imbalance for software vulnerability assessment: Does data augmentation help?

    T. H. M. Le and M. Ali Babar, “Mitigating data imbalance for software vulnerability assessment: Does data augmentation help?” in the 18th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement, 2024, pp. 119–130

    2024

  24. [32]

    Software vulnerability prediction in low-resource languages: An empirical study of codebert and chatgpt,

    T. H. M. Le, M. A. Babar, and T. H. Thai, “Software vulnerability prediction in low-resource languages: An empirical study of codebert and chatgpt,” in the 28th International Conference on Evaluation and Assessment in Software Engineering , 2024, pp. 679–685

    2024

  25. [33]

    A survey on data-driven software vulnerability assessment and prioritization,

    T. H. M. Le, H. Chen, and M. A. Babar, “A survey on data-driven software vulnerability assessment and prioritization,” ACM Computing Surveys, vol. 55, no. 5, pp. 1–39, 2022

    2022

  26. [34]

    A survey of learning- based automated program repair,

    Q. Zhang, C. Fang, Y . Ma, W. Sun, and Z. Chen, “A survey of learning- based automated program repair,” ACM Transactions on Software Engi- neering and Methodology , vol. 33, no. 2, pp. 1–69, 2023. 5

    2023

Pith tools

Reviewed August 6, 2026 · model on record in the stance chip above.