Pith. sign in

REVIEW 4 major objections 5 minor 1 cited by

SoK: Towards Effective Automated Vulnerability Repair

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

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

Pith's one-line read No single automated repair method wins everywhere: learning-based tools shine on synthetic benchmarks but lag on real-world vulnerabilities, while non-learning tools lead there but struggle with complexity.

desk verdict Useful SoK with a real cross-method benchmark, but the headline claim that learning lags behind is only as strong as a C/C++-heavy, Java-filtered dataset scored at pass@3. read the letter →

arxiv 2501.18820 v1 pith:7UZEAJSU submitted 2025-01-31 cs.CR

Ying Li , Faysal hossain shezan , Bomin wei , Gang Wang , Yuan Tian This is my paper · ORCID
classification cs.CR
keywords automatedvulnerabilityrepairsecuritypatchgenerationlargelanguagemodelsprogrambenchmarkevaluationconstraint-basedlearning-basedCWE
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 organizes the field of automated vulnerability repair (AVR) into four families—template-guided, search-based, constraint-based, and learning-driven—and benchmarks representative tools from each across synthetic and real-world C/C++ and Java datasets. Its central conclusion is that no single approach is best: the choice that works depends heavily on the benchmark, with GPT-4 reaching 96.6% repair success on the synthetic SARD set but dropping below 50% on real-world datasets, where constraint-based ExtractFix and search/constraint VulnFix do relatively better. The paper also argues that learning-based methods lack whole-program understanding and fail on vulnerabilities with inter-procedural dependencies or implicit specification constraints, while non-learning methods struggle with precise constraint extraction. A sympathetic reader would take away that AVR results are strongly benchmark-dependent and that synthetic evaluations can flatter learning-based methods.

What carries the argument

The load-bearing apparatus is the repair success rate (RSR), defined as the number of vulnerabilities successfully repaired divided by the total to repair, applied through a benchmark protocol that spans synthetic SARD C/C++ and real-world C/C++ (ExtractFix, VulnLoc) and Java (Vul4J, VJBench) vulnerabilities. RSR is computed with a three-stage check—successful compilation, oracle/test pass, and manual semantic review—so failures can be attributed to a stage. The four-category taxonomy (template-guided, search-based, constraint-based, learning-driven) organizes the comparison and explains why tools fail: templates and mutation need clear patterns, constraints need precise extraction, and learning needs program understanding.

What would settle it

Run the same ten tools on the unfiltered VJBench (all 42) and Vul4J (all 79) cases, including the 28 multi-file Java vulnerabilities the paper excluded, and compare repair success rates; if GPT-4 or the fine-tuned models repair a substantial share of those, the claim that learning-based methods lag traditional approaches overall would not generalize.

Watch

Extended reading notes

Core claim

On the paper's own terms, the discovery is a negative result stated as a landscape finding: after surveying 79 papers and running ten repair tools on four benchmarks, no consistently dominant AVR approach exists. The numbers that carry the claim are repair success rates: GPT-4-1106-preview scores 96.6% on 1,000 sampled SARD C/C++ cases, but only 46.67% on the 30-case ExtractFix set, 34.88% on the 43-case VulnLoc set, 37.14% on the filtered 70-case Vul4J Java set, and 21.74% on VJBench. Non-learning tools such as ExtractFix (70.00% on its own benchmark) and VulnFix (43.33% on ExtractFix, 46.51% on VulnLoc) do better on real-world sets but still fail on complex logic, multi-file changes, and constraints hidden in specifications. The paper attributes the gap to a structural difference: learning-based methods produce compilable code often but miss program-wide dependencies and implicit security properties, while non-learning methods compute constraints or invariants from program context. Its Finding IV states the overall result plainly: learning-based AVR methods lag traditional approaches on these benchmarks, even though they excel on specific CWE categories.

Load-bearing premise

The empirical conclusions depend on the curated benchmark suite being representative of AVR's real difficulty distribution; the filters that removed multi-file Java vulnerabilities and several tool categories could make 'learning-based lag traditional' an artifact of test selection.

Editorial extensions

If this is right

  • Results from synthetic datasets such as SARD should not be treated as predictions of real-world repair performance; the paper's own numbers show a 96.6% RSR on synthetic C/C++ collapsing to below 50% on real-world C/C++ and Java sets.
  • A benchmark's composition—CWE mix, presence of inter-procedural dependencies, and availability of exploits/test oracles—determines which repair method looks best, so AVR comparisons are only meaningful relative to a described benchmark.
  • Inter-procedural code dependencies are a more informative difficulty signal than single-hunk versus multi-hunk change size, which the paper finds does not reliably predict repair success.
  • Combining learning-based patch generation with program analysis, constraint extraction, or external verifier feedback is a concrete direction the paper identifies for improving both families of methods.
  • Security patch validation remains a bottleneck that currently requires human expertise, especially for selecting among multiple generated patches from non-deterministic LLMs.

Reading between the lines

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

  • Editorial inference: if the benchmark-dependence result generalizes, practical adoption should match tool to vulnerability profile—constraint-based tools for memory-safety CVEs with a single exploit, LLM-based tools for well-represented CWE patterns—rather than picking one tool by average score.
  • Editorial inference: the paper's filtering decisions (dropping multi-file Java vulnerabilities and tools targeting backporting, Solidity, or NPDs) may have removed exactly the cases where LLMs' strengths or weaknesses are most visible; re-running on unfiltered sets could sharpen or reverse Finding IV.
  • Editorial inference: the authors' use of three sampled outputs per non-deterministic model and counting any correct one privileges LLMs relative to deterministic tools; a pass@1 comparison might show an even larger real-world gap.
  • Editorial inference: a natural extension would be a benchmark 'fingerprint'—reporting CWE distribution, dependency profile, and exploit availability alongside RSR—so future AVR papers can be compared meaningfully across different datasets.
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 / 5 minor

Summary. This SoK paper surveys automated vulnerability repair (AVR), proposes a four-category taxonomy (template-guided, search-based, constraint-based, learning-driven) with sub-strategies and methodologies, and reports a quantitative benchmark evaluation of ten AVR tools on synthetic (SARD) and real-world C/C++ and Java datasets. The main empirical findings are that no single method dominates, that learning-based methods perform very well on synthetic data but drop sharply on real-world benchmarks, and that non-learning methods are generally more effective on the real-world C/C++ cases considered. The paper also analyzes repair difficulty factors (scope of change and code dependencies), presents case studies, and offers future research directions.

Significance. If the empirical findings hold, this is one of the few SoKs that combine a taxonomy with direct, reproducible tool evaluation, and it would be a useful reference for researchers choosing between learning-based and non-learning AVR approaches. The three-step validation with manual review (96.5% agreement, kappa 91.5%) is a genuine strength, as is the explicit reporting of artifact availability and exclusion criteria. The paper also makes a useful conceptual contribution by distinguishing security patch generation from general program repair and by highlighting the role of code dependencies rather than hunk counts in repair difficulty. However, the central 'no single best approach' conclusion is more robust than the sharper Finding IV ('learning lags behind overall'), which depends on a filtered benchmark composition and an asymmetric evaluation protocol.

major comments (4)
  1. [Section 5.1 / Section 5.2, Finding IV] The 'overall' ranking in Finding IV is not supported by the evaluated benchmark structure. The Java benchmarks were explicitly filtered to remove multi-file vulnerabilities (footnote 1, retaining 23/42 VJBench and 70/79 Vul4J), and no non-learning Java tool was evaluated on the same filtered set (Appendix B excludes Nopol and NPEFix because the Java benchmark lacks NPDs). Consequently, the comparison between learning and non-learning methods is effectively a C/C++-only comparison, and it uses two datasets (ExtractFix and VulnLoc) designed for and dominated by non-learning memory-safety repair tools. To support an 'overall' claim, the authors should either evaluate non-learning Java tools on the filtered Java set, or explicitly restrict Finding IV to the C/C++ benchmarks and discuss how the CWE distribution affects generalizability.
  2. [Section 5.1, Evaluation Metrics (Eq. 1 and following note)] The evaluation gives non-deterministic LLMs a pass@3 advantage while deterministic tools are run once. This asymmetry favors learning-based methods, so it does not undermine the direction of Finding IV; however, it makes the reported RSR values non-comparable across method families and prevents any quantitative 'overall' ranking. The authors should report per-run success rates for the LLMs (or, equivalently, compute best-of-3 for the deterministic tools) and label the current numbers as pass@3 in Tables 2 and 3.
  3. [Section 5.2, Finding I] Finding I states that 'the robustness of learning-driven method in our evaluation is excellent,' but the data in Tables 2 and 3 show GPT-4 dropping from 96.6% on SARD to between 10% and 47% on real-world benchmarks, and VRPilot remaining below non-learning tools on both C/C++ sets. The mutation experiments (D_SARD with 200 samples) only measure robustness to syntactic perturbations of synthetic code, not robustness across real-world vulnerability distributions. This finding should be reworded to match the evidence, e.g., 'learning-driven methods are robust on synthetic SARD-style inputs' rather than claiming excellent robustness generally.
  4. [Section 5.2, Figure 3 and Open RQ III] The CWE-level analysis in Figure 3 is used to support Finding IV, but most CWE categories contain only one or two data points, and the paper itself notes in Open RQ III that 'limited data makes strong conclusions unreliable.' The categorical statements in Findings III and IV go beyond what this sample size supports. The authors should either add confidence intervals or statistical tests on CWE-level RSRs, or soften the findings to explicitly acknowledge that the observed gaps may be an artifact of benchmark composition.
minor comments (5)
  1. [Throughout] There are numerous typos and grammatical errors, e.g., 'norrowing' instead of 'narrowing' in Section 4.2, 'employsthree' in the same section, 'vulerable' in Section 2.4, and 'techniniques' in Section 6. A careful proofreading pass is needed.
  2. [Section 5.2 / Table 4] Table 4 is introduced as 'Successful repairs by Scope of Change and Code Dependencies' but the columns mix counts and rates; the header rows should be clarified, and the text should state whether the denominators (25 and 23) are the number of applicable cases for each tool or global totals.
  3. [Appendix B / Table 6] The artifact-status table is useful, but the symbols in the 'Accessible', 'Instruction', and 'Executable' columns are inconsistently explained: the legend defines check/cross symbols but some rows use a slash, which is not defined in the table notes.
  4. [Section 2.3, Definition 3] The definition of SPV says a patch is deemed effective if it satisfies three criteria, but the paper later acknowledges (Section 6, D6) that most validation still requires human effort; the definition should make clear that the criteria are ideal conditions, not an operational procedure.
  5. [Section 4.4, subsection labels] The prompt-engineering subsection labels its subparts as B1, B2, B3 after using A and B for previous subsections; this creates confusion (there are two 'B1's in Section 4.4). Renumber the prompt-engineering items as C1, C2, C3.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the SoK's taxonomy and empirical findings are grounded in external tools, external benchmarks, and measured RSR values, not in fitted parameters or self-citations.

full rationale

The paper's central claims—'no single best approach' and Finding IV ('Learning-based AVR methods lag behind traditional approaches overall')—are empirical conclusions drawn from running externally developed tools (Senx, VulnFix, ExtractFix, VRPilot, GPT-4, Gemini, CodeT5, InCoder, etc.) on externally provided benchmarks (SARD, VJBench, Vul4J, ExtractFix, VulnLoc). The taxonomy in Section 3 is a classification scheme imposed by the authors, but it does not mathematically determine any RSR value or any relative ranking. No parameter is fitted to a subset of data and then renamed as a prediction; the RSR metric is defined transparently, and the pass@3 counting for non-deterministic LLMs is disclosed, not disguised. The paper contains no load-bearing self-citations: the evaluated artifacts and datasets come from other research groups, and no 'uniqueness theorem' or prior author-derived ansatz is invoked to force a conclusion. The benchmark filtering choices (e.g., retaining 23/42 VJBench and 70/79 Vul4J cases, excluding backporting/Solidity/NPD-focused tools) are validity limitations that reduce the generality of 'overall' comparisons, but they do not make the observed outcomes true by construction. The paper itself repeatedly cautions that small sample sizes make strong conclusions unreliable, which further indicates that the findings are presented as empirical observations rather than as artifacts of definitional circularity. Therefore, no circular step meeting the required evidentiary standard is present.

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

This SoK introduces no new free parameters or invented entities; the only 'costs' are the representativeness assumptions above. The benchmark has no fitted constants; it reports measured RSR values. The main assumptions are about dataset representativeness, oracle validity, literature coverage, and model stability.

assumptions (5)
  • domain assumption The selected benchmark datasets (SARD sample, VJBench/Vul4J, ExtractFix/VulnLoc) are representative of the AVR problem space and difficulty distribution.
    Section 5.1 states the selection criteria (prevalence, language diversity, mix of synthetic and real-world, availability of exploits), but this representativeness is assumed, not formally demonstrated, and the filtering of multi-file Java vulnerabilities narrows the sample.
  • domain assumption Repair success rate (RSR), computed via compilation, oracle tests/exploits, and manual review, is a valid measure of whether a security patch is correct.
    Section 5.1 defines RSR and the three-step validation. The validity depends on the completeness of test/exploit oracles and the accuracy of the 200-patch manual review (96.5% agreement), which are assumed rather than proven.
  • domain assumption The 79-paper corpus collected through keyword search, filtering, manual review, and snowballing is representative of the AVR literature, and the authors' taxonomy assignments are correct.
    Section 3 describes the selection methodology (4,883 initial, 267 after filtering, 79 final), but the categorization of each paper into template-guided, search-based, constraint-based, or learning-driven is a human judgment that could differ across reviewers.
  • domain assumption GPT-4-1106-preview and Gemini-Pro results generalize to other LLMs and remain stable across model updates.
    Section 5.1 uses these specific models and best-of-3 sampling; the paper notes non-determinism but does not address version drift, and the authors substituted GPT-4 for VRPilot instead of the original GPT-3.5-turbo.
  • domain assumption Tools excluded from the benchmark (backporting, Solidity-specific, NPD-only) would not change the headline finding of no single best approach.
    Appendix B lists exclusions; the paper assumes these exclusions do not bias the comparison, but this is not empirically tested.

how reviews work

0 comments
Cite this review

Pith. "Pith review of SoK: Towards Effective Automated Vulnerability Repair." pith.science (2026). https://pith.science/paper/7UZEAJSU

@misc{pith2026250118820,
  author       = {Pith},
  title        = {Pith review of: SoK: Towards Effective Automated Vulnerability Repair},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/7UZEAJSU}},
  note         = {Machine review of arXiv:2501.18820}
}
read the original abstract

The increasing prevalence of software vulnerabilities necessitates automated vulnerability repair (AVR) techniques. This Systematization of Knowledge (SoK) provides a comprehensive overview of the AVR landscape, encompassing both synthetic and real-world vulnerabilities. Through a systematic literature review and quantitative benchmarking across diverse datasets, methods, and strategies, we establish a taxonomy of existing AVR methodologies, categorizing them into template-guided, search-based, constraint-based, and learning-driven approaches. We evaluate the strengths and limitations of these approaches, highlighting common challenges and practical implications. Our comprehensive analysis of existing AVR methods reveals a diverse landscape with no single ``best'' approach. Learning-based methods excel in specific scenarios but lack complete program understanding, and both learning and non-learning methods face challenges with complex vulnerabilities. Additionally, we identify emerging trends and propose future research directions to advance the field of AVR. This SoK serves as a valuable resource for researchers and practitioners, offering a structured understanding of the current state-of-the-art and guiding future research and development in this critical domain.

Figures

Figures reproduced from arXiv: 2501.18820 by the authors.

Figure 1
Figure 1. The timeline of vulnerability discovery, patch release, [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Taxonomy of Automated Vulnerability Repair approaches. Boxes with blue background present the taxonomy of security patch generation methods. Boxes with green background show the taxonomy of security patch validation approaches. ployed a systematic approach to analyze each paper, exam￾ining three key dimensions: (1) The core components and methodologies used in AVR; (2) The effectiveness and target vulnerabilities ty… view at source ↗
Figure 3
Figure 3. Total vs. (Non-)Learning-Based Repair Counts [PITH_FULL_IMAGE:figures/full_fig_p013_3.png] view at source ↗
Figures from the paper (1 more)
Figure 4
Figure 4. Figure 4: Inter-procedural processing for D𝑆𝐴𝑅𝐷 B Security Patch Generation Artifacts. As shown in [PITH_FULL_IMAGE:figures/full_fig_p023_4.png]

Discussion (0). Continue with ORCID 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. SoK: Automated Vulnerability Repair: Methods, Tools, and Assessments

    cs.SE 2025-06 conditional novelty 5.0 of 10

    Vul4C, a 144-vulnerability C/C++ repair benchmark with exploits and patches, is introduced and used to compare seven C/C++ and two Java automated vulnerability repair tools.

Reference graph

Works this paper leans on

224 extracted references · 63 canonical work pages · cited by 1 Pith paper

  1. [1]

    Zero-day vulnera- bilities: 17 consequences and complications

    Forbes Technology Council. Zero-day vulnera- bilities: 17 consequences and complications. https://www.forbes.com/sites/forbestechcou ncil/2023/05/26/zero-day-vulnerabilities-17-c onsequences-and-complications. Accessed on: Jan, 2024

    2023

  2. [2]

    Evaluating complexity, code churn, and developer activitymetricsasindicatorsofsoftwarevulnerabilities

    YongheeShin,AndrewMeneely,LaurieWilliams,andJasonA Osborne. Evaluating complexity, code churn, and developer activitymetricsasindicatorsofsoftwarevulnerabilities. IEEE TSE, 2010

    2010

  3. [3]

    A large-scale empirical study of security patches

    Frank Li and Vern Paxson. A large-scale empirical study of security patches. InProc. ACM CCS, 2017

    2017

  4. [4]

    A novel approach for software vulnerability classifi- cation

    Xiaodan Li, Xiaolin Chang, John A Board, and Kishor S Trivedi. A novel approach for software vulnerability classifi- cation. InProc. IEEE RAMS, 2017

    2017

  5. [5]

    Vulnerability remediation timelines: 7 best practices

    Makenzie Buenning. Vulnerability remediation timelines: 7 best practices. https://www.ninjaone.com/blog/vu lnerability-remediation-timelines-best-pract ices/, 2024. Accessed on: Mar, 2024

    2024

  6. [6]

    Autopag:towardsautomatedsoftwarepatchgeneration with source code root cause identification and repair

    Zhiqiang Lin, Xuxian Jiang, Dongyan Xu, Bing Mao, and LiXie. Autopag:towardsautomatedsoftwarepatchgeneration with source code root cause identification and repair. InProc. ACM CCS, 2007

    2007

  7. [7]

    Exter- minator: automatically correcting memory errors with high probability

    Gene Novark, Emery D Berger, and Benjamin G Zorn. Exter- minator: automatically correcting memory errors with high probability. InProc. ACM PLDI, 2007

    2007

  8. [8]

    Program transformations to fix c integers

    Zack Coker and Munawar Hafiz. Program transformations to fix c integers. InProc. ACM/IEEE ICSE, 2013

    2013

Show all 224 references
  1. [9]

    XiangGao,BoWang,GregoryJDuck,RuyiJi,YingfeiXiong, andAbhikRoychoudhury.Beyondtests:Programvulnerability repair via crash constraint extraction.ACM TOSEM, 2021

    2021

  2. [10]

    Program vulnerability repair via inductive inference

    Yuntong Zhang, Xiang Gao, Gregory J Duck, and Abhik Roychoudhury. Program vulnerability repair via inductive inference. InProc. ACM ISSTA, 2022

    2022

  3. [11]

    Generative adversarial networks.Communi- cations of the ACM, 2020

    Ian Goodfellow, Jean Pouget-Abadie, Mehdi Mirza, Bing Xu, David Warde-Farley, Sherjil Ozair, Aaron Courville, and Yoshua Bengio. Generative adversarial networks.Communi- cations of the ACM, 2020

    2020

  4. [12]

    Seqtrans:automaticvulnerabilityfixviasequencetosequence learning

    Jianlei Chi, Yu Qu, Ting Liu, Qinghua Zheng, and Heng Yin. Seqtrans:automaticvulnerabilityfixviasequencetosequence learning. IEEE TSE, 2022

    2022

  5. [13]

    Neu- ral transfer learning for repairing security vulnerabilities in c code

    Zimin Chen,Steve Kommrusch,andMartin Monperrus. Neu- ral transfer learning for repairing security vulnerabilities in c code. IEEE TSE, 2022

    2022

  6. [14]

    Howeffective areneuralnetworksforfixingsecurityvulnerabilities

    YiWu,NanJiang,HungVietPham,ThibaudLutellier,Jordan Davis,LinTan,PetrBabkin,andSameenaShah. Howeffective areneuralnetworksforfixingsecurityvulnerabilities. In Proc. ACM ISSTA, 2023

    2023

  7. [15]

    Examining zero-shot vul- nerability repair with large language models

    Hammond Pearce, Benjamin Tan, Baleegh Ahmad, Ramesh Karri, and Brendan Dolan-Gavitt. Examining zero-shot vul- nerability repair with large language models. InProc. IEEE S&P, 2023

    2023

  8. [16]

    Chatgpt for vulnerability detection, classification, and repair: How far are we? InIEEE APSEC, 2023

    MichaelFu,ChakkritKlaTantithamthavorn,VanNguyen,and Trung Le. Chatgpt for vulnerability detection, classification, and repair: How far are we? InIEEE APSEC, 2023

    2023

  9. [17]

    Automaticsoftwarerepair:Abibliography

    MartinMonperrus. Automaticsoftwarerepair:Abibliography. ACM Computing Surveys (CSUR), 2018

    2018

  10. [18]

    Au- tomatic software repair: A survey

    Luca Gazzola, Daniela Micucci, and Leonardo Mariani. Au- tomatic software repair: A survey. InProc. ACM/IEEE ICSE, 2018

    2018

  11. [19]

    PhD thesis, HAL Archives Ouvertes, 2018

    Martin Monperrus.The living review on automated program repair. PhD thesis, HAL Archives Ouvertes, 2018

    2018

  12. [20]

    A compara- tive study ofautomatic program repairtechniques forsecurity vulnerabilities

    Eduard Pinconschi, Rui Abreu, and Pedro Adão. A compara- tive study ofautomatic program repairtechniques forsecurity vulnerabilities. InProc. IEEE ISSRE, 2021

    2021

  13. [21]

    Let’s talk with developers, not about developers: A review of automatic program repair research.IEEE TSE, 2022

    Emily Winter, Vesna Nowack, David Bowes, Steve Coun- sell, Tracy Hall, Sæmundur Haraldsson, and John Woodward. Let’s talk with developers, not about developers: A review of automatic program repair research.IEEE TSE, 2022

    2022

  14. [22]

    A survey on automated program repair techniques.arXiv:2303.18184, 2023

    Kai Huang, Zhengzi Xu, Su Yang, Hongyu Sun, Xuejun Li, Zheng Yan, and Yuqing Zhang. A survey on automated program repair techniques.arXiv:2303.18184, 2023

    2023 arXiv

  15. [23]

    A survey of learning-based automated program repair.ACM TOSEM, 2023

    Quanjun Zhang, Chunrong Fang, Yuxiang Ma, Weisong Sun, and Zhenyu Chen. A survey of learning-based automated program repair.ACM TOSEM, 2023

    2023

  16. [24]

    Largelan- guage model for vulnerability detection and repair: Literature review and roadmap.arXiv:2404.02525, 2024

    XinZhou,SicongCao,XiaobingSun,andDavidLo. Largelan- guage model for vulnerability detection and repair: Literature review and roadmap.arXiv:2404.02525, 2024

    2024 arXiv

  17. [25]

    What if is not enough? fixing null pointer dereference with contextual check

    Yunlong Xing, Shu Wang, Shiyu Sun, Xu He, Kun Sun, and Qi Li. What if is not enough? fixing null pointer dereference with contextual check. InUSENIX Security, 2024

    2024

  18. [26]

    Tap- fixer: Automatic detection and repair of home automation vulnerabilities based on negated-property reasoning

    Yinbo Yu, Yuanqi Xu, Kepu Huang, and Jiajia Liu. Tap- fixer: Automatic detection and repair of home automation vulnerabilities based on negated-property reasoning. InProc. USENIX Security, 2024

    2024

  19. [27]

    Localizing vulnerabilities statistically from one exploit

    ShiqiShen,AashishKolluri,ZhenDong,PrateekSaxena,and Abhik Roychoudhury. Localizing vulnerabilities statistically from one exploit. InProc. ACM ASIACCS, 2021

    2021

  20. [28]

    Vulchecker: Graph-based vulnerability lo- calization in source code

    Yisroel Mirsky, George Macon, Michael Brown, Carter Yage- mann, Matthew Pruett, Evan Downing, Sukarno Mertoguno, and Wenke Lee. Vulchecker: Graph-based vulnerability lo- calization in source code. InProc. USENIX Security, 2023

    2023

  21. [29]

    Dynamic program slicing

    Hiralal Agrawal and Joseph R Horgan. Dynamic program slicing. ACM SIGPlan Notices, 1990. 15

    1990

  22. [30]

    Icspatch: Automated vulnerability lo- calization and non-intrusive hotpatching in industrial control systems using data dependence graphs

    Prashant Hari Narayan Rajput, Constantine Doumanidis, and Michail Maniatakos. Icspatch: Automated vulnerability lo- calization and non-intrusive hotpatching in industrial control systems using data dependence graphs. InProc. USENIX Secur. Symp, 2023

    2023

  23. [31]

    Simplifying and isolat- ing failure-inducing input.IEEE TSE, 2002

    Andreas Zeller and Ralf Hildebrandt. Simplifying and isolat- ing failure-inducing input.IEEE TSE, 2002

    2002

  24. [32]

    Racing on the negative force: Efficient vulnerability root-cause analysis through reinforce- ment learning on counterexamples

    Dandan Xu, Di Tang, Yi Chen, XiaoFeng Wang, Kai Chen, Haixu Tang, and Longxing Li. Racing on the negative force: Efficient vulnerability root-cause analysis through reinforce- ment learning on counterexamples. InUSENIX Security, 2024

    2024

  25. [33]

    An empirical study of auto- mated vulnerability localization with large language models

    Jian Zhang, Chong Wang, Anran Li, Weisong Sun, Cen Zhang, Wei Ma, and Yang Liu. An empirical study of auto- mated vulnerability localization with large language models. arXiv:2404.00287, 2024

    2024

  26. [34]

    Graphspd: Graph-based security patch detection with enriched code semantics

    Shu Wang, Xinda Wang, Kun Sun, Sushil Jajodia, Haining Wang, and Qi Li. Graphspd: Graph-based security patch detection with enriched code semantics. InProc. IEEE S&P, 2023

    2023

  27. [35]

    Directed greybox fuzzing

    Marcel Böhme, Van-Thuan Pham, Manh-Dung Nguyen, and Abhik Roychoudhury. Directed greybox fuzzing. InProc. ACM CCS, 2017

    2017

  28. [36]

    Evocatio:Conjuringbugcapabilitiesfrom a single poc

    Zhiyuan Jiang, Shuitao Gan, Adrian Herrera, Flavio Toffalini, Lucio Romerio, Chaojing Tang, Manuel Egele, Chao Zhang, andMathiasPayer. Evocatio:Conjuringbugcapabilitiesfrom a single poc. InProc. ACM CCS, 2022

    2022

  29. [37]

    Fast and precise on-the-fly patch validation for all

    Lingchao Chen, Yicheng Ouyang, and Lingming Zhang. Fast and precise on-the-fly patch validation for all. InIEEE/ACM ICSE, 2021

    2021

  30. [38]

    Au- tomatic software repair: A survey.IEEE TSE, 2017

    Luca Gazzola, Daniela Micucci, and Leonardo Mariani. Au- tomatic software repair: A survey.IEEE TSE, 2017

    2017

  31. [39]

    Leveragingsyntax-relatedcodefor automated program repair

    QiXinandStevenPReiss. Leveragingsyntax-relatedcodefor automated program repair. InProc. IEEE/ACM ASE, 2017

    2017

  32. [40]

    S3: syntax-and semantic-guided repair synthesis via programming by examples

    Xuan-Bach D Le, Duc-Hiep Chu, David Lo, Claire Le Goues, and Willem Visser. S3: syntax-and semantic-guided repair synthesis via programming by examples. InProc. ACM ESEC/FSE, 2017

    2017

  33. [41]

    Anti-patterns in search-based program repair

    Shin Hwei Tan,Hiroaki Yoshida,Mukul R Prasad,and Abhik Roychoudhury. Anti-patterns in search-based program repair. In Proc. ACM/IEEE FSE, 2016

    2016

  34. [42]

    Automatedbehavioral regression testing

    WeiJin,AlessandroOrso,andTaoXie. Automatedbehavioral regression testing. InProc. IEEE/ACM ICST, 2010

    2010

  35. [43]

    Identifying test-suite-overfitted patches through test case generation

    Qi Xin and Steven P Reiss. Identifying test-suite-overfitted patches through test case generation. InProc. ACM ISSTA, 2017

    2017

  36. [44]

    Diffgen: Automated regression unit-test generation

    Kunal Taneja and Tao Xie. Diffgen: Automated regression unit-test generation. InProc. IEEE/ACM ASE, 2008

    2008

  37. [45]

    Automaticpatchgenerationlearnedfromhuman-written patches

    Dongsun Kim, Jaechang Nam, Jaewoo Song, and Sunghun Kim. Automaticpatchgenerationlearnedfromhuman-written patches. InIEEE ICSME, 2013

    2013

  38. [46]

    Identifying patch correctness in test-based program repair

    Yingfei Xiong, Xinyuan Liu, Muhan Zeng, Lu Zhang, and Gang Huang. Identifying patch correctness in test-based program repair. InProc. IEEE/ACM ICSE, 2018

    2018

  39. [47]

    Patchverif: Discovering faulty patches in robotic vehicles

    Hyungsub Kim, Muslum Ozgur Ozmen, Z Berkay Celik, Antonio Bianchi, and Dongyan Xu. Patchverif: Discovering faulty patches in robotic vehicles. InProc. USENIX Security, 2023

    2023

  40. [48]

    Verifying security patches

    Jonathan Gallagher, Robin Gonzalez, and Michael E Locasto. Verifying security patches. InProceedings of the 2014 in- ternational workshop on privacy & security in programming, 2014

    2014

  41. [49]

    Leveraging large language model for automatic patch correctness assessment.IEEE TSE, 2024

    XinZhou,BowenXu,KisubKim,DongGyunHan,HungHuu Nguyen, Thanh Le-Cong, Junda He, Bach Le, and David Lo. Leveraging large language model for automatic patch correctness assessment.IEEE TSE, 2024

    2024

  42. [50]

    Cure: Code-aware neural machine translation for automatic program repair

    Nan Jiang,ThibaudLutellier,andLin Tan. Cure: Code-aware neural machine translation for automatic program repair. In 2021 IEEE/ACM ICSE

    2021

  43. [51]

    Thinkrepair: Self-directed automated program repair

    Xin Yin, Chao Ni, Shaohua Wang, Zhenhao Li, Limin Zeng, and Xiaohu Yang. Thinkrepair: Self-directed automated program repair. InProc. ACM ISSTA, 2024

    2024

  44. [52]

    Compilation error repair: for the student programs, from the student programs

    Umair Z Ahmed, Pawan Kumar, Amey Karkare, Purushottam Kar, and Sumit Gulwani. Compilation error repair: for the student programs, from the student programs. InProc. ICSE, 2018

    2018

  45. [53]

    Deepdelta:learningtorepaircompilation errors

    AliMesbah,AndrewRice,EmilyJohnston,NickGlorioso,and EdwardAftandilian. Deepdelta:learningtorepaircompilation errors. InProc. ACM ESEC/FSE, 2019

    2019

  46. [54]

    Xueyang Li, Shangqing Liu, Ruitao Feng, Guozhu Meng, Xi- aofeiXie,KaiChen,andYangLiu.Transrepair:Context-aware program repair for compilation errors. InProc. IEEE/ACM ASE, 2022

    2022

  47. [55]

    Patches as better bug reports

    Westley Weimer. Patches as better bug reports. InPro- ceedings of the 5th international conference on Generative programming and component engineering, 2006

    2006

  48. [56]

    Automati- cally fixing c buffer overflows using program transformations

    Alex Shaw, Dusten Doggett, and Munawar Hafiz. Automati- cally fixing c buffer overflows using program transformations. InProc. IEEE DSN, 2014

    2014

  49. [57]

    Bovin- spector: automatic inspection and repair of buffer overflow vulnerabilities

    Fengjuan Gao, Linzhang Wang, and Xuandong Li. Bovin- spector: automatic inspection and repair of buffer overflow vulnerabilities. InProc. IEEE/ACM ASE, 2016

    2016

  50. [58]

    Using safety properties to generate vulnerability patches

    Zhen Huang, David Lie, Gang Tan, and Trent Jaeger. Using safety properties to generate vulnerability patches. InProc. IEEE S&P, 2019

    2019

  51. [59]

    Safe memory-leak fixing for c programs

    QingGao,YingfeiXiong,YaqingMi,LuZhang,WeikunYang, Zhaoping Zhou, Bing Xie, and Hong Mei. Safe memory-leak fixing for c programs. InIEEE/ACM ICSE, 2015. 16

    2015

  52. [60]

    Saver: scalable, precise, and safe memory-error repair

    Seongjoon Hong, Junhee Lee, Jeongsoo Lee, and Hakjoo Oh. Saver: scalable, precise, and safe memory-error repair. In Proc. ACM/IEEE ICSE, 2020

    2020

  53. [61]

    Auto- matedmemoryleakfixingonvalue-flowslicesforcprograms

    Hua Yan, Yulei Sui, Shiping Chen, and Jingling Xue. Auto- matedmemoryleakfixingonvalue-flowslicesforcprograms. InProceedingsofthe31stAnnualACMSymposiumonApplied Computing, 2016

    2016

  54. [62]

    Automatic integer error repair by proper-type inference

    Xi Cheng, Min Zhou, Xiaoyu Song, Ming Gu, and Jiaguang Sun. Automatic integer error repair by proper-type inference. IEEE TDSC, 2019

    2019

  55. [63]

    Intrepair: Informed repairing of integer overflows

    Paul Muntean, Martin Monperrus, Hao Sun, Jens Grossklags, and Claudia Eckert. Intrepair: Informed repairing of integer overflows. IEEE TSE, 2019

    2019

  56. [64]

    Rupair: towards automatic buffer overflow detection and rectification for rust

    Baojian Hua, Wanrong Ouyang, Chengman Jiang, Qiliang Fan, and Zhizhong Pan. Rupair: towards automatic buffer overflow detection and rectification for rust. InProc. ACM ASIACCS, 2021

    2021

  57. [65]

    Automaticallydiagnosingand repairing error handling bugs in c

    YuchiTianandBaishakhiRay. Automaticallydiagnosingand repairing error handling bugs in c. InProc. ACM/IEEE ICSE, 2017

    2017

  58. [66]

    Smartshield: Automatic smart contract protection made easy

    YuyaoZhang,SiqiMa,JuanruLi,KailaiLi,SuryaNepal,and Dawu Gu. Smartshield: Automatic smart contract protection made easy. InIEEE SANER, 2020

    2020

  59. [67]

    Evmpatch:Timelyandautomatedpatchingofethereum smart contracts

    Michael Rodler, Wenting Li, Ghassan O Karame, and Lucas Davi. Evmpatch:Timelyandautomatedpatchingofethereum smart contracts. InProc. USENIX Security, 2021

    2021

  60. [68]

    Ely- sium:Context-awarebytecode-levelpatchingtoautomatically heal vulnerable smart contracts

    Christof Ferreira Torres, Hugo Jonker, and Radu State. Ely- sium:Context-awarebytecode-levelpatchingtoautomatically heal vulnerable smart contracts. InProceedings of the 25th International Symposium on Research in Attacks, Intrusions and Defenses, 2022

    2022

  61. [69]

    Sguard: towards fixingvulnerablesmartcontractsautomatically

    Tai D Nguyen, Long H Pham, and Jun Sun. Sguard: towards fixingvulnerablesmartcontractsautomatically. In Proc.IEEE S&P, 2021

    2021

  62. [70]

    Contractfix: A framework for automatically fixing vulnerabilities in smart contracts.arXiv:2307.08912, 2023

    Pengcheng Fang. Contractfix: A framework for automatically fixing vulnerabilities in smart contracts.arXiv:2307.08912, 2023

    2023 arXiv

  63. [71]

    Automatically fixing security vulnerabilities in java code

    Aharon Abadi, Ran Ettinger, Yishai A Feldman, and Mati Shomrat. Automatically fixing security vulnerabilities in java code. InProc. ACM OOPSLA, 2011

    2011

  64. [72]

    Vfix: value-flow-guided precise program repair for null pointer dereferences

    Xuezheng Xu, Yulei Sui, Hua Yan, and Jingling Xue. Vfix: value-flow-guided precise program repair for null pointer dereferences. InProc. ACM/IEEE ICSE, 2019

    2019

  65. [73]

    Regexscalpel: Regular expression denial of service (redos) defense by localize-and-fix

    Yeting Li, Yecheng Sun, Zhiwu Xu, Jialun Cao, Yuekang Li, Rongchen Li, Haiming Chen, Shing-Chi Cheung, Yang Liu, and Yang Xiao. Regexscalpel: Regular expression denial of service (redos) defense by localize-and-fix. InUSENIX Security, 2022

    2022

  66. [74]

    Cdrep:Auto- matic repairof cryptographic misuses in android applications

    SiqiMa,DavidLo,TengLi,andRobertHDeng. Cdrep:Auto- matic repairof cryptographic misuses in android applications. InProc. ACM ASIACCS, 2016

    2016

  67. [75]

    Example-based vulnerability detection and repair in java code

    Ying Zhang, Ya Xiao, Md Mahir Asef Kabir, Danfeng Yao, and Na Meng. Example-based vulnerability detection and repair in java code. InProc. IEEE/ACM ICPC, 2022

    2022

  68. [76]

    Vurle: Automatic vulnerability detection and repair by learning from examples

    Siqi Ma, Ferdian Thung, David Lo, Cong Sun, and Robert H Deng. Vurle: Automatic vulnerability detection and repair by learning from examples. InProc. IEEE ESORICS, 2017

    2017

  69. [77]

    Binary rewriting without control flow recovery

    GregoryJDuck,XiangGao,andAbhikRoychoudhury. Binary rewriting without control flow recovery. InProc. ACM PLDI, 2020

    2020

  70. [78]

    Westley Weimer, ThanhVu Nguyen, Claire Le Goues, and StephanieForrest.Automaticallyfindingpatchesusinggenetic programming. InProc. ACM/IEEE ICSE, 2009

    2009

  71. [79]

    A genetic programming approach to auto- mated software repair

    Stephanie Forrest, ThanhVu Nguyen, Westley Weimer, and Claire Le Goues. A genetic programming approach to auto- mated software repair. InProc. ACM/IEEE GECCO, 2009

    2009

  72. [80]

    A systematic study of automated program repair: Fixing 55 out of 105 bugs for $8 each

    ClaireLeGoues,MichaelDewey-Vogt,StephanieForrest,and Westley Weimer. A systematic study of automated program repair: Fixing 55 out of 105 bugs for $8 each. InProc. ACM/IEEE ICSE, 2012

    2012

  73. [81]

    Genprog: A generic method for automatic software repair.IEEE TSE, 2011

    Claire Le Goues, ThanhVu Nguyen, Stephanie Forrest, and Westley Weimer. Genprog: A generic method for automatic software repair.IEEE TSE, 2011

    2011

  74. [82]

    Sapfix: Automated end-to-end repair at scale

    AlexandruMarginean,JohannesBader,SatishChandra,Mark Harman, Yue Jia, Ke Mao, Alexander Mols, and Andrew Scott. Sapfix: Automated end-to-end repair at scale. InProc. ACM/IEEE ICSE, 2019

    2019

  75. [83]

    Hypergi: Automateddetection and repair of information flow leakage

    Ibrahim Mesecan, Daniel Blackwell, David Clark, Myra B Cohen,andJustyna Petke. Hypergi: Automateddetection and repair of information flow leakage. InProc. IEEE/ACM ASE, 2021

    2021

  76. [84]

    Dynamic patch generation for null pointer exceptions using metaprogramming

    Thomas Durieux, Benoit Cornu, Lionel Seinturier, and Mar- tin Monperrus. Dynamic patch generation for null pointer exceptions using metaprogramming. InProc. IEEE SANER, 2017

    2017

  77. [85]

    Property-based automated repair of defi protocols

    Palina Tolmach, Yi Li, and Shang-Wei Lin. Property-based automated repair of defi protocols. InProc. IEEE/ACM ASE, 2022

    2022

  78. [86]

    Backportingsecuritypatchesofwebapplications:Aprototype design and implementation on injection vulnerability patches

    YoukunShi,YuanZhang,TianhanLuo,XiangyuMao,Yinzhi Cao, Ziwen Wang, Yudi Zhao, Zongan Huang, and Min Yang. Backportingsecuritypatchesofwebapplications:Aprototype design and implementation on injection vulnerability patches. InUSENIX Security, 2022

    2022

  79. [87]

    Automatedpatch backportinginlinux(experiencepaper)

    Ridwan Shariffdeen, Xiang Gao, Gregory J Duck, Shin Hwei Tan,JuliaLawall,andAbhikRoychoudhury. Automatedpatch backportinginlinux(experiencepaper). In Proc.ACMISSTA , 2021. 17

    2021

  80. [88]

    Enhancing oss patch backporting with semantics

    Su Yang, Yang Xiao, Zhengzi Xu, Chengyi Sun, Chen Ji, and Yuqing Zhang. Enhancing oss patch backporting with semantics. InProc. ACM SIGSAC CCS, 2023

    2023

  81. [89]

    Automated patch transplantation

    Ridwan Salihin Shariffdeen, Shin Hwei Tan, Mingyuan Gao, and Abhik Roychoudhury. Automated patch transplantation. ACM TOSEM, 2020

    2020

  82. [90]

    Fix me up: Repairing access-control bugs in web applications

    Sooel Son, Kathryn S McKinley, and Vitaly Shmatikov. Fix me up: Repairing access-control bugs in web applications. In NDSS, 2013

    2013

  83. [91]

    Automatic hot patch generation for android kernels

    Zhengzi Xu, Yulong Zhang, Longri Zheng, Liangzhao Xia, Chenfu Bao, Zhi Wang, and Yang Liu. Automatic hot patch generation for android kernels. InUSENIX Security, 2020

    2020

  84. [92]

    Static automated programrepairforheapproperties

    Rijnard van Tonder and Claire Le Goues. Static automated programrepairforheapproperties. In Proc.ACM/IEEEICSE , 2018

    2018

  85. [93]

    Memfix:static analysis-based repair of memory deallocation errors for c

    JunheeLee,SeongjoonHong,andHakjooOh. Memfix:static analysis-based repair of memory deallocation errors for c. In Proc. ACM ESEC/FSE, 2018

    2018

  86. [94]

    Automating patching of vulnerable open-source software versions in application binaries

    Ruian Duan, Ashish Bijlani, Yang Ji, Omar Alrawi, Yiyuan Xiong, Moses Ike, Brendan Saltaformaggio, and Wenke Lee. Automating patching of vulnerable open-source software versions in application binaries. InNDSS, 2019

    2019

  87. [95]

    Programrepairguidedbydatalog-definedstaticanalysis

    YuLiu,SergeyMechtaev,PavleSubotić,andAbhikRoychoud- hury. Programrepairguidedbydatalog-definedstaticanalysis. In Proc. ESEC/FSE, 2023

    2023

  88. [96]

    Repairing dos vulnera- bility of real-world regexes

    Nariyoshi Chida and Tachio Terauchi. Repairing dos vulnera- bility of real-world regexes. InProc. IEEE S&P, 2022

    2022

  89. [97]

    Semfix: Program repair via semantic analysis

    HoangDuongThienNguyen,DaweiQi,AbhikRoychoudhury, and Satish Chandra. Semfix: Program repair via semantic analysis. InProc. ACM/IEEE ICSE, 2013

    2013

  90. [98]

    An- gelix:Scalablemultilineprogrampatchsynthesisviasymbolic analysis

    Sergey Mechtaev, Jooyong Yi, and Abhik Roychoudhury. An- gelix:Scalablemultilineprogrampatchsynthesisviasymbolic analysis. InProc. IEEE/ACM ICSE, 2016

    2016

  91. [99]

    Concolicprogramrepair

    Ridwan Shariffdeen, Yannic Noller, Lars Grunske, and Abhik Roychoudhury. Concolicprogramrepair. InProc.ACM/IEEE ICSE, 2021

    2021

  92. [100]

    Repairing programs with semantic code search(t)

    YalinKe,KathrynTStolee,ClaireLeGoues,andYuriyBrun. Repairing programs with semantic code search(t). InProc. IEEE/ACM ASE, 2015

    2015

  93. [101]

    Directfix: Looking for simple program repairs

    Sergey Mechtaev, Jooyong Yi, and Abhik Roychoudhury. Directfix: Looking for simple program repairs. In Proc. ACM/IEEE ICSE, 2015

    2015

  94. [102]

    Adaptive android kernel live patching

    Yue Chen, Yulong Zhang, Zhi Wang, Liangzhao Xia, Chenfu Bao, and Tao Wei. Adaptive android kernel live patching. In Proc. USENIX Security, 2017

    2017

  95. [103]

    Crash-avoiding program repair

    Xiang Gao, Sergey Mechtaev, and Abhik Roychoudhury. Crash-avoiding program repair. InProc. ACM ISSTA, 2019

    2019

  96. [104]

    Nopol: Automatic repair of conditional statement bugs in java programs.IEEE TSE, 2016

    Jifeng Xuan, Matias Martinez, Favio Demarco, Maxime Clement, Sebastian Lamelas Marcote, Thomas Durieux, Daniel Le Berre, and Martin Monperrus. Nopol: Automatic repair of conditional statement bugs in java programs.IEEE TSE, 2016

    2016

  97. [105]

    Learning to repair software vulnerabilities with generative adversarial networks

    Jacob Harer, Onur Ozdemir, Tomo Lazovich, Christopher Reale, Rebecca Russell, Louis Kim, et al. Learning to repair software vulnerabilities with generative adversarial networks. Advances in neural information processing systems, 2018

    2018

  98. [106]

    Repairing security vulnerabilities using pre-trained programming language models

    Kai Huang, Su Yang, Hongyu Sun, Chengyi Sun, Xuejun Li, and Yuqing Zhang. Repairing security vulnerabilities using pre-trained programming language models. InIEEE DSN-W, 2022

    2022

  99. [107]

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

    Nafis Tanveer Islam and Peyman Najafirad. Code security vulnerability repair using reinforcement learning with large language models.arXiv:2401.07031, 2024

    2024 arXiv

  100. [108]

    Explor- ing the limits of chatgpt in software security applications

    Fangzhou Wu, Qingzhao Zhang, Ati Priya Bajaj, Tiffany Bao, Ning Zhang, Ruoyu Wang, Chaowei Xiao, et al. Explor- ing the limits of chatgpt in software security applications. arXiv:2312.05275, 2023

    2023 arXiv

  101. [109]

    Fixing hardware security bugs with large language models.arXiv:2302.01215, 2023

    BaleeghAhmad,ShailjaThakur,BenjaminTan,RameshKarri, and Hammond Pearce. Fixing hardware security bugs with large language models.arXiv:2302.01215, 2023

    2023 arXiv

  102. [110]

    Navrepair: Node-type aware c/c++ code vulner- ability repair.arXiv:2405.04994, 2024

    Ruoke Wang, Zongjie Li, Chaozheng Wang, Yang Xiao, and Cuiyun Gao. Navrepair: Node-type aware c/c++ code vulner- ability repair.arXiv:2405.04994, 2024

    2024

  103. [111]

    Prompt fix:Vulnerabilityautomaticrepairtechnologybasedonprompt engineering

    PengLiu,HeWang,ChenZheng,andYuqingZhang. Prompt fix:Vulnerabilityautomaticrepairtechnologybasedonprompt engineering. InProc. IEEE ICNC, 2024

    2024

  104. [112]

    Exploring chatgpt’s capabilities on vulnerabil- ity management

    Peiyu Liu, Junming Liu, Lirong Fu, Kangjie Lu, Yifan Xia, Xuhong Zhang, Wenzhi Chen, Haiqin Weng, Shouling Ji, and Wenhai Wang. Exploring chatgpt’s capabilities on vulnerabil- ity management. InUSENIX Security, 2024

    2024

  105. [113]

    Vision transformer inspired automated vulnerability repair.ACM TOSEM, (3), 2024

    Michael Fu, Van Nguyen, Chakkrit Tantithamthavorn, Dinh Phung, and Trung Le. Vision transformer inspired automated vulnerability repair.ACM TOSEM, (3), 2024

    2024

  106. [114]

    Chain-of-thought prompting of large language models for discovering and fixing software vulnerabilities

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

    2024 arXiv

  107. [115]

    arXiv:2409.18395, 2024

    ArshiyaKhan,GuannanLiu,andXingGao.Codevulnerability repair with large language model using context-aware prompt tuning. arXiv:2409.18395, 2024

    2024 arXiv

  108. [116]

    Contracttinker: Llm-empoweredvulnerabil- ity repair for real-world smart contracts

    Che Wang, Jiashuo Zhang, Jianbo Gao, Libin Xia, Zhi Guan, andZhongChen. Contracttinker: Llm-empoweredvulnerabil- ity repair for real-world smart contracts. InProc. IEEE/ACM ASE, 2024

    2024

  109. [117]

    A case study of llm for automated vulnerability repair: Assessing impact of reasoning and patch validation 18 feedback

    Ummay Kulsum, Haotian Zhu, Bowen Xu, and Marcelo d’Amorim. A case study of llm for automated vulnerability repair: Assessing impact of reasoning and patch validation 18 feedback. InProceedings of the 1st ACM International Con- ference on AI-Powered Software, 2024

    2024

  110. [118]

    Out of sight, out of mind: Better automatic vulnerability repair by broadening input ranges and sources

    XinZhou,KisubKim,BowenXu,DongGyunHan,andDavid Lo. Out of sight, out of mind: Better automatic vulnerability repair by broadening input ranges and sources. InIEEE/ACM ICSE, 2024

    2024

  111. [119]

    A new era in software security: Towards self-healing soft- ware via large language models and formal verification

    Norbert Tihanyi, Ridhi Jain, Yiannis Charalambous, Mo- hamed Amine Ferrag, Youcheng Sun, and Lucas C Cordeiro. A new era in software security: Towards self-healing soft- ware via large language models and formal verification. arXiv:2305.14752, 2023

    2023 arXiv

  112. [120]

    Sok: Software compartmentalization

    Hugo Lefeuvre, Nathan Dautenhahn, David Chisnall, and Pierre Olivier. Sok: Software compartmentalization. InProc. IEEE S&P, 2025

    2025

  113. [121]

    Sok: Taxonomy of attacks on open-source software supply chains

    PiergiorgioLadisa,HenrikPlate,MatiasMartinez,andOlivier Barais. Sok: Taxonomy of attacks on open-source software supply chains. InProc. IEEE S&P, 2023

    2023

  114. [122]

    https://www.core.edu.au/conf erence-portal, 2024

    Core rankings portal. https://www.core.edu.au/conf erence-portal, 2024. Access on: May, 2024

    2024

  115. [123]

    Systematic review: Analysis of coding vulnerabilities across languages

    Shreyas Sakharkar. Systematic review: Analysis of coding vulnerabilities across languages. Journal of Information Security, 2023

    2023

  116. [124]

    Can memory-safe programming languages kill 70 https://securityintelligence.com/news/ memory-safe-programming-languages-security-b ugs/, 2024

    Jennifer Gregory. Can memory-safe programming languages kill 70 https://securityintelligence.com/news/ memory-safe-programming-languages-security-b ugs/, 2024. Accessed on: May, 2024

    2024

  117. [125]

    Softwarevulnerability repair

    RIDWANSALIHINSHARIFFDEEN. Softwarevulnerability repair. 2022

    2022

  118. [126]

    Jon Erickson.Hacking: the art of exploitation. 2008

    2008

  119. [127]

    What was the dao?, 2023

    Cryptopedia Staff. What was the dao?, 2023

    2023

  120. [128]

    Controlflowanalysis

    FrancesEAllen. Controlflowanalysis. ACMSigplanNotices , 1970

    1970

  121. [129]

    The program dependence graph and its use in optimization.ACM TOPLAS, 1987

    Jeanne Ferrante, Karl J Ottenstein, and Joe D Warren. The program dependence graph and its use in optimization.ACM TOPLAS, 1987

    1987

  122. [130]

    https://doc.rust-lang

    Rust-ownershipsandlifetimes. https://doc.rust-lang. org/nomicon/ownership.html. Accessed on June 2024

    2024

  123. [131]

    Arbiter: Bridging the static and dynamic divide in vulnerability discovery on binary programs

    Jayakrishna Vadayath, Moritz Eckert, Kyle Zeng, Nicolaas Weideman,GokulkrishnaPraveenMenon,YanickFratantonio, Davide Balzarotti, Adam Doupé, Tiffany Bao, Ruoyu Wang, et al. Arbiter: Bridging the static and dynamic divide in vulnerability discovery on binary programs. 2022

    2022

  124. [132]

    Stacked borrows: an aliasing model for rust.Proceedings of the ACM on Programming Languages, (POPL), 2019

    RalfJung,Hoang-HaiDang,JeehoonKang,andDerekDreyer. Stacked borrows: an aliasing model for rust.Proceedings of the ACM on Programming Languages, (POPL), 2019

    2019

  125. [133]

    Understanding memory and thread safety practices and issues in real-world rust programs

    Boqin Qin,Yilun Chen,Zeming Yu,Linhai Song,andYiying Zhang. Understanding memory and thread safety practices and issues in real-world rust programs. InProc. ACM PLDI, 2020

    2020

  126. [134]

    Heuristic

    Wikipedia. Heuristic. https://en.wikipedia.org/wik i/Heuristic_(computer_science), 2024. Accessed on: Jan, 2024

    2024

  127. [135]

    Bugs as deviant behavior: A general approach to inferring errors in systems code.ACM SIGOPS Operating Systems Review, 2001

    Dawson Engler, David Yu Chen, Seth Hallem, Andy Chou, and Benjamin Chelf. Bugs as deviant behavior: A general approach to inferring errors in systems code.ACM SIGOPS Operating Systems Review, 2001

    2001

  128. [136]

    https://en.wikipedia.org/wiki/Fuzzing,

    Fuzzing. https://en.wikipedia.org/wiki/Fuzzing,

  129. [137]

    ct-fuzz: Fuzzing for timing leaks

    Shaobo He, Michael Emmi, and Gabriela Ciocarlie. ct-fuzz: Fuzzing for timing leaks. InProc. IEEE ICST, 2020

    2020

  130. [138]

    https://en.wikipedia.org/wiki/ Metaprogramming, 2024

    Metaprogramming. https://en.wikipedia.org/wiki/ Metaprogramming, 2024. Accessed on: Jan, 2024

    2024

  131. [139]

    On finding duplication and near-duplication in large software systems

    Brenda S Baker. On finding duplication and near-duplication in large software systems. InProc. IEEE/ACM RE, 1995

    1995

  132. [140]

    A language independent approach for detecting duplicated code

    Stéphane Ducasse, Matthias Rieger, and Serge Demeyer. A language independent approach for detecting duplicated code. InProc. IEEE ICSM, 1999

    1999

  133. [141]

    https://www.lenovo.com/ie/en/glossary/what-is-alt-patch/ , 2024

    What is a patch? the essential guide for computer users. https://www.lenovo.com/ie/en/glossary/what-is-alt-patch/ , 2024

    2024

  134. [142]

    Detection of recurring software vulnerabili- ties

    Nam H Pham, Tung Thanh Nguyen, Hoan Anh Nguyen, and Tien N Nguyen. Detection of recurring software vulnerabili- ties. InProc. IEEE/ACM ASE, 2010

    2010

  135. [143]

    Backporting security fixes

    Red Hat. Backporting security fixes. https://acce ss.redhat.com/security/updates/backporting. Ac- cessed on: Jan, 2024

    2024

  136. [144]

    Documenting and automating collateral evo- lutions in linux device drivers.ACM SIGOPS Operating Systems Review, 2008

    Yoann Padioleau, Julia Lawall, René Rydhof Hansen, and Gilles Muller. Documenting and automating collateral evo- lutions in linux device drivers.ACM SIGOPS Operating Systems Review, 2008

    2008

  137. [145]

    Recommending code changes for automatic backporting of linux device drivers

    Ferdian Thung, Xuan-Bach D Le, David Lo, and Julia Lawall. Recommending code changes for automatic backporting of linux device drivers. InIEEE ICSME, 2016

    2016

  138. [146]

    https://backports.wiki.kernel

    Backports project. https://backports.wiki.kernel. org/index.php/Main_Page,2024. Accessedon:Jan,2024

    2024

  139. [147]

    History driven program repair

    Xuan Bach D Le, David Lo, and Claire Le Goues. History driven program repair. In 2016 IEEE 23rd international conferenceonsoftwareanalysis,evolution,andreengineering (SANER), 2016

    2016

  140. [148]

    Context-awarepatchgenerationforbetterautomated program repair

    MingWen,JunjieChen,RongxinWu,DanHao,andShing-Chi Cheung. Context-awarepatchgenerationforbetterautomated program repair. InIEEE ICSE, 2018

    2018

  141. [149]

    Recurringbugfixesinobject- oriented programs

    Tung Thanh Nguyen, Hoan Anh Nguyen, Nam H Pham, Jafar Al-Kofahi,andTienNNguyen. Recurringbugfixesinobject- oriented programs. InProc. ACM/IEEE ICSE, 2010

    2010

  142. [150]

    Kim Marriott and Peter J Stuckey.Programming with con- straints: an introduction. 1998. 19

    1998

  143. [151]

    Automated program repair.Communications of the ACM, (12), 2019

    Claire Le Goues, Michael Pradel, and Abhik Roychoudhury. Automated program repair.Communications of the ACM, (12), 2019

    2019

  144. [152]

    Effective typestate verification in the pres- ence of aliasing.ACM TOSEM, 2008

    Stephen J Fink, Eran Yahav, Nurit Dor, G Ramalingam, and Emmanuel Geay. Effective typestate verification in the pres- ence of aliasing.ACM TOSEM, 2008

    2008

  145. [153]

    Exact cover

    Wikipedia. Exact cover. https://en.wikipedia.org/w iki/Exact_cover, 2024. Accessed on: Jan, 2024

    2024

  146. [154]

    https://en.wikipedia.org/wiki/Datalog,

    Datalog. https://en.wikipedia.org/wiki/Datalog,

  147. [155]

    Symbolic execution and program testing

    James C King. Symbolic execution and program testing. Communications of the ACM, (7), 1976

    1976

  148. [156]

    Accessed on: Jan, 2024

    2024

  149. [157]

    Dart: Directed automated random testing

    Patrice Godefroid, Nils Klarlund, and Koushik Sen. Dart: Directed automated random testing. InProceedings of the 2005 ACM SIGPLAN conference on Programming language design and implementation, 2005

    2005

  150. [158]

    Klee: Unassisted and automatic generation of high-coverage tests for complex systems programs

    Cristian Cadar, Daniel Dunbar, Dawson R Engler, et al. Klee: Unassisted and automatic generation of high-coverage tests for complex systems programs. InProc. OSDI, 2008

    2008

  151. [159]

    In2012 USENIX annual technical conference (USENIX ATC 12), 2012

    KonstantinSerebryany,DerekBruening,AlexanderPotapenko, and Dmitriy Vyukov.{AddressSanitizer}: A fast address sanity checker. In2012 USENIX annual technical conference (USENIX ATC 12), 2012

    2012

  152. [160]

    Satisfiabilitymodulotheories

    ClarkBarrettandCesareTinelli. Satisfiabilitymodulotheories . 2018

    2018

  153. [161]

    What is formal methods?NASA LaRC Formal Methods Program, 2001

    Ricky W Butler. What is formal methods?NASA LaRC Formal Methods Program, 2001

    2001

  154. [162]

    Undefinedbehaviorsanitizer

    Clang. Undefinedbehaviorsanitizer. https://clang.llvm .org/docs/UndefinedBehaviorSanitizer.html, 2024. Accessed on: Jan, 2024

    2024

  155. [163]

    Daikon (system)

    Wikipedia. Daikon (system). https://en.wikipedia .org/wiki/Daikon_(system), 2024. Accessed on: May, 2024

    2024

  156. [164]

    A formal theory of inductive inference

    Ray J Solomonoff. A formal theory of inductive inference. part i.Information and control, 1964

    1964

  157. [165]

    Model checking

    Edmund M Clarke. Model checking. In Foundations of SoftwareTechnologyandTheoreticalComputerScience:17th Conference Kharagpur, India, December 18–20, 1997 Pro- ceedings 17, 1997

    1997

  158. [166]

    cvc5: A versatile and industrial-strength smt solver

    Haniel Barbosa, Clark Barrett, Martin Brain, Gereon Kremer, Hanna Lachnitt, Makai Mann, Abdalrhman Mohamed, Mu- dathirMohamed,AinaNiemetz,AndresNötzli,etal. cvc5: A versatile and industrial-strength smt solver. InInternational Conferenceon ToolsandAlgorithmsforthe Construction...

    2022

  159. [167]

    strcpy function

    cplusplus. strcpy function. https://cplusplus.com/ reference/cstring/strcpy/, 2024. Accessed on: Jan, 2024

    2024

  160. [168]

    Z3: An efficient smt solver

    Leonardo De Moura and Nikolaj Bjørner. Z3: An efficient smt solver. InProc. IEEE TACAS, 2008

    2008

  161. [169]

    Specification-based program repair using sat

    DivyaGopinath,MuhammadZubairMalik,andSarfrazKhur- shid. Specification-based program repair using sat. InTools and Algorithms for the Construction and Analysis of Systems, 2011

    2011

  162. [170]

    https://en.wikipedia .org/wiki/Boolean_satisfiability_problem, 2024

    Boolean satisfiability problem. https://en.wikipedia .org/wiki/Boolean_satisfiability_problem, 2024. Accessed on: Jan, 2024

    2024

  163. [171]

    https: //www.practicallogix.com/common-challenges-f aced-in-software-requirements-specification-a nd-how-to-overcome-them-your-ultimate-guide/ , 2024

    Common challenges faced in software requirements specification and how to overcome them. https: //www.practicallogix.com/common-challenges-f aced-in-software-requirements-specification-a nd-how-to-overcome-them-your-ultimate-guide/ , 2024

    2024

  164. [172]

    Symbolic execution with existential second-order constraints

    Sergey Mechtaev, Alberto Griggio, Alessandro Cimatti, and Abhik Roychoudhury. Symbolic execution with existential second-order constraints. InProc. ACM ESEC/FSE, 2018

    2018

  165. [173]

    Elixir: Effective object-oriented program repair

    Ripon K Saha, Yingjun Lyu, Hiroaki Yoshida, and Mukul R Prasad. Elixir: Effective object-oriented program repair. In Proc. IEEE/ACM ASE, 2017

    2017

  166. [174]

    Automatic patch generation by learning correct code

    Fan Long and Martin Rinard. Automatic patch generation by learning correct code. InProc. ACM POPL, 2016

    2016

  167. [175]

    Dlfix: Context- based code transformation learning for automated program repair

    Yi Li, Shaohua Wang, and Tien N Nguyen. Dlfix: Context- based code transformation learning for automated program repair. InProc. ACM/IEEE ICSE, 2020

    2020

  168. [176]

    Sorting and transforming programrepairingredientsviadeeplearningcodesimilarities

    MartinWhite,MicheleTufano,MatiasMartinez,MartinMon- perrus, and Denys Poshyvanyk. Sorting and transforming programrepairingredientsviadeeplearningcodesimilarities. InProc. IEEE SANER, 2019

    2019

  169. [177]

    Fixminer:Miningrelevantfixpatternsforautomatedprogram repair

    Anil Koyuncu, Kui Liu, Tegawendé F Bissyandé, Dongsun Kim, Jacques Klein, Martin Monperrus, and Yves Le Traon. Fixminer:Miningrelevantfixpatternsforautomatedprogram repair. Empirical Software Engineering, (3), 2020

    2020

  170. [178]

    Learningsyntacticprogramtransformations from examples

    Reudismam Rolim, Gustavo Soares, Loris D’Antoni, Olek- sandr Polozov, Sumit Gulwani, Rohit Gheyi, Ryo Suzuki, and BjörnHartmann. Learningsyntacticprogramtransformations from examples. InProc. IEEE/ACM ICSE, 2017

    2017

  171. [179]

    Neuralprogramrepairbyjointlylearning to localize and repair.arXiv:1904.01720, 2019

    Marko Vasic, Aditya Kanade, Petros Maniatis, David Bieber, andRishabhSingh. Neuralprogramrepairbyjointlylearning to localize and repair.arXiv:1904.01720, 2019

    1904 arXiv

  172. [180]

    Deepfix: Fixing common c language errors by deep learning

    RahulGupta,SohamPal,AdityaKanade,andShirishShevade. Deepfix: Fixing common c language errors by deep learning. InProc. AAAI, 2017

    2017

  173. [181]

    An empiricalstudy on learning bug-fixing patches in the wildvia neural machine translation.ACM TOSEM, 2019

    Michele Tufano, Cody Watson, Gabriele Bavota, Massimil- iano Di Penta, Martin White, and Denys Poshyvanyk. An empiricalstudy on learning bug-fixing patches in the wildvia neural machine translation.ACM TOSEM, 2019

    2019

  174. [182]

    Se- quencer: Sequence-to-sequence learning for end-to-end pro- gram repair.IEEE TSE, 2019

    Zimin Chen, Steve Kommrusch, Michele Tufano, Louis-Noël Pouchet, Denys Poshyvanyk, and Martin Monperrus. Se- quencer: Sequence-to-sequence learning for end-to-end pro- gram repair.IEEE TSE, 2019. 20

    2019

  175. [183]

    Coconut: combining context-aware neural translation models using ensemble for program repair

    ThibaudLutellier,HungVietPham,LawrencePang,YitongLi, Moshi Wei, and Lin Tan. Coconut: combining context-aware neural translation models using ensemble for program repair. In Proceedings of the 29th ACM SIGSOFT international symposium on software testing and analysis, 2020

    2020

  176. [184]

    Codit:Codeeditingwithtree-basedneural models

    Saikat Chakraborty, Yangruibo Ding, Miltiadis Allamanis, andBaishakhiRay. Codit:Codeeditingwithtree-basedneural models. IEEE TSE, 2020

    2020

  177. [185]

    Pre-trained model-based automated software vulnerability repair: How far are we? IEEE TDSC, 2023

    Quanjun Zhang, Chunrong Fang, Bowen Yu, Weisong Sun, Tongke Zhang, and Zhenyu Chen. Pre-trained model-based automated software vulnerability repair: How far are we? IEEE TDSC, 2023

    2023

  178. [186]

    Dear: A novel deep learning-based approach for automated program repair

    Yi Li, Shaohua Wang, and Tien N Nguyen. Dear: A novel deep learning-based approach for automated program repair. arXiv:2205.01859, 2022

    2022 arXiv

  179. [187]

    Codebleu: a method for automatic evaluation of code synthesis.arXiv:2009.10297, 2020

    ShuoRen,DayaGuo,ShuaiLu,LongZhou,ShujieLiu,Duyu Tang, Neel Sundaresan, Ming Zhou, Ambrosio Blanco, and Shuai Ma. Codebleu: a method for automatic evaluation of code synthesis.arXiv:2009.10297, 2020

    2009 arXiv

  180. [188]

    Reinforcementlearning:Asurvey

    Leslie Pack Kaelbling, Michael L Littman, and Andrew W Moore. Reinforcementlearning:Asurvey. Journalofartificial intelligence research, 1996

    1996

  181. [189]

    Proximal policy optimization algorithms

    JohnSchulman,FilipWolski,PrafullaDhariwal,AlecRadford, and Oleg Klimov. Proximal policy optimization algorithms. arXiv:1707.06347, 2017

    2017 arXiv

  182. [190]

    Bertscore: Evaluating text generation with bert

    TianyiZhang,VarshaKishore,FelixWu,KilianQWeinberger, and Yoav Artzi. Bertscore: Evaluating text generation with bert. arXiv:1904.09675, 2019

    1904 arXiv

  183. [191]

    https://openai.com/blog/openai-codex, 2022

    Codex. https://openai.com/blog/openai-codex, 2022

    2022

  184. [192]

    Codegen2: Lessons for training llms on programming and natural languages

    Erik Nijkamp, Hiroaki Hayashi, Caiming Xiong, Silvio Savarese, and Yingbo Zhou. Codegen2: Lessons for training llms on programming and natural languages. arXiv:2305.02309, 2023

    2023 arXiv

  185. [193]

    https://openai.com/gpt-4, 2023

    Gpt-4. https://openai.com/gpt-4, 2023

    2023

  186. [194]

    Codet5: Identifier-aware unified pre-trained encoder- decoder models for code understanding and generation

    Yue Wang, Weishi Wang, Shafiq Joty, and Steven CH Hoi. Codet5: Identifier-aware unified pre-trained encoder- decoder models for code understanding and generation. arXiv:2109.00859, 2021

    2021 arXiv

  187. [195]

    Sard: A software assurance reference dataset

    Paul E Black et al. Sard: A software assurance reference dataset. In Anonymous Cybersecurity Innovation Forum., 2017

    2017

  188. [196]

    Esbmc 5.0: an industrial-strengthcmodelchecker

    MikhailRGadelha,FelipeRMonteiro,JeremyMorse,LucasC Cordeiro, Bernd Fischer, and Denis A Nicole. Esbmc 5.0: an industrial-strengthcmodelchecker. In Proc.IEEE/ACMASE , 2018

    2018

  189. [197]

    Large language models for code: Security hardening and adversarial testing

    Jingxuan He and Martin Vechev. Large language models for code: Security hardening and adversarial testing. InProc. ACM CCS, 2023

    2023

  190. [198]

    Crossvul: a cross-language vulner- ability dataset with commit data

    Georgios Nikitopoulos, Konstantina Dritsa, Panos Louridas, and Dimitris Mitropoulos. Crossvul: a cross-language vulner- ability dataset with commit data. InProc. ACM ESEC/FSE, 2021

    2021

  191. [199]

    A manually-curated dataset of fixes to vulnerabilities of open-source software

    Serena Elisa Ponta, Henrik Plate, Antonino Sabetta, Michele Bezzi, and Cédric Dangremont. A manually-curated dataset of fixes to vulnerabilities of open-source software. InProc. IEEE/ACM MSR, 2019

    2019

  192. [200]

    Cvefixes: automated collection of vulnerabilities and their fixes from open-source software

    Guru Bhandari, Amara Naseer, and Leon Moonen. Cvefixes: automated collection of vulnerabilities and their fixes from open-source software. InProceedings of the 17th Interna- tional Conference on Predictive Models and Data Analytics in Software Engineering, 2021

    2021

  193. [201]

    A ground-truth dataset of real security patches.arXiv:2110.09635, 2021

    Sofia Reis and Rui Abreu. A ground-truth dataset of real security patches.arXiv:2110.09635, 2021

    2021 arXiv

  194. [202]

    Ac/c++ code vulnerability dataset with code changes and cve sum- maries

    JiahaoFan,YiLi,ShaohuaWang,andTienNNguyen. Ac/c++ code vulnerability dataset with code changes and cve sum- maries. InProc. IEEE/ACM MSR, 2020

    2020

  195. [203]

    Paul E Black and Paul E Black.Juliet 1.3 test suite. 2018

    2018

  196. [204]

    Vul4j: a dataset of reproducible java vulnerabilities geared towards the study of program repair techniques

    Quang-CuongBui,RiccardoScandariato,andNicolásEDíaz Ferreyra. Vul4j: a dataset of reproducible java vulnerabilities geared towards the study of program repair techniques. In Proc. IEEE/ACM MSR, 2022

    2022

  197. [205]

    Incoder:Agenerativemodelforcode infilling and synthesis.arXiv:2204.05999, 2022

    Daniel Fried, Armen Aghajanyan, Jessy Lin, Sida Wang, Eric Wallace, Freda Shi, Ruiqi Zhong, Wen-tau Yih, Luke Zettle- moyer,andMikeLewis. Incoder:Agenerativemodelforcode infilling and synthesis.arXiv:2204.05999, 2022

    2022 arXiv

  198. [206]

    Maestro: A platform for benchmarking automatic program repair tools on software vulnerabilities

    Eduard Pinconschi, Quang-Cuong Bui, Rui Abreu, Pedro Adão, and Riccardo Scandariato. Maestro: A platform for benchmarking automatic program repair tools on software vulnerabilities. InProc. ISSTA, 2022

    2022

  199. [207]

    Impact of code language models on automated program repair

    NanJiang,KevinLiu,ThibaudLutellier,andLinTan. Impact of code language models on automated program repair. In IEEE/ACM ICSE, 2023

    2023

  200. [208]

    Ai-powered patching: the future of automated vulnerability fixes

    Jan Nowakowski Jan Keller. Ai-powered patching: the future of automated vulnerability fixes. Accessed on: May, 2024

    2024

  201. [209]

    https://www.w3.org/Grap hics/JPEG/itu-t81.pdf, 1993

    Itu-t recommendation t.81. https://www.w3.org/Grap hics/JPEG/itu-t81.pdf, 1993. Accessed on: June, 2024

    1993

  202. [210]

    Google. Gemini. https://gemini.google.com/. Ac- cessed on: May, 2024

    2024

  203. [211]

    Llm-generated invariants for bounded model checking without loop unrolling

    Muhammad AA Pirzada, Giles Reger, Ahmed Bhayat, and Lucas C Cordeiro. Llm-generated invariants for bounded model checking without loop unrolling. InProc. IEEE/ACM ASE, 2024

    2024

  204. [212]

    Llm meets bounded model checking: Neuro-symbolic loop invariant inference

    Guangyuan Wu, Weining Cao, Yuan Yao, Hengfeng Wei, Taolue Chen, and Xiaoxing Ma. Llm meets bounded model checking: Neuro-symbolic loop invariant inference. InProc. IEEE/ACM ASE, 2024. 21

    2024

  205. [213]

    https: //git.kernel.org/pub/scm/linux/kernel/git/to rvalds/linux.git/commit/?id=8a4cd82d62b5, 2024

    nfc: fix refcount leak in llcp_sock_connect(). https: //git.kernel.org/pub/scm/linux/kernel/git/to rvalds/linux.git/commit/?id=8a4cd82d62b5, 2024

    2024

  206. [214]

    Mitigating security risks in linux with klaus: A method for evaluating patch correctness

    Yuhang Wu, Zhenpeng Lin, Yueqi Chen, Dang K Le, Dongliang Mu, and Xinyu Xing. Mitigating security risks in linux with klaus: A method for evaluating patch correctness. In Proc. USENIX Security, 2023

    2023

  207. [215]

    Secbench: A database of real security vulnerabilities

    Sofia Reis and Rui Abreu. Secbench: A database of real security vulnerabilities. InSecSE@ ESORICS, 2017

    2017

  208. [216]

    Correctbench: Automatic testbench genera- tion with functional self-correction using llms for hdl design

    RuidiQiu,GraceLiZhang,RolfDrechsler,UlfSchlichtmann, and Bing Li. Correctbench: Automatic testbench genera- tion with functional self-correction using llms for hdl design. arXiv:2411.08510, 2024

    2024 arXiv

  209. [217]

    https://github.com/bminor/binutils -gdb, 2023

    Binutils-gdb. https://github.com/bminor/binutils -gdb, 2023

    2023

  210. [218]

    Vulrepair: a t5-based automated software vulnerability repair

    Michael Fu, Chakkrit Tantithamthavorn, Trung Le, Van Nguyen, and Dinh Phung. Vulrepair: a t5-based automated software vulnerability repair. InACM ESEC/FSE, 2022

    2022

  211. [219]

    https://huggingface.co/

    Huggingface. https://huggingface.co/. Accessedon: May, 2024

    2024

  212. [220]

    https://github.com/vadz/libtiff, 2023

    Libtiff. https://github.com/vadz/libtiff, 2023

    2023

  213. [221]

    Github. Codeql. https://codeql.github.com/, 2024. Accessed on: Jan, 2024

    2024

  214. [222]

    https://joern.io/

    Joern. https://joern.io/. Accessed on: May, 2024

    2024

  215. [223]

    %CVEfixes[198] >30 R 209 5,365

    OmerTripp,SalvatoreGuarnieri,MarcoPistoia,andAleksandr Aravkin. Aletheia: Improving the usability of static security analysis. InACM CCS, 2014. Appendix The appendix illustrates more details on the experimental setting, dataset selection, mutation strategies, security patch ge...

    2014

  216. [224]

    Why can’t johnny fix vulnerabilities: A usability eval- uation of static analysis tools for security

    Justin Smith, Lisa Nguyen Quang Do, and Emerson Murphy- Hill. Why can’t johnny fix vulnerabilities: A usability eval- uation of static analysis tools for security. InSOUPS 2020, 2020

    2020

Pith tools

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