Pith. sign in

REVIEW 4 major objections 4 minor 1 cited by

FuncVul: An Effective Function Level Vulnerability Detection Model using LLM and Code Chunk

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

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

Pith's one-line read A code-chunk-based model using LLM labels and GraphCodeBERT detects function-level vulnerabilities with reported 87–92% accuracy and F1, beating baselines and improving on full-function prediction by 53.9% accuracy.

desk verdict Solid engineering, shaky ground truth: the chunking finding is real, but the unvalidated LLM labels make the headline numbers mean less than they seem. read the letter →

arxiv 2506.19453 v1 pith:WVGIAYYI submitted 2025-06-24 cs.CR

Sajal Halder , Muhammad Ejaz Ahmed , Seyit Camtepe This is my paper
classification cs.CR
keywords function-levelvulnerabilitydetectioncodechunkGraphBERTlargelanguagemodelpatchanalysissoftwaresupplychainC/C++Python
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

FuncVul aims to establish that small code chunks around patch edits, rather than whole functions, are the right unit for automated vulnerability detection. The paper builds six datasets of C/C++ and Python code chunks by combining patch information with large-language-model labels, and fine-tunes GraphCodeBERT on them. It reports an average accuracy of 89.39% and F1 of 88.94%, outperforming CodeBERT, LineVul, VulBERTa, VUDENC, and BERT, and shows that chunk-based prediction improves accuracy by 53.9% and F1 by 42.0% over full-function classification. If those results hold, developers would be able to focus fixes on the few lines that matter and catch multiple vulnerabilities within one function.

What carries the argument

The mechanism that carries the argument is the code chunk extraction algorithm, Algorithm 1. It takes a function's source and a security patch, identifies the removed (deleted) lines, and extracts the contiguous segment from three lines before the first edit to three lines after the last edit, or the edited lines alone when the edit spans more than ten lines. Ground truth labeling then requires the LLM's detected 'vul lines' to overlap those deleted lines for the chunk to be called vulnerable. The learned detector is GraphCodeBERT, a Transformer pretrained with data-flow edge prediction, fine-tuned on the chunk datasets to output a vulnerable/non-vulnerable label.

What would settle it

Manually re-annotate a random sample of the non-vulnerable chunks from Dataset 1 by reading the pre-patch code against the CVE description. If a meaningful fraction of those chunks contain the vulnerability that the patch fixed, the overlap-based labeling rule is unsound, and FuncVul's scores are inflated by label noise.

Watch

Extended reading notes

Core claim

On the paper's own terms, the central discovery is that a three-line-extended code chunk centered on a patch's edited lines preserves the local context a detector needs while excluding the unrelated code that drowns out the signal in full-function analysis. Using this chunk as input, a fine-tuned GraphCodeBERT model achieves 87–92% accuracy and 86–92% F1 across six datasets constructed from two labeling strategies: LLM-plus-patch overlap and LLM-only line detection. The paper also claims the model generalizes to unseen CVEs (81.95% accuracy) and unseen project IDs (76.69%), and that it can flag multiple vulnerable chunks inside a single function.

Load-bearing premise

The load-bearing premise is that a code chunk is genuinely vulnerable when the LLM's flagged vulnerable lines overlap the patch's deleted lines; if the LLM misses or misidentifies the true vulnerable lines, the training labels are corrupted and the reported 87–92% accuracy is an artifact of the labeling rule.

Editorial extensions

If this is right

  • Whole-function classifiers can be replaced by chunk-based ones that focus model capacity on patch-adjacent lines, reducing token counts and irrelevant context.
  • The 53.9% accuracy and 42.0% F1 gains over full-function prediction imply that distracting code, not the vulnerability itself, is the main obstacle in function-level detection.
  • Chunking a function into several segments allows a single function to receive multiple vulnerability flags, which binary function-level labels cannot express.
  • The reported cross-CVE and cross-project generalization (81.95% and 76.69%) supports the claim that the model learns transferable structural patterns rather than dataset-specific artifacts.

Reading between the lines

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

  • Editorial: the paper never validates the LLM's line-level labels against independently confirmed vulnerable lines, so part of the reported performance may measure how faithfully GraphCodeBERT reproduces Gemini 1.5 Pro's judgments rather than how well it finds real vulnerabilities.
  • Editorial: a natural extension is to treat the LLM-vs-patch disagreement as a third 'uncertain' class and train a model only on unanimous labels, which would quantify how much of FuncVul's edge comes from label noise.
  • Editorial: the chunk-vs-full-function comparison implicitly favors chunks because the train/test split is chunk-level; an evaluation that respects function boundaries (all chunks from the same function in one split) would show whether the 53.9% improvement survives realistic deployment.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

4 major / 4 minor

Summary. The paper proposes FuncVul, a code-chunk-level vulnerability detection model for C/C++ and Python. It constructs six datasets: four are labeled by requiring an overlap between Gemini 1.5 Pro's reported vulnerable lines and the deleted lines of a CVE patch, and two are labeled by the LLM alone. FuncVul fine-tunes GraphCodeBERT on these chunks and is compared with CodeBERT, CustomVulBERTa, BERT, VUDENC, and LineVul, reporting average accuracy of 87–92% and F1 of 86–92%. The paper also reports that code chunks outperform full-function prediction, that generic code chunks perform slightly worse than original code chunks, that 3-line extended chunks are best, and that the model can identify unseen CVEs/projects with 76–82% accuracy. RQ6 claims the model detects multiple vulnerabilities per function.

Significance. If the labeling methodology were independently validated, the code-chunk approach would be a practically useful contribution: it localizes vulnerabilities within functions, can be applied across C/C++ and Python, and the authors ship code and datasets publicly. The experimental comparison is systematic, using five baselines and five-fold cross-validation across six datasets, and the chunk-length sensitivity study in RQ5 is a useful analysis. However, the central ground-truth construction depends entirely on an unvalidated LLM, RQ4's test labels are unspecified, and RQ6 is not actually evaluated. These gaps directly affect the strength of the headline performance claims.

major comments (4)
  1. [Section 4.1 (Vulnerable Ground Truth)] The positive-label criterion requires that Gemini 1.5 Pro's 'vul lines' overlap with the patch's deleted lines, and Datasets 5 and 6 are labeled by the LLM alone. The same LLM is never validated against an independent source, so the reported F1 of 86–92% may reflect how well FuncVul reproduces Gemini's annotation pattern rather than how well it detects real vulnerabilities. The paper itself notes in RQ4 that many vulnerable packages remain 'Unknown' because the LLM does not detect them, and those excluded cases are likely the hard ones. Table 3 does not state how the 'Unknown' chunks in Test Cases 1 and 2 were labeled, so the 81.95% and 76.69% results cannot be interpreted as independent evidence. Please add a human or independent audit of a sample of labels, report inter-annotator agreement, and describe the exact labeling procedure for the RQ4 test sets.
  2. [Section 5.3 (RQ6)] The paper lists 'detecting multiple vulnerabilities within a single function's code' as a main contribution, but Section 5.3 contains only a qualitative description. There is no experiment, no metric, no ground-truth construction for functions with multiple vulnerabilities, and no baseline comparison. Without an evaluation protocol and quantitative results, this claim is unsupported and should either be substantiated or removed from the contributions.
  3. [Section 5.2, Table 2] Several MCC entries appear arithmetically inconsistent with the corresponding Accuracy, Precision, and Recall. For Dataset 1, with 1810 vulnerable and 2357 non-vulnerable samples, Accuracy=0.8906, Precision=0.8108, and Recall=0.9840 imply approximately TP=1781, FP=416, FN=29, TN=1941, which yields MCC≈0.80, not the reported 0.9477. Similar concerns apply to Datasets 5 and 6. Please recalculate all MCC values or explain how they were obtained, since MCC is used as a headline metric.
  4. [Section 5.2 (RQ2)] The claim that code chunks improve accuracy by 53.9% and F1 by 42.0% over full-function prediction is not verifiable from the manuscript. The text refers to 'Table 3(a)', but Table 3 lists RQ4 test-set statistics, and the full-function training/evaluation setup (data, labels, split, model configuration) is not described anywhere. Please provide the full-function results table and the experimental protocol, or remove the quantitative improvement claim.
minor comments (4)
  1. [Algorithm 1, lines 11–12] The pseudocode has typographical errors: 'start index←max(modified index[0]) - before lines, 0)' is missing the min operation, and 'end index←min(max(modified index[-1]) + after lines + 1, len(F))' should be 'min(max(modified index[-1]) + after lines + 1, len(F))'. Also, 'modified index' is initialized as a set {} but is used as a list with append and indexing; please make the pseudocode executable or clearly informal.
  2. [Table 2] The table contains formatting typos such as '0.9802±0.0.0', '0.0.021', and '0.9477±0.0025' in places where the standard deviation format is inconsistent. Please clean up all numeric formatting.
  3. [Section 5.2, RQ2 text] The sentence 'Table 3(a) compares the performance of the Full Function and Code Chunk approaches' should refer to Figure 3(a), and the heading of Table 3 should read 'New CVEs' rather than 'New CVSs'.
  4. [Appendix A.4] The MCC formula is printed without parentheses around the denominator product: as written, the square root appears to apply only to the numerator or is ambiguous. Please write it as MCC = (TP·TN − FP·FN) / sqrt((TP+FP)(TP+FN)(TN+FP)(TN+FN)).

Circularity Check

2 steps flagged · score 6.0 of 10

Ground truth is LLM-defined: FuncVul's 'vulnerable' label is the LLM's vulnerable-line detection (plus patch overlap), so the headline accuracy/F1 measure reproduction of that LLM rule, not independently validated vulnerability detection; RQ4 reuses the same Unknown pipeline without specifying test-label provenance.

  1. self definitional [Section 4.1, 'Vulnerable Ground Truth']
    "A code chunk is classified as vulnerable (class label: 1) and included in the ground truth dataset if it satisfies the following criteria: Property 1 must be fulfilled. According to Property 2, the LLM response for vul lines is not None. There is at least one overlapping line between the vul lines identified by the LLM and the deleted lines in the patch modification."

    The class label that FuncVul is trained and evaluated to predict is defined as 'LLM's vul lines overlap patch-deleted lines'. Thus Eq. (2)'s V(fc_i)=1 iff fc_i is vulnerable reduces, by construction, to V(fc_i)=1 iff the LLM flagged a vulnerable line that coincides with a patch deletion. Reported accuracy and F1 therefore measure agreement with this LLM-plus-patch rule, not with an externally validated notion of vulnerability. The model may genuinely learn the rule, but the rule itself is the input labeling heuristic; no independent ground truth confirms that the LLM's vulnerable-line judgments are correct.

  2. self definitional [Section 4.1, 'Code Chunks and Generic Code Chunks Label Data']
    "We further created two additional datasets, Dataset 5 and Dataset 6 (c.f. Section 5.1), by providing the full function code to a large language model (LLM) to identify vulnerable lines. If the LLM successfully detects at least one vulnerable line, we apply the N-line code chunking approach to generate positive samples."

    For Datasets 5 and 6, the positive label is literally 'the LLM detected at least one vulnerable line'. FuncVul is fine-tuned and evaluated on these labels, so a 90-92% F1 on Dataset 6 demonstrates that GraphCodeBERT can reproduce Gemini 1.5 Pro's vulnerable-line judgment, not that it detects vulnerabilities in any sense independent of the LLM. The same section states that negative samples use the same strategy as Datasets 1-4, making the whole benchmark an LLM-defined construct for these two datasets.

full rationale

The core training and evaluation pipeline is standard: a GraphCodeBERT model is fine-tuned on code chunks and compared with baselines on the same constructed datasets, so the relative ranking of models is internally consistent and not itself circular. There is no load-bearing self-citation chain or imported uniqueness theorem. The circularity is in the definition of the prediction target. Section 4.1 defines a positive chunk by the rule 'LLM vul lines overlap patch-deleted lines' and labels everything else Unknown; Datasets 5 and 6 define positives as 'LLM detected at least one vulnerable line'. The reported 87-92% accuracy and F1 therefore quantify how well FuncVul reproduces the LLM-based labeling heuristic, not how well it detects vulnerabilities against an independent ground truth. Patch-deleted lines provide a partial external anchor for Datasets 1-4, but the LLM's vulnerable-line judgment is never validated, and the paper explicitly admits that 'many vulnerable packages remain undetected by LLM Detect' (Section 5.2, RQ4). RQ4's test cases are drawn from this Unknown data, but the paper does not describe how the test labels were obtained; if the same LLM-overlap rule was used, RQ4 inherits the same issue. This is a partial, definition-level circularity rather than an identity between the learned model and the LLM, so the score is 6 rather than higher.

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

The work introduces no new physical or formal entities. The central claim rests on three tuning heuristics and three domain assumptions about label quality and patch semantics. The 3-line context and 10-line threshold are hand-selected parameters that influence the chunks and therefore the results.

free parameters (3)
  • 3-line context extension = 3
    Chosen as the default context size in Section 4, then validated against 1,5,7,9,10,15,20,25 lines in RQ5. The selection is made on the six datasets, so this parameter is fit to the test distribution.
  • 10-line threshold for chunk construction = 10
    In Algorithm 1, if the edited region exceeds 10 lines, the chunk is just the edited lines, otherwise 3 lines are added on each side. This heuristic has no theoretical justification and is not varied.
  • Random 5-10 lines for non-vulnerable samples
    Non-vulnerable chunks are partly drawn from fixed functions by sampling 5 to 10 arbitrary lines, as described in Section 4.1. The length is arbitrary.
assumptions (3)
  • domain assumption Single-commit CVE patches contain the vulnerability in the modified function
    Property 1 in Section 4.1 restricts the study to single-patch CVEs, asserting smaller patches are more likely to be vulnerability fixes. The paper notes 80.04% of OSV CVEs qualify, so this limits coverage.
  • domain assumption Gemini 1.5 Pro correctly identifies vulnerable lines in function code chunks
    Section 4.1 uses the LLM's 'vul lines' output as part of the ground-truth criterion. No human validation or agreement statistics are provided.
  • ad hoc to paper Overlap between LLM-identified lines and patch-deleted lines indicates true vulnerability
    The vulnerable label requires at least one overlapping line. This is the paper's constructed definition, and it may not capture vulnerabilities where the fix changes code elsewhere.

how reviews work

0 comments
Cite this review

Pith. "Pith review of FuncVul: An Effective Function Level Vulnerability Detection Model using LLM and Code Chunk." pith.science (2026). https://pith.science/paper/WVGIAYYI

@misc{pith2026250619453,
  author       = {Pith},
  title        = {Pith review of: FuncVul: An Effective Function Level Vulnerability Detection Model using LLM and Code Chunk},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/WVGIAYYI}},
  note         = {Machine review of arXiv:2506.19453}
}
read the original abstract

Software supply chain vulnerabilities arise when attackers exploit weaknesses by injecting vulnerable code into widely used packages or libraries within software repositories. While most existing approaches focus on identifying vulnerable packages or libraries, they often overlook the specific functions responsible for these vulnerabilities. Pinpointing vulnerable functions within packages or libraries is critical, as it can significantly reduce the risks associated with using open-source software. Identifying vulnerable patches is challenging because developers often submit code changes that are unrelated to vulnerability fixes. To address this issue, this paper introduces FuncVul, an innovative code chunk-based model for function-level vulnerability detection in C/C++ and Python, designed to identify multiple vulnerabilities within a function by focusing on smaller, critical code segments. To assess the model's effectiveness, we construct six code and generic code chunk based datasets using two approaches: (1) integrating patch information with large language models to label vulnerable samples and (2) leveraging large language models alone to detect vulnerabilities in function-level code. To design FuncVul vulnerability model, we utilise GraphCodeBERT fine tune model that captures both the syntactic and semantic aspects of code. Experimental results show that FuncVul outperforms existing state-of-the-art models, achieving an average accuracy of 87-92% and an F1 score of 86-92% across all datasets. Furthermore, we have demonstrated that our code-chunk-based FuncVul model improves 53.9% accuracy and 42.0% F1-score than the full function-based vulnerability prediction. The FuncVul code and datasets are publicly available on GitHub at https://github.com/sajalhalder/FuncVul.

Figures

Figures reproduced from arXiv: 2506.19453 by the authors.

Figure 1
Figure 1. Code Checks and Generic Code Chunks Label Data Generation. [PITH_FULL_IMAGE:figures/full_fig_p007_1.png] view at source ↗
Figure 2
Figure 2. Proposed code chunk based function vulnerability detection model (FuncVul) architec [PITH_FULL_IMAGE:figures/full_fig_p010_2.png] view at source ↗
Figure 3
Figure 3. Comparison between our proposed code chunk based results with full function code based [PITH_FULL_IMAGE:figures/full_fig_p014_3.png] view at source ↗
Figures from the paper (2 more)
Figure 4
Figure 4. Figure 4: Comparison between our proposed code chunk based results with generic code chunk [PITH_FULL_IMAGE:figures/full_fig_p014_4.png]
Figure 5
Figure 5. Figure 5: Impacts of code chunk length on dataset 6. [PITH_FULL_IMAGE:figures/full_fig_p016_5.png]

Discussion (0). Sign in to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. Beyond Embeddings: Interpretable Feature Extraction for Binary Code Similarity

    cs.AI 2025-09 conditional novelty 6.0 of 10

    LLM-generated structured assembly features achieve cross-architecture and cross-optimization binary code similarity retrieval competitive with trained embeddings, and a hybrid method beats both.

Reference graph

Works this paper leans on

38 extracted references · 33 canonical work pages · cited by 1 Pith paper

  1. [1]

    In: 2023 IEEE 9th International Women in En- gineering (WIE) Conference on Electrical and Computer Engineering (WIECON-ECE)

    Akuthota, V., Kasula, R., Sumona, S.T., Mohiuddin, M., Reza, M.T., Rahman, M.M.: Vulner- ability detection and monitoring using llm. In: 2023 IEEE 9th International Women in En- gineering (WIE) Conference on Electrical and Computer Engineering (WIECON-ECE). pp. 309–314. IEEE (2023)

    work page 2023

  2. [2]

    Chakraborty, S., Krishna, R., Ding, Y., Ray, B.: Deep learning based vulnerability detection: Are we there yet? IEEE Transactions on Software Engineering48(9), 3280–3296 (2021)

    work page 2021

  3. [3]

    CVE: Common vulnerabilities and exposures.https://cve.mitre.org(2024), ac- cessed: 2024-11-12

    work page 2024

  4. [4]

    In: Proceedings of the 19th ACM Asia Conference on Computer and Communications Se- curity

    Dunlap, T., Lin, E., Enck, W., Reaves, B.: Vfcfinder: Pairing security advisories and patches. In: Proceedings of the 19th ACM Asia Conference on Computer and Communications Se- curity. pp. 1128–1142 (2024)

    work page 2024

  5. [5]

    arXiv preprint arXiv:2002.08155 (2020)

    Feng, Z., Guo, D., Tang, D., Duan, N., Feng, X., Gong, M., Shou, L., Qin, B., Liu, T., Jiang, D., et al.: Codebert: A pre-trained model for programming and natural languages. arXiv preprint arXiv:2002.08155 (2020)

    arXiv 2020

  6. [6]

    In: Proceedings of the 19th International Conference on Mining Software Repositories

    Fu, M., Tantithamthavorn, C.: Linevul: A transformer-based line-level vulnerability predic- tion. In: Proceedings of the 19th International Conference on Mining Software Repositories. pp. 608–620 (2022)

    work page 2022

  7. [7]

    arXiv preprint arXiv:2009.08366 (2020)

    Guo, D., Ren, S., Lu, S., Feng, Z., Tang, D., Liu, S., Zhou, L., Duan, N., Svyatkovskiy, A., Fu, S., et al.: Graphcodebert: Pre-training code representations with data flow. arXiv preprint arXiv:2009.08366 (2020)

    arXiv 2020

  8. [8]

    In: European symposium on research in computer security

    Guo, Y., Patsakis, C., Hu, Q., Tang, Q., Casino, F.: Outside the comfort zone: Analysing llm capabilities in software vulnerability detection. In: European symposium on research in computer security. pp. 271–289. Springer (2024)

    work page 2024

Show all 38 references
  1. [9]

    In: 2022 International joint conference on neural networks (IJCNN)

    Hanif, H., Maffeis, S.: Vulberta: Simplified source code pre-training for vulnerability de- tection. In: 2022 International joint conference on neural networks (IJCNN). pp. 1–8. IEEE (2022)

    2022

  2. [10]

    In: Proceedings of the 19th international conference on mining software repositories

    Hin, D., Kan, A., Chen, H., Babar, M.A.: Linevd: Statement-level vulnerability detection us- ing graph neural networks. In: Proceedings of the 19th international conference on mining software repositories. pp. 596–607 (2022)

    2022

  3. [11]

    In: 2023 IEEE 8th European Sym- posium on Security and Privacy (EuroS&P)

    Islam, N.T., Parra, G.D.L.T., Manuel, D., Bou-Harb, E., Najafirad, P.: An unbiased transformer source code learning with semantic vulnerability graph. In: 2023 IEEE 8th European Sym- posium on Security and Privacy (EuroS&P). pp. 144–159. IEEE (2023)

    2023

  4. [12]

    In: Proceedings of naacL-HLT

    Kenton, J.D.M.W.C., Toutanova, L.K.: Bert: Pre-training of deep bidirectional transformers for language understanding. In: Proceedings of naacL-HLT. vol. 1, p. 2. Minneapolis, Min- nesota (2019)

    2019

  5. [13]

    In: Proceedings of the 29th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering

    Li, Y., Wang, S., Nguyen, T.N.: Vulnerability detection with fine-grained interpretations. In: Proceedings of the 29th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering. pp. 292–303 (2021)

    2021

  6. [14]

    IEEE Transactions on Dependable and Secure Computing 19(4), 2821–2837 (2021)

    Li, Z., Zou, D., Xu, S., Chen, Z., Zhu, Y., Jin, H.: Vuldeelocator: a deep learning-based fine- grained vulnerability detector. IEEE Transactions on Dependable and Secure Computing 19(4), 2821–2837 (2021)

    2021

  7. [15]

    In: Proceedings of the 32nd annual conference on computer security applications

    Li, Z., Zou, D., Xu, S., Jin, H., Qi, H., Hu, J.: Vulpecker: an automated vulnerability detection system based on code similarity analysis. In: Proceedings of the 32nd annual conference on computer security applications. pp. 201–213 (2016)

    2016

  8. [16]

    arXiv preprint arXiv:1801.01681 (2018)

    Li, Z., Zou, D., Xu, S., Ou, X., Jin, H., Wang, S., Deng, Z., Zhong, Y.: Vuldeepecker: A deep learning-based system for vulnerability detection. arXiv preprint arXiv:1801.01681 (2018)

    2018 arXiv

  9. [17]

    arXiv preprint arXiv:1907.11692364(2019)

    Liu, Y.: Roberta: A robustly optimized bert pretraining approach. arXiv preprint arXiv:1907.11692364(2019)

    2019 arXiv

  10. [18]

    Journal of Systems and Software 212, 112031 (2024)

    Lu, G., Ju, X., Chen, X., Pei, W., Cai, Z.: Grace: Empowering llm-based software vulnerability detection with graph structure and in-context learning. Journal of Systems and Software 212, 112031 (2024)

    2024

  11. [19]

    In: Proceedings of the ACM/IEEE 44th International Conference on Software Engineering: Companion Proceedings

    Nguyen, V.A., Nguyen, D.Q., Nguyen, V., Le, T., Tran, Q.H., Phung, D.: Regvd: Revisiting graph neural networks for vulnerability detection. In: Proceedings of the ACM/IEEE 44th International Conference on Software Engineering: Companion Proceedings. pp. 178–182 (2022)

    2022

  12. [20]

    NVD: National vulnerability database (2024),https://nvd.nist.gov, accessed on November 12, 2024

    2024

  13. [21]

    In: Pro- ceedings of the 2019 27th ACM Joint Meeting on European Software Engineering Confer- ence and Symposium on the Foundations of Software Engineering

    Sonnekalb, T.: Machine-learning supported vulnerability detection in source code. In: Pro- ceedings of the 2019 27th ACM Joint Meeting on European Software Engineering Confer- ence and Symposium on the Foundations of Software Engineering. pp. 1180–1183 (2019)

    2019

  14. [22]

    arXiv preprint arXiv:2403.05530 (2024)

    Team, G., Georgiev, P., Lei, V.I., Burnell, R., Bai, L., Gulati, A., Tanzer, G., Vincent, D., Pan, Z., Wang, S., et al.: Gemini 1.5: Unlocking multimodal understanding across millions of tokens of context. arXiv preprint arXiv:2403.05530 (2024)

    2024 arXiv

  15. [23]

    Future Generation Computer Systems163, 107504 (2025)

    Tran, H.C., Tran, A.D., Le, K.H.: Detectvul: A statement-level code vulnerability detection for python. Future Generation Computer Systems163, 107504 (2025)

    2025

  16. [24]

    Vaswani, A., Shazeer, N., Parmar, N., Uszkoreit, J., Jones, L., Gomez, A.N., Kaiser, L., Polo- sukhin, I.: Attention is all you need. nips’17. In: Proceedings of the 31st International Con- ference on Neural Information Processing Systems December. pp. 6000–6010 (2017)

    2017

  17. [25]

    Vo, H.D., Nguyen, S.: Can an old fashioned feature extraction and a light-weight model im- prove vulnerability type identification performance? Information and Software Technology 164, 107304 (2023)

    2023

  18. [26]

    IEEE Transactions on Information Forensics and Security16, 1943–1958 (2020)

    Wang, H., Ye, G., Tang, Z., Tan, S.H., Huang, S., Fang, D., Feng, Y., Bian, L., Wang, Z.: Combin- ing graph-based learning with automated data collection for code vulnerability detection. IEEE Transactions on Information Forensics and Security16, 1943–1958 (2020)

    2020

  19. [27]

    Ap- plied Sciences10(6), 1943 (2020)

    Wang, X., Chen, K., Kang, T., Ouyang, J.: A dynamic coarse grain discrete element method for gas-solid fluidized beds by considering particle-group crushing and polymerization. Ap- plied Sciences10(6), 1943 (2020)

    2020

  20. [28]

    In: Proceedings of the 2024 IEEE/ACM 46th International Con- ference on Software Engineering: Companion Proceedings

    Wang, X., Hu, R., Gao, C., Wen, X.C., Chen, Y., Liao, Q.: Reposvul: A repository-level high- quality vulnerability dataset. In: Proceedings of the 2024 IEEE/ACM 46th International Con- ference on Software Engineering: Companion Proceedings. pp. 472–483 (2024)

    2024

  21. [29]

    Information and Software Technology 144, 106809 (2022)

    Wartschinski, L., Noller, Y., Vogel, T., Kehrer, T., Grunske, L.: Vudenc: vulnerability detection with deep learning on a natural codebase for python. Information and Software Technology 144, 106809 (2022)

    2022

  22. [30]

    Algorithms14(11), 335 (2021)

    Wei, H., Lin, G., Li, L., Jia, H.: A context-aware neural embedding for function-level vulner- ability detection. Algorithms14(11), 335 (2021)

    2021

  23. [31]

    In: 2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE)

    Wen, X.C., Chen, Y., Gao, C., Zhang, H., Zhang, J.M., Liao, Q.: Vulnerability detection with graph simplification and enhanced graph representation learning. In: 2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE). pp. 2275–2286. IEEE (2023)

    2023

  24. [32]

    In: Proceedings of the 44th International Conference on Software Engineering

    Wu, Y., Zou, D., Dou, S., Yang, W., Xu, D., Jin, H.: Vulcnn: An image-inspired scalable vulner- ability detection system. In: Proceedings of the 44th International Conference on Software Engineering. pp. 2365–2376 (2022)

    2022

  25. [33]

    In: 2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE)

    Xia, C.S., Wei, Y., Zhang, L.: Automated program repair in the era of large pre-trained lan- guage models. In: 2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE). pp. 1482–1494. IEEE (2023)

    2023

  26. [34]

    Journal of Information Security and Applications81, 103718 (2024)

    Yuan, X., Lin, G., Mei, H., Tai, Y., Zhang, J.: Software vulnerable functions discovery based on code composite feature. Journal of Information Security and Applications81, 103718 (2024)

    2024

  27. [35]

    Advances in neural information processing systems32(2019) A Appendix A.1 Generic Code Conversion LLM Prompt Generic code chunks converts code chunks in generic format

    Zhou, Y., Liu, S., Siow, J., Du, X., Liu, Y.: Devign: Effective vulnerability identification by learning comprehensive program semantics via graph neural networks. Advances in neural information processing systems32(2019) A Appendix A.1 Generic Code Conversion LLM Prompt Gener...

    2019

  28. [36]

    Return these lines in a list of string named asline code

    Identify the lines of code that contain vulnerabilities. Return these lines in a list of string named asline code. If no vulnerable lines are found, return [’None’]. Ensure the list is formatted with items separated by commas and enclosed in square brackets

  29. [37]

    Return these line numbers in a list of integer named asvul lines

    Determine the line numbers of vulnerable code. Return these line numbers in a list of integer named asvul lines. If no such lines exist, return [’None’]

  30. [38]

    Return these in a list of string named as vul category

    List the affected vulnerability categories. Return these in a list of string named as vul category. If no categories are affected, return [’None’]. Please provide the output in three keys as dictionary format:line code,vul lines, and vul category. Do not need an explanation. T...

Pith tools

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