Pith. sign in

REVIEW 4 major objections 6 minor 2 cited by

Guiding AI to Fix Its Own Flaws: An Empirical Study on LLM-Driven Secure Code Generation

T0 review · 4 major / 6 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 Most LLMs generate vulnerable Python code at rates up to 27%, and self-generated vulnerability hints plus explained CodeQL feedback reduce those rates mainly for strong instruction-following models.

desk verdict A credible and useful empirical study of LLM secure code generation, but every headline rate rides on unvalidated CodeQL detections, so the exact numbers should be treated as approximate until a human-labeled sample confirms the oracle. read the letter →

arxiv 2506.23034 v1 pith:LJQYD5MK submitted 2025-06-28 cs.SE

Hao Yan , Swapneel Suhas Vaidya , Xiaokuan Zhang , Ziyu Yao This is my paper
classification cs.SE
keywords largelanguagemodelssecurecodegenerationvulnerabilityrepairself-generatedhintsexplainedfeedbackQLPythonvulnerabilitiesempiricalevaluation
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

The paper tries to establish that modern LLMs, proprietary and open-weight, routinely generate insecure Python code, and that two practical interventions—self-generated vulnerability hints before code generation and explained CodeQL feedback for repair—reduce vulnerability rates only for models with strong instruction-following ability. Across eight models on two benchmarks, target-vulnerability rates range from 4.0% to 15.0% on SecCodePLT and from 9.9% to 27.3% on SecurityEval. GPT-4o's target-vulnerability rate drops from 15.0% to 2.6% on SecCodePLT when the prompt is augmented with its own hints, whereas weaker models often gain nothing or get worse. If correct, the findings argue that LLM-based code generation should not be used unaided, and that security scanners plus contextual explanation should be part of the workflow.

What carries the argument

The central mechanism is a two-stage prompting pipeline. First, the model is asked to list five potential CWEs for a coding task ('self-generated vulnerability hints'), and those hints are inserted into the code-generation prompt; the paper measures their effect with target-vulnerability rate (TarV-R, the share of snippets containing the benchmark's labeled CWE) and all-vulnerability rate (AllV-R, the share containing any CodeQL-detected vulnerability). Second, for repair, CodeQL's raw findings are given either directly or after GPT-4o rewrites them into explanations and fix suggestions ('explained feedback'). The paper uses CodeQL as the detection oracle throughout, so every rate and improvement figure is a CodeQL verdict.

What would settle it

Manually inspect a random sample of the generated snippets from both benchmarks and compare human judgments of vulnerability presence against CodeQL's verdicts; if disagreement is substantial, the headline rates and improvement numbers would need revision.

Watch

Extended reading notes

Core claim

On the paper's own terms, the discovery is that vulnerability rates are substantial but improvable: all eight evaluated models produce vulnerable code at non-trivial rates, with the same frequent CWE types appearing across models. Self-generated vulnerability hints reduce target-vulnerability rates when the hints are relevant and precise, and context-specific hints outperform bare CWE definitions; irrelevant hints can increase vulnerability rates. Post-hoc repair with CodeQL feedback works mainly for advanced models, and explained feedback—GPT-4o's natural-language interpretation of CodeQL output—consistently beats raw direct feedback, e.g., DeepSeek-Coder-V2's all-vulnerability rate on SecurityEval drops from 28.9% to 20.7% with explained feedback. The paper frames the bottleneck as instruction-following capability: models that cannot use hints or feedback well show little or no improvement.

Load-bearing premise

The study counts a code snippet as vulnerable (or not) solely on what CodeQL reports, and no manual audit of CodeQL's positives and negatives on the generated code is reported.

Editorial extensions

If this is right

  • Developers should not assume newer or larger models are safer: GPT-4o had higher vanilla vulnerability rates than GPT-3.5-turbo on both benchmarks.
  • Pairing a code-optimized generator with a strong instruction-following model for hint prediction and repair could lower vulnerability rates without manual expertise.
  • Irrelevant self-generated hints are not harmless; they can raise target-vulnerability rates, so hint filtering or ranking based on relevance matters.
  • Explained feedback is the more effective repair signal for capable models, so security tools should expose natural-language explanations, not just raw alerts.

Reading between the lines

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

  • A testable extension is to rerun the same pipeline with a second static analyzer or a manual vulnerability audit; if the detector's false positive or false negative rate is high, every reported rate and improvement would shift.
  • Because the explainer is itself an LLM (GPT-4o), the repair gains may partly reflect GPT-4o's reasoning rather than the feedback structure; using a cheaper or weaker explainer would test how much of the benefit is transferable.
  • The overlapping top-10 vulnerability distributions across models suggest that a small shared set of CWE types could become training-data interventions, potentially improving security across the board.
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 / 6 minor

Summary. This paper presents an empirical study of eight proprietary and open-weight LLMs on Python secure code generation using two benchmarks (SecurityEval and SecCodePLT). It reports three sets of measurements: (RQ1) the rate at which each model generates code containing the target vulnerability (TarV-R) or any vulnerability (AllV-R), as detected by CodeQL; (RQ2) whether augmenting prompts with self-generated vulnerability hints reduces these rates; and (RQ3) whether post-hoc repair with direct CodeQL feedback or with GPT-4o-generated explained feedback reduces the AllV-R of code that was initially vulnerable. The headline findings are that all models generate vulnerable code at non-trivial rates, that self-generated hints help mainly models with strong instruction-following (e.g., GPT-4o TarV-R drops from 15.0% to 2.6% on SecCodePLT), and that explained feedback tends to improve repair for the more capable models.

Significance. If the measurements are trustworthy, the study provides a useful comparative benchmark of current LLMs' secure-code behavior and gives developers evidence-based advice to not trust unaided LLM output. The paper has several strengths: it covers a broad range of model families and sizes, uses two established benchmarks, ships an anonymized code repository, and includes manual validation of the GPT-4o-generated explained feedback and of the GPT-4o hint-precision judgments. The broad qualitative observation that all evaluated models generate vulnerable code is robust because it holds across models and benchmarks. The main risk to significance is that every quantitative claim is computed from unvalidated CodeQL detections; if CodeQL has systematic false positives or false negatives on this generated Python code, then the rates, rankings, and repair improvements all change.

major comments (4)
  1. [Section 4 (Evaluations) and Section 6 (Threats to validity)] All headline rates (TarV-R, AllV-R) and all repair outcomes are computed solely from CodeQL detections, yet the paper reports no manual validation of CodeQL positives or negatives on the generated code. The only manual validations are of the explained feedback (Section 5.3) and of GPT-4o's hint-precision judgments (Section 5.2), not of the vulnerability labels themselves. Section 4 also excludes 274 SecCodePLT samples covering 6 CWEs because they are "not covered by CodeQL," which demonstrates incomplete coverage. If CodeQL systematically misses vulnerabilities or fires false positives, every rate in Tables 3, 4, 7, and 8 and every repair delta is affected. The authors should randomly sample a few hundred generated code snippets, obtain human expert labels, report CodeQL's precision and recall on that sample, and either correct the rates or provide a sensitivity analysis bounding the impact of oracle error.
  2. [Section 5, Tables 3, 4, 5, 7, and 8] No confidence intervals or significance tests are reported for any of the headline comparisons. Many subgroup analyses use very small denominators; for example, in Table 5, the SecurityEval 'Hints w. TarV' groups have n=17 for CodeLlama-7B, n=11 for Llama3.2-3B, and n=40 for CodeLlama-34B. Differences on such samples, such as CodeLlama-7B's TarV-R change from 11.8% to 17.6% on SecurityEval, are well within sampling noise. Because the same coding questions are measured under the vanilla and hint conditions, paired tests (e.g., McNemar) or at least exact binomial confidence intervals should be reported before making qualitative claims such as 'hints including the target vulnerability generally lead to lower TarV-R.'
  3. [Section 5.3, Table 8] The RQ3 conclusion that 'explained feedback' is more effective than direct feedback is not supported uniformly: for GPT-4o on SecurityEval, the AllV-R is identical (13.2%) for direct and explained feedback, and for CodeLlama-7B and CodeLlama-34B there is no improvement under either feedback. The paper should qualify the conclusion to specific models and datasets, and should report per-vulnerable-sample repair success rates (e.g., the percentage of CodeQL-flagged vulnerable snippets that are no longer flagged after repair). This would separate repair effectiveness from the initial vulnerability rate and would make the comparisons across models and feedback conditions direct.
  4. [Section 5.2, Table 5] The comparison between 'Hints w. TarV' and 'Hints w/o TarV' is an observational split based on the model's own hint generation, so it is confounded with model ability: a model that can name the correct target CWE is likely to be a better secure coder to begin with. The text presents the Table 5 results as causal evidence without acknowledging this selection confound. The controlled experiments in Table 7, where the target hint is provided exogenously, are the appropriate basis for causal claims, and the paper should explicitly say so.
minor comments (6)
  1. [Section 1, Contributions] The phrase 'prompting-based vulnerable code pair' should be 'prompting-based vulnerable code repair.'
  2. [Tables 2 and 3] Model names are inconsistent between tables: Table 2 uses 'StarCode2-15B' and 'DeepSeek-Coder-V2-Lite-Instruct', while Table 3 uses 'StarCoder2-15B' and 'DeepSeekV2-16B'. Please standardize the naming.
  3. [Abstract and Section 5.1] The abstract states that models generate vulnerable code 'at rates ranging from 9.8% to 42.1%,' but Table 3 shows SecCodePLT TarV-R for StarCoder2-15B is 4.0%, which is outside this range. Please clarify which metric and dataset the range refers to.
  4. [Section 5.3 and Table 8] The text says repair is applied only to a subset of code where any vulnerability was detected, but Table 8 reports AllV-R changes over the full dataset. Please define the denominator and the computation of the subscript changes so readers can interpret the repair effectiveness metric correctly.
  5. [Section 5.3] The explained feedback is generated by GPT-4o for all models, including GPT-4o itself. The paper should explicitly mention that GPT-4o's own repair results may benefit from self-consistency with the feedback style, even though the feedback was manually validated for correctness.
  6. [Figure 6] The caption and text should clarify that the 'top-10 vulnerabilities' are computed only on SecCodePLT, and the figure would benefit from a labeled y-axis showing the frequency or count.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: the vulnerability rates and repair outcomes are direct empirical measurements against external benchmarks and the external CodeQL scanner; the GPT-4o self-involvement is a potential confound, not a circular derivation.

full rationale

This paper is an empirical measurement study, not a derivation-from-input. The central quantities (TarV-R and AllV-R) are defined directly as counts of CodeQL-detected vulnerable samples divided by total samples, and every headline rate, hint effect, and repair delta is computed from those external measurements on the SecurityEval and SecCodePLT benchmarks. There is no fitted parameter that is later renamed as a prediction, no definition of an output in terms of an input, and no uniqueness theorem or load-bearing self-citation; the references are to prior third-party benchmarks and tools, not to the authors' own prior results. The self-referential elements that exist are (a) GPT-4o generating the explained feedback and also being one of the evaluated repair models, and (b) GPT-4o serving as the 'LLM-as-judge' for hint preciseness, including for its own hints. These are legitimate threats to cross-model comparability and could bias the relative ranking of GPT-4o, but they do not make any reported quantity equivalent to its own input by construction; the outcomes still depend on the actual generated code and CodeQL detections. The paper also explicitly acknowledges in Threats to validity that CodeQL fails to capture dynamic vulnerabilities and that results are limited to static Python analysis. Since no specific circular reduction can be exhibited from the paper's own equations or citations, the appropriate finding is no significant circularity.

Assumptions & free parameters 2 free parameters · 4 assumptions · 0 invented entities

The central results rely on external measurement assumptions rather than on fitted parameters. The only hand-chosen experimental numbers are the hint count k=5 and unreported sampling hyperparameters. The main epistemic weight rests on CodeQL and benchmark labels being correct.

free parameters (2)
  • top-k self-generated hints (k=5) = 5
    Chosen by hand without reported ablation; the number and specificity of hints directly affect whether the target vulnerability is included and how much TarV-R drops.
  • LLM sampling parameters (temperature, top-p, seed) = not reported
    Generation hyperparameters are not reported; they influence all generated code and therefore all vulnerability and repair rates.
assumptions (4)
  • domain assumption CodeQL static analysis accurately distinguishes vulnerable from non-vulnerable generated Python code.
    All metrics in Tables 3, 4, 7, and 8 are computed from CodeQL detections; Section 6 notes CodeQL misses dynamic and runtime vulnerabilities, but no false-positive rate on these benchmarks is measured.
  • domain assumption SecurityEval and SecCodePLT target CWE labels correctly identify the vulnerability each task intends.
    TarV-R is defined relative to these labels; the paper does not audit the labels.
  • domain assumption GPT-4o's binary preciseness judgments approximate human judgments well enough to rank models.
    Validated on 80 pairs with reported precision 95.65% and recall 91.67%; the sample is small and covers only a fraction of the hint set.
  • domain assumption GPT-4o-generated explained feedback is correct and actionable at the claimed rate.
    Manual validation on 160 samples is reported; the sample is small relative to the full repair set.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Guiding AI to Fix Its Own Flaws: An Empirical Study on LLM-Driven Secure Code Generation." pith.science (2026). https://pith.science/paper/LJQYD5MK

@misc{pith2026250623034,
  author       = {Pith},
  title        = {Pith review of: Guiding AI to Fix Its Own Flaws: An Empirical Study on LLM-Driven Secure Code Generation},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/LJQYD5MK}},
  note         = {Machine review of arXiv:2506.23034}
}
read the original abstract

Large Language Models (LLMs) have become powerful tools for automated code generation. However, these models often overlook critical security practices, which can result in the generation of insecure code that contains vulnerabilities-weaknesses or flaws in the code that attackers can exploit to compromise a system. However, there has been limited exploration of strategies to guide LLMs in generating secure code and a lack of in-depth analysis of the effectiveness of LLMs in repairing code containing vulnerabilities. In this paper, we present a comprehensive evaluation of state-of-the-art LLMs by examining their inherent tendencies to produce insecure code, their capability to generate secure code when guided by self-generated vulnerability hints, and their effectiveness in repairing vulnerabilities when provided with different levels of feedback. Our study covers both proprietary and open-weight models across various scales and leverages established benchmarks to assess a wide range of vulnerability types. Through quantitative and qualitative analyses, we reveal that although LLMs are prone to generating insecure code, advanced models can benefit from vulnerability hints and fine-grained feedback to avoid or fix vulnerabilities. We also provide actionable suggestions to developers to reduce vulnerabilities when using LLMs for code generation.

Figures

Figures reproduced from arXiv: 2506.23034 by the authors.

Figure 1
Figure 1. We performed a comprehensive evaluation of LLMs [PITH_FULL_IMAGE:figures/full_fig_p001_1.png] view at source ↗
Figure 2
Figure 2. Example prompt for vanilla code generation. [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 4
Figure 4. Example prompt for post-hoc vulnerable code repair [PITH_FULL_IMAGE:figures/full_fig_p005_4.png] view at source ↗
Figures from the paper (2 more)
Figure 5
Figure 5. Figure 5: Up: Example prompt for explained feedback gener [PITH_FULL_IMAGE:figures/full_fig_p005_5.png]
Figure 6
Figure 6. Figure 6: The distribution of the top-10 vulnerabilities across all LLMs on SecCodePLT. In practice, models share most of the [PITH_FULL_IMAGE:figures/full_fig_p008_6.png]

Discussion (0). Sign in to comment.

Forward citations

Cited by 2 Pith papers

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

  1. From Evaluation to Optimisation: Hierarchy-Aware Training Signals for CWE Prediction in Python

    cs.LG 2026-07 conditional novelty 6.0 of 10

    Using the ALPHA hierarchy penalty as a direct GRPO reward improves CWE prediction under distribution shift, while supervised delivery of the same penalty regresses below zero-shot.

  2. Tool-Guided Retrieval-Augmented Repair for Securing LLM-Generated C Code

    cs.SE 2026-07 conditional novelty 5.0 of 10

    A tool-guided repair loop with a growing fix-pattern repository lowers compilation failures and CodeQL-flagged security issues in LLM-generated C code.

Reference graph

Works this paper leans on

71 extracted references · 25 canonical work pages · cited by 2 Pith papers

  1. [1]

    [n. d.]. https://cwe.mitre.org/

    work page

  2. [2]

    Josh Achiam, Steven Adler, Sandhini Agarwal, Lama Ahmad, Ilge Akkaya, Floren- cia Leoni Aleman, Diogo Almeida, Janko Altenschmidt, Sam Altman, Shyamal Anadkat, et al. 2023. Gpt-4 technical report.arXiv preprint arXiv:2303.08774 (2023)

    arXiv 2023

  3. [3]

    Meta AI. [n. d.]. Llama 3.2: Revolutionizing edge ai and vision with open, cus- tomizable models. https://ai.meta.com/blog/llama-3-2-connect-2024-vision- edge-mobile-devices/

    work page 2024

  4. [4]

    Owura Asare, Meiyappan Nagappan, and N Asokan. 2023. Is github’s copilot as bad as humans at introducing vulnerabilities in code?Empirical Software Engineering28, 6 (2023), 129

    2023

  5. [5]

    Jacob Austin, Augustus Odena, Maxwell Nye, Maarten Bosma, Henryk Michalewski, David Dohan, Ellen Jiang, Carrie Cai, Michael Terry, Quoc Le, et al. 2021. Program synthesis with large language models.arXiv preprint arXiv:2108.07732(2021)

    arXiv 2021

  6. [6]

    Pavel Avgustinov, Oege De Moor, Michael Peyton Jones, and Max Schäfer. 2016. QL: Object-oriented queries on relational data. In30th European Conference on Object-Oriented Programming (ECOOP 2016). Schloss Dagstuhl–Leibniz-Zentrum für Informatik, 2–1

    work page 2016

  7. [7]

    Manish Bhatt, Sahana Chennabasappa, Yue Li, Cyrus Nikolaidis, Daniel Song, Shengye Wan, Faizan Ahmad, Cornelius Aschermann, Yaohui Chen, Dhaval Kapil, et al. 2024. Cyberseceval 2: A wide-ranging cybersecurity evaluation suite for large language models.arXiv preprint arXiv:2404.13161(2024)

    arXiv 2024

  8. [8]

    Manish Bhatt, Sahana Chennabasappa, Cyrus Nikolaidis, Shengye Wan, Ivan Evti- mov, Dominik Gabi, Daniel Song, Faizan Ahmad, Cornelius Aschermann, Lorenzo Fontana, et al. 2023. Purple llama cyberseceval: A secure coding benchmark for language models.arXiv preprint arXiv:2312.04724(2023)

    arXiv 2023

Show all 71 references
  1. [9]

    Tom Brown, Benjamin Mann, Nick Ryder, Melanie Subbiah, Jared D Kaplan, Prafulla Dhariwal, Arvind Neelakantan, Pranav Shyam, Girish Sastry, Amanda Askell, et al. 2020. Language models are few-shot learners.Advances in neural information processing systems33 (2020), 1877–1901

    2020

  2. [10]

    Díaz Ferreyra

    Quang-Cuong Bui, Riccardo Scandariato, and Nicolás E. Díaz Ferreyra. 2022. Vul4J: A Dataset of Reproducible Java Vulnerabilities Geared Towards the Study of Program Repair Techniques. In2022 IEEE/ACM 19th International Conference on Mining Software Repositories (MSR). 464–468....

    2022

  3. [11]

    Mark Chen, Jerry Tworek, Heewoo Jun, Qiming Yuan, Henrique Ponde De Oliveira Pinto, Jared Kaplan, Harri Edwards, Yuri Burda, Nicholas Joseph, Greg Brockman, et al. 2021. Evaluating large language models trained on code. arXiv preprint arXiv:2107.03374(2021)

    2021 arXiv

  4. [12]

    Xinyun Chen, Maxwell Lin, Nathanael Schaerli, and Denny Zhou. 2023. Teach- ing Large Language Models to Self-Debug. InThe 61st Annual Meeting Of The Association For Computational Linguistics

    2023

  5. [13]

    Zimin Chen, Steve Kommrusch, and Martin Monperrus. 2022. Neural transfer learning for repairing security vulnerabilities in c code.IEEE Transactions on Software Engineering49, 1 (2022), 147–165

    2022

  6. [14]

    Domenico Cotroneo, Roberta De Luca, and Pietro Liguori. 2025. DeVAIC: A tool for security assessment of AI-generated code.Information and Software Technology177 (2025), 107572

    2025

  7. [15]

    Abhimanyu Dubey, Abhinav Jauhri, Abhinav Pandey, Abhishek Kadian, Ahmad Al-Dahle, Aiesha Letman, Akhil Mathur, Alan Schelten, Amy Yang, Angela Fan, et al. 2024. The llama 3 herd of models.arXiv preprint arXiv:2407.21783(2024)

    2024 arXiv

  8. [16]

    Daniel Fried, Armen Aghajanyan, Jessy Lin, Sida Wang, Eric Wallace, Freda Shi, Ruiqi Zhong, Wen-tau Yih, Luke Zettlemoyer, and Mike Lewis. 2022. Incoder: A generative model for code infilling and synthesis.arXiv preprint arXiv:2204.05999 (2022)

    2022 arXiv

  9. [17]

    Michael Fu, Chakkrit Tantithamthavorn, Trung Le, Van Nguyen, and Dinh Phung

  10. [18]

    Michael Fu, Chakkrit Kla Tantithamthavorn, Van Nguyen, and Trung Le. 2023. Chatgpt for vulnerability detection, classification, and repair: How far are we?. In 2023 30th Asia-Pacific Software Engineering Conference (APSEC). IEEE, 632–636

    2023

  11. [19]

    GitHub. [n. d.]. https://codeql.github.com/

  12. [20]

    GitHub. 2021. Copilot. https://github.blog/2021-06-29-introducing-github- copilot-ai-pair-programmer/

    2021

  13. [21]

    Jingxuan He, Mark Vero, Gabriela Krasnopolska, and Martin Vechev. 2024. In- struction tuning for secure code generation. InProceedings of the 41st International Conference on Machine Learning. 18043–18062

    2024

  14. [22]

    Dan Hendrycks, Steven Basart, Saurav Kadavath, Mantas Mazeika, Akul Arora, Ethan Guo, Collin Burns, Samir Puranik, Horace He, Dawn Song, and Jacob Steinhardt. 2021. Measuring Coding Challenge Competence With APPS.NeurIPS (2021)

    2021

  15. [23]

    Dong Huang, Jie M Zhang, Michael Luck, Qingwen Bu, Yuhao Qing, and Heming Cui. 2023. Agentcoder: Multi-agent-based code generation with iterative testing and optimisation.arXiv preprint arXiv:2312.13010(2023). Preprint, 2025, Yan et al

    2023 arXiv

  16. [24]

    Md Ashraful Islam, Mohammed Eunus Ali, and Md Rizwan Parvez. 2025. CODESIM: Multi-Agent Code Generation and Problem Solving through Simulation-Driven Planning and Debugging.arXiv preprint arXiv:2502.05664 (2025)

    2025 arXiv

  17. [25]

    Nafis Tanveer Islam, Mohammad Bahrami Karkevandi, and Peyman Najafirad

  18. [26]

    Raphaël Khoury, Anderson R Avila, Jacob Brunelle, and Baba Mamadou Camara

  19. [27]

    Geunwoo Kim, Pierre Baldi, and Stephen McAleer. 2023. Language models can solve computer tasks.Advances in Neural Information Processing Systems36 (2023), 39648–39677

    2023

  20. [28]

    Sophia D Kolak, Ruben Martins, Claire Le Goues, and Vincent Josua Hellendoorn

  21. [29]

    Junjie Li, Aseem Sangalay, Cheng Cheng, Yuan Tian, and Jinqiu Yang. 2024. Fine tuning large language model for secure code generation. InProceedings of the 2024 IEEE/ACM First International Conference on AI Foundation Models and Software Engineering. 86–90

    2024

  22. [30]

    Ziyang Li, Saikat Dutta, and Mayur Naik. 2025. IRIS: LLM-assisted static analysis for detecting security vulnerabilities. InThe Thirteenth International Conference on Learning Representations

    2025

  23. [31]

    Jiawei Liu, Chunqiu Steven Xia, Yuyao Wang, and Lingming Zhang. 2023. Is Your Code Generated by ChatGPT Really Correct? Rigorous Evaluation of Large Language Models for Code Generation. InThirty-seventh Conference on Neural Information Processing Systems. https://openreview.ne...

    2023

  24. [32]

    InDeep Learning for Code Workshop

    Patch generation with language models: Feasibility and scaling behavior. InDeep Learning for Code Workshop

  25. [33]

    Aman Madaan, Niket Tandon, Prakhar Gupta, Skyler Hallinan, Luyu Gao, Sarah Wiegreffe, Uri Alon, Nouha Dziri, Shrimai Prabhumoye, Yiming Yang, et al

  26. [34]

    Yu Nong, Mohammed Aldeen, Long Cheng, Hongxin Hu, Feng Chen, and Haipeng Cai. 2024. Chain-of-thought prompting of large language models for discovering and fixing software vulnerabilities.arXiv preprint arXiv:2402.17230(2024)

    2024 arXiv

  27. [35]

    Yu Nong, Haoran Yang, Long Cheng, Hongxin Hu, and Haipeng Cai. 2024. Au- tomated software vulnerability patching using large language models.arXiv preprint arXiv:2408.13597(2024)

    2024 arXiv

  28. [36]

    Anton Lozhkov, Raymond Li, Loubna Ben Allal, Federico Cassano, Joel Lamy- Poirier, Nouamane Tazi, Ao Tang, Dmytro Pykhtar, Jiawei Liu, Yuxiang Wei, et al. 2024. Starcoder 2 and the stack v2: The next generation.arXiv preprint arXiv:2402.19173(2024)

    2024 arXiv

  29. [37]

    OpenAI. 2023. ChatGPT. https://openai.com

    2023

  30. [38]

    Self-refine: Iterative refinement with self-feedback.Advances in Neural Information Processing Systems36 (2024)

    2024

  31. [39]

    Hammond Pearce, Benjamin Tan, Baleegh Ahmad, Ramesh Karri, and Brendan Dolan-Gavitt. 2023. Examining zero-shot vulnerability repair with large language models. In2023 IEEE Symposium on Security and Privacy (SP). IEEE, 2339–2356

    2023

  32. [40]

    Xutan Peng, Yipeng Zhang, Jingfeng Yang, and Mark Stevenson. 2022. On the security vulnerabilities of text-to-sql models.arXiv preprint arXiv:2211.15363 (2022)

    2022 arXiv

  33. [41]

    OpenAI. [n. d.]. https://openai.com/index/chatgpt

  34. [42]

    Julian Aron Prenner, Hlib Babii, and Romain Robbes. 2022. Can OpenAI’s codex fix bugs? an evaluation on QuixBugs. InProceedings of the Third International Workshop on Automated Program Repair. 69–75

    2022

  35. [43]

    Hammond Pearce, Baleegh Ahmad, Benjamin Tan, Brendan Dolan-Gavitt, and Ramesh Karri. 2022. Asleep at the keyboard? assessing the security of github copilot’s code contributions. In2022 IEEE Symposium on Security and Privacy (SP). IEEE, 754–768

    2022

  36. [44]

    Qibing Ren, Chang Gao, Jing Shao, Junchi Yan, Xin Tan, Wai Lam, and Lizhuang Ma. 2024. Codeattack: Revealing safety generalization challenges of large lan- guage models via code completion. InFindings of the Association for Computa- tional Linguistics ACL 2024. 11437–11452

    2024

  37. [45]

    Baptiste Roziere, Jonas Gehring, Fabian Gloeckle, Sten Sootla, Itai Gat, Xiao- qing Ellen Tan, Yossi Adi, Jingyu Liu, Romain Sauvestre, Tal Remez, et al. 2023. Code llama: Open foundation models for code.arXiv preprint arXiv:2308.12950 (2023)

    2023 arXiv

  38. [46]

    Neil Perry, Megha Srivastava, Deepak Kumar, and Dan Boneh. 2023. Do users write more insecure code with AI assistants?. InProceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security. 2785–2799

    2023

  39. [47]

    Mohammed Latif Siddiq and Joanna CS Santos. 2022. SecurityEval dataset: mining vulnerability examples to evaluate machine learning-based code generation techniques. InProceedings of the 1st International Workshop on Mining Software Repositories Applications for Privacy and Sec...

    2022

  40. [48]

    Alec Radford, Jeffrey Wu, Rewon Child, David Luan, Dario Amodei, Ilya Sutskever, et al. 2019. Language models are unsupervised multitask learners.OpenAI blog 1, 8 (2019), 9

    2019

  41. [49]

    André Silva, Sen Fang, and Martin Monperrus. 2023. Repairllama: Efficient representations and fine-tuned adapters for program repair.arXiv preprint arXiv:2312.15698(2023)

    2023 arXiv

  42. [50]

    Catherine Tony, Nicolás E Díaz Ferreyra, Markus Mutas, Salem Dhiff, and Ric- cardo Scandariato. 2024. Prompting techniques for secure code generation: A systematic investigation.arXiv preprint arXiv:2407.07064(2024)

    2024 arXiv

  43. [51]

    Bernhard Scholz, Herbert Jordan, Pavle Subotić, and Till Westmann. 2016. On fast large-scale program analysis in datalog. InProceedings of the 25th International Conference on Compiler Construction. 196–206

    2016

  44. [52]

    Shengye Wan, Cyrus Nikolaidis, Daniel Song, David Molnar, James Crnkovich, Jayson Grace, Manish Bhatt, Sahana Chennabasappa, Spencer Whitman, Stephanie Ding, et al . 2024. Cyberseceval 3: Advancing the evaluation of cy- bersecurity risks and capabilities in large language mode...

    2024 arXiv

  45. [53]

    Mohammed Latif Siddiq and Joanna C. S. Santos. 2022. SecurityEval Dataset: Mining Vulnerability Examples to Evaluate Machine Learning-Based Code Gen- eration Techniques. InProceedings of the 1st International Workshop on Min- ing Software Repositories Applications for Privacy ...

    2022

  46. [54]

    Xingyao Wang, Zihan Wang, Jiateng Liu, Yangyi Chen, Lifan Yuan, Hao Peng, and Heng Ji. 2024. MINT: EVALUATING LLMS IN MULTI-TURN INTERACTION WITH TOOLS AND LANGUAGE FEEDBACK. In12th International Conference on Learning Representations, ICLR 2024

    2024

  47. [55]

    Jason Wei, Xuezhi Wang, Dale Schuurmans, Maarten Bosma, Fei Xia, Ed Chi, Quoc V Le, Denny Zhou, et al. 2022. Chain-of-thought prompting elicits reasoning in large language models.Advances in neural information processing systems35 (2022), 24824–24837

    2022

  48. [56]

    Manya Wadhwa, Xinyu Zhao, Junyi Jessy Li, and Greg Durrett. 2024. Learn- ing to Refine with Fine-Grained Natural Language Feedback. InFindings of the Association for Computational Linguistics: EMNLP 2024. 12281–12308

    2024

  49. [57]

    Chunqiu Steven Xia, Yuxiang Wei, and Lingming Zhang. 2023. Automated program repair in the era of large pre-trained language models. In2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE). IEEE, 1482–1494

    2023

  50. [58]

    Jiexin Wang, Xitong Luo, Liuwen Cao, Hongkui He, Hailin Huang, Jiayuan Xie, Adam Jatowt, and Yi Cai. 2024. Is Your AI-Generated Code Really Safe? Evaluating Large Language Models on Secure Code Generation with CodeSecEval.arXiv preprint arXiv:2407.02395(2024)

    2024 arXiv

  51. [59]

    Ziyi Yang, Fanqi Wan, Longguang Zhong, Tianyuan Shi, and Xiaojun Quan

  52. [60]

    Xin Yin, Chao Ni, Shaohua Wang, Zhenhao Li, Limin Zeng, and Xiaohu Yang

  53. [61]

    Yi Wu, Nan Jiang, Hung Viet Pham, Thibaud Lutellier, Jordan Davis, Lin Tan, Petr Babkin, and Sameena Shah. 2023. How effective are neural networks for fixing security vulnerabilities. InProceedings of the 32nd ACM SIGSOFT International Symposium on Software Testing and Analysi...

    2023

  54. [62]

    Lianmin Zheng, Wei-Lin Chiang, Ying Sheng, Siyuan Zhuang, Zhanghao Wu, Yonghao Zhuang, Zi Lin, Zhuohan Li, Dacheng Li, Eric Xing, et al. 2023. Judging llm-as-a-judge with mt-bench and chatbot arena.Advances in Neural Information Processing Systems36 (2023), 46595–46623

    2023

  55. [63]

    Yu Yang, Yuzhou Nie, Zhun Wang, Yuheng Tang, Wenbo Guo, Bo Li, and Dawn Song. 2024. SecCodePLT: A Unified Platform for Evaluating the Security of Code GenAI. arXiv:2410.11096 [cs.CR] https://arxiv.org/abs/2410.11096

    2024

  56. [64]

    Qihao Zhu, Daya Guo, Zhihong Shao, Dejian Yang, Peiyi Wang, Runxin Xu, Y Wu, Yukun Li, Huazuo Gao, Shirong Ma, et al . 2024. DeepSeek-Coder-V2: Breaking the Barrier of Closed-Source Models in Code Intelligence.arXiv preprint arXiv:2406.11931(2024)

    2024 arXiv

  57. [67]

    InProceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis

    Thinkrepair: Self-directed automated program repair. InProceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis. 1274–1286

  58. [68]

    Boyu Zhang, Tianyu Du, Junkai Tong, Xuhong Zhang, Kingsum Chow, Sheng Cheng, Xun Wang, and Jianwei Yin. 2024. SecCoder: Towards Generalizable and Robust Secure Code Generation. InProceedings of the 2024 Conference on Empirical Methods in Natural Language Processing. 14557–14571

    2024

  59. [70]

    Yaqin Zhou, Shangqing Liu, Jingkai Siow, Xiaoning Du, and Yang Liu. 2019. Devign: Effective vulnerability identification by learning comprehensive program semantics via graph neural networks.Advances in neural information processing systems32 (2019)

    2019

  60. [2022]

    InPro- ceedings of the 30th ACM joint european software engineering conference and symposium on the foundations of software engineering

    VulRepair: a T5-based automated software vulnerability repair. InPro- ceedings of the 30th ACM joint european software engineering conference and symposium on the foundations of software engineering. 935–947

  61. [2023]

    In2023 IEEE International Conference on Systems, Man, and Cybernetics (SMC)

    How secure is code generated by chatgpt?. In2023 IEEE International Conference on Systems, Man, and Cybernetics (SMC). IEEE, 2445–2451

  62. [2024]

    Code security vulnerability repair using reinforcement learning with large language models.arXiv preprint arXiv:2401.07031(2024)

    2024 arXiv

  63. [2025]

    InThe Thirteenth International Conference on Learning Representations

    Weighted-Reward Preference Optimization for Implicit Model Fusion. InThe Thirteenth International Conference on Learning Representations. https: //openreview.net/forum?id=fq24pEb8SL

Pith tools

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