# Using ML filters to help automated vulnerability repairs: when it helps and when it doesn't

arXiv: https://arxiv.org/abs/2504.07027 · HTML: https://mlsanity.com/paper/2504.07027/

## Key facts

- Cited by 1 papers in the map (data through 14 Oct 2026).
- Builds on 14 of its 30 references that are in the map.
- First posted on arXiv 9 Apr 2025.

## Builds on (most cited first, 14 of 14)

- [Deep Learning based Vulnerability Detection: Are We There Yet?](https://mlsanity.com/paper/2009.07235/) (2020)
- [InferFix: End-to-End Program Repair with LLMs](https://mlsanity.com/paper/2303.07263/) (2023)
- [Vulnerability Detection with Fine-grained Interpretations](https://mlsanity.com/paper/2106.10478/) (2021)
- [How Effective Are Neural Networks for Fixing Security Vulnerabilities](https://mlsanity.com/paper/2305.18607/) (2023)
- [A New Era in Software Security: Towards Self-Healing Software via Large Language Models and Formal Verification](https://mlsanity.com/paper/2305.14752/) (2023)
- [Getafix: Learning to Fix Bugs Automatically](https://mlsanity.com/paper/1902.06111/) (2019)
- [LineVD: Statement-level Vulnerability Detection using Graph Neural Networks](https://mlsanity.com/paper/2203.05181/) (2022)
- [Trust Enhancement Issues in Program Repair](https://mlsanity.com/paper/2108.13064/) (2021)
- [On the Efficiency of Test Suite based Program Repair: A Systematic Assessment of 16 Automated Repair Systems for Java Programs](https://mlsanity.com/paper/2008.00914/) (2020)
- [SeqTrans: Automatic Vulnerability Fix via Sequence to Sequence Learning](https://mlsanity.com/paper/2010.10805/) (2020)
- [Vulnerability Detection with Graph Simplification and Enhanced Graph Representation Learning](https://mlsanity.com/paper/2302.04675/) (2023)
- [Code-centric Learning-based Just-In-Time Vulnerability Detection](https://mlsanity.com/paper/2304.08396/) (2023)
- [User-Centric Deployment of Automated Program Repair at Bloomberg](https://mlsanity.com/paper/2311.10516/) (2023)
- [On the acceptance by code reviewers of candidate security patches suggested by Automated Program Repair tools](https://mlsanity.com/paper/2209.07211/) (2022)

## Built on by (most cited first, 1 of 1)

- [Repairing vulnerabilities without invisible hands. A differentiated replication study on LLMs](https://mlsanity.com/paper/2507.20977/) (2025)

## Abstract (arXiv)

[Context:] The acceptance of candidate patches in automated program repair has been typically based on testing oracles. Testing requires typically a costly process of building the application while ML models can be used to quickly classify patches, thus allowing more candidate patches to be generated in a positive feedback loop. [Problem:] If the model predictions are unreliable (as in vulnerability detection) they can hardly replace the more reliable oracles based on testing. [New Idea:] We propose to use an ML model as a preliminary filter of candidate patches which is put in front of a traditional filter based on testing. [Preliminary Results:] We identify some theoretical bounds on the precision and recall of the ML algorithm that makes such operation meaningful in practice. With these bounds and the results published in the literature, we calculate how fast some of state-of-the art vulnerability detectors must be to be more effective over a traditional AVR pipeline such as APR4Vuln based just on testing.