Automated code-review systems can identify potential defects, but they often provide limited explanations for developers. This study investigates a curriculum-based approach for fine-tuning CodeT5+ 770M to generate code-review and vulnerability explanations for Python and JavaScript. Training was divided into three stages: code understanding, semantic review, and vulnerability explanation. Rehearsal examples from earlier stages were included during later training to reduce forgetting. We also compared this staged approach with an earlier mixed-phase setup that trained on all tasks together, to see whether staging changed how the training process behaved. During Stage 3, we found that using case-specific CVE descriptions as targets led the model to generate unsupported package names, versions, and repository references. We replaced these targets with CWE-level descriptions and retrained the model. In a manual review of 20 outputs, the revised model did not produce the same type of unsupported specific details. BLEU increased from 7.54 to 34.43, and ROUGE-1 increased from 0.2765 to 0.4180. However, the revised model still confused CWE categories: exact category agreement was 27.3% after excluding samples with incomplete ground-truth labels, and Cross-Site Scripting was predicted more often than its true frequency. We also tested whether increasing the Stage 2 target length from 192 to 512 tokens improved later Stage 3 performance. Across six epochs, the average validation-loss difference was +0.0008, and the final Stage 3 metrics showed no meaningful change. These results show that target design and manual inspection are important when evaluating generated vulnerability explanations, and that negative results, like the target-length test here, are worth reporting alongside positive ones.
Introduction
The text presents a study on using large language models (LLMs) to improve automated code review and vulnerability explanations. The researchers fine-tuned CodeT5+ 770M on Python and JavaScript code and investigated two main questions: whether tasks should be trained sequentially using a curriculum or jointly, and how to reduce unsupported or fabricated details in security explanations.
Main approach
The researchers designed a three-stage curriculum:
Syntax/structure: Learn basic code understanding through docstring generation.
Semantic/review: Generate code-review comments.
Vulnerability: Explain security vulnerabilities.
Because sequential training can cause catastrophic forgetting, rehearsal examples from earlier stages were included in later stages.
The study compared this staged approach with an earlier mixed-phase training setup, although the authors caution that the two approaches were not directly comparable because their training objectives differed.
The most important problem discovered was that the model sometimes generated specific but unsupported information, such as package names, versions, and repository references that were not present in the input code.
The researchers believed this happened partly because they trained the model to reproduce detailed CVE descriptions, which contain case-specific facts that are difficult to associate reliably with small code examples.
They therefore changed the target from CVE descriptions to more general CWE descriptions, which explain vulnerability categories rather than individual cases.
This substantially improved automatic metrics:
BLEU: 7.54 → 34.43
ROUGE-1: 0.2765 → 0.4180
BERTScore: 0.8601 → 0.8857
Best validation loss: 2.0823 → 0.5182
In a manual check of 20 outputs, unsupported specific details went from present to 0/20.
However, the authors emphasize that the higher scores do not necessarily mean better vulnerability understanding, because CWE descriptions are more standardized and therefore easier to predict.
Remaining problem
The revised model still struggled with fine-grained vulnerability classification.
It correctly predicted the exact CWE category for only:
22.3% of all Stage 3 test examples.
27.3% after removing examples labeled “Insufficient Information.”
The model tended to overpredict common categories, especially Cross-Site Scripting (XSS). This suggests that class imbalance caused the model to favour frequent vulnerability categories when uncertain.
Other findings
Stage 1 performed best on n-gram metrics because code-understanding/documentation is more constrained.
Stage 2 had lower BLEU/ROUGE, but its relatively high BERTScore suggests that generated review comments could still be semantically appropriate. Code review is naturally a one-to-many task, so exact word overlap is not always a good measure.
Increasing Stage 2's maximum target length from 192 to 512 tokens did not produce a meaningful improvement in downstream vulnerability performance.
The staged curriculum made it easier to isolate and diagnose the vulnerability-explanation fabrication problem compared with mixed training.
Conclusion
This study evaluated a three-stage fine-tuning procedure for generating code-review and vulnerability explanations with CodeT5+ 770M. The staged setup allowed the vulnerability-explanation task to be evaluated separately from code understanding and review-comment generation. When the model was trained with case-specific CVE descriptions, some outputs included unsupported package names, versions, and repository references. Replacing these targets with CWE-level descriptions removed this behavior in the 20 manually reviewed outputs and improved automatic evaluation scores. However, the revised task used more standardized targets, so the metric improvement should not be interpreted only as improved vulnerability understanding. Fine-grained CWE classification remained limited, with category confusion that was likely affected by class imbalance. Increasing the Stage 2 target length from 192 to 512 tokens also did not produce a clear improvement in downstream Stage 3 performance. We think findings like this are worth reporting even when they don\'t show an improvement, since knowing what does not help is still useful for anyone building on this work. Future work should evaluate class-balanced training, larger manually reviewed test sets, better grounding in verified vulnerability metadata, a separate classifier stage to strengthen detection alongside the existing static-analysis tools, and models with larger context windows.
References
[1] X. Tang, K. Kim, Y. Song, C. Lothritz, B. Li, S. Ezzini, H. Tian, J. Klein, and T. F. Bissyandé, \"CodeAgent: Autonomous communicative agents for code review,\" in Proc. 2024 Conf. Empirical Methods in Natural Language Processing (EMNLP), Miami, FL, USA, 2024, pp. 11279-11313.
[2] H. Pearce, B. Tan, B. Ahmad, R. Karri, and B. Dolan-Gavitt, \"Examining zero-shot vulnerability repair with large language models,\" in Proc. 44th IEEE Symp. Security and Privacy (SP), 2023, pp. 2339-2356, doi: 10.1109/SP46215.2023.10179420.
[3] M. Naïr, K. Yamani, L. Said Lhadj, and R. Baghdadi, \"Curriculum learning for small code language models,\" in Proc. 62nd Annu. Meeting Assoc. Comput. Linguistics (ACL), Student Research Workshop, Bangkok, Thailand, 2024, pp. 390-401, doi: 10.18653/v1/2024.acl-srw.44.
[4] P. Buzzega, M. Boschini, A. Porrello, D. Abati, and S. Calderara, \"Dark experience for general continual learning: A strong, simple baseline,\" in Adv. Neural Inf. Process. Syst. (NeurIPS), vol. 33, 2020, pp. 15920-15930.
[5] S. Lipp, S. Banescu, and A. Pretschner, \"An empirical study on the effectiveness of static C code analyzers for vulnerability detection,\" in Proc. 31st ACM SIGSOFT Int. Symp. Software Testing and Analysis (ISSTA \'22), Virtual, South Korea, 2022, pp. 544-555, doi: 10.1145/3533767.3534380.