Emanuele Iannone

2026

1. MSR

   

   A Match Made in Heaven? AI-driven Matching of Vulnerabilities and Security Unit Tests

   Emanuele Iannone, Quang-Cuong Bui, and Riccardo Scandariato

   In 2026 IEEE/ACM 23rd International Conference on Mining Software Repositories (MSR), Apr 2026

   PDF Abstract BibTeX

   Software vulnerabilities are often detected via taint analysis, penetration testing, or fuzzing. They are also found via unit tests that exercise security-sensitive behavior with specific inputs, called vulnerability-witnessing tests. Generative AI models could help developers in writing them, but they require many examples to learn from, which are currently scarce. This paper introduces VuTeCo, an AI-driven framework for collecting examples of vulnerability- witnessing tests from Java repositories. VuTeCo carries out two tasks: (1) The "Finding" task to determine whether a unit test case is security-related, and (2) the "Matching" task to relate a test case to the vulnerability it witnesses. VuTeCo addresses the Finding task with UniXcoder, achieving an F0.5 score of 0.73 and a precision of 0.83 on a test set of unit tests from Vul4J. The Matching task is addressed using DeepSeek Coder, achieving an F0.5 score of 0.65 and a precision of 0.75 on a test set of pairs of unit tests and vulnerabilities from Vul4J. VuTeCo has been used in the wild on 427 Java projects and 1,238 vulnerabilities, obtaining 224 test cases confirmed to be security-related and 35 tests correctly matched to 29 vulnerabilities. The validated tests were collected in a new dataset called Test4Vul. VuTeCo lays the foundation for large-scale retrieval of vulnerability-witnessing tests, enabling future AI models to better understand and generate security unit tests

   @inproceedings{iannone:msr2026:vuteco:sec:tests,
     author = {Iannone, Emanuele and Bui, Quang-Cuong and Scandariato, Riccardo},
     booktitle = {2026 IEEE/ACM 23rd International Conference on Mining Software Repositories (MSR)},
     title = {A Match Made in Heaven? AI-driven Matching of Vulnerabilities and Security Unit Tests},
     year = {2026},
     volume = {},
     number = {},
     pages = {},
     keywords = {Mining Software Repositories;Vulnerability-witnessing Tests;Security Testing;Unit Testing;Language Models},
     doi = {},
     issn = {},
     month = apr
   }

2. SANER

   

   VulTerminator: Bringing Back Template-Based Automated Repair for Fixing Java Vulnerabilities

   Quang-Cuong Bui, Emanuele Iannone, and Riccardo Scandariato

   In 2026 IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER), Mar 2026

   PDF Abstract BibTeX

   Abstract—Mainstream techniques for Automated Vulnerability Repair (AVR) lean heavily on Large Language Models (LLMs) and treat the vulnerability repair as a code translation task. Yet, their effectiveness is limited due to the complex nature of vulnerability fixes and, possibly, the lack of training datasets in the Java programming language. On the other hand, template-based Automated Program Repair (APR) remains a popular way to fix general bugs. However, only a few approaches have ever employed vulnerability-specific fix templates. This paper introduces VulTerminator, a novel repair approach for Java vulnerabilities that leverages both heuristic-based and data-driven fix templates. The former are specialized for certain vulnerability types, such as XML External Entity (XXE) injection, which can be more easily patched with predefined heuristics. The latter aim to repair a broader class of vulnerabilities by generating common patch templates with masks, which are later filled by a fine-tuned Masked Language Model (MLM). In this paper, we introduce a total of eleven fix templates distilled from real-world Java patches and evaluate VulTerminator on 106 vulnerabilities with test cases from Vul4J+, as well as on 169 unseen vulnerabilities from a newly curated dataset called Vul4JL. VulTerminator achieves the best overall repair performance, outperforming the state-of-the- art approaches by 7% on Vul4J+ and 27% on Vul4JL, as confirmed by manual inspection. VulTerminator managed to fix 10 vulnerabilities in Vul4J+ and 16 in Vul4JL that no other approach could do, mainly due to the contribution of heuristic-based templates.

   @inproceedings{bui:saner2026:vulterminator:repair,
     author = {Bui, Quang-Cuong and Iannone, Emanuele and Scandariato, Riccardo},
     booktitle = {2026 IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER)},
     title = {VulTerminator: Bringing Back Template-Based Automated Repair for Fixing Java Vulnerabilities},
     year = {2026},
     volume = {},
     number = {},
     pages = {},
     keywords = {Automated Vulnerability Repair;Automated Program Repair;Large Language Models},
     doi = {},
     issn = {},
     month = mar
   }

2025

1. TOSEM

   

   Back to the Roots: Assessing Mining Techniques for Java Vulnerability-Contributing Commits

   Torge Hinrichs, Emanuele Iannone, Tamás Aladics, Péter Hegedűs, Andrea De Lucia, Fabio Palomba, and Riccardo Scandariato

   ACM Trans. Softw. Eng. Methodol., Sep 2025

   PDF Abstract BibTeX Publisher

   Context: Vulnerability-contributing commits (VCCs) are code changes that introduce vulnerabilities. Mining historical VCCs relies on SZZ-based algorithms that trace from known vulnerability-fixing commits. Objective: Although these techniques have been used, e.g., to train just-in-time vulnerability predictors, they lack systematic benchmarking to evaluate their precision, recall, and error sources. Method: We empirically assessed 12 VCC mining techniques in Java repositories using two benchmark datasets (one from the literature and one newly curated). We also explored combinations of techniques, through intersections, voting schemes, and machine learning, to improve performance. Results: Individual techniques achieved at most 0.60 precision but up to 0.89 recall. The precision rose to 0.75 when the outputs were combined with the logical AND, at the expense of recall. Machine learning ensembles reached 0.80 precision with a better precision–recall balance. Performance varied significantly by dataset. Analyzing “fixing commits” showed that certain fix types (e.g., filtering or sanitization) affect retrieval accuracy, and failure patterns highlighted weaknesses when fixes involve external data handling. Conclusion: Such results help software security researchers select the most suitable mining technique for their studies and understand new ways to design more accurate solutions.

   @article{hinrichs:tosem2025:szz:vcc,
     author = {Hinrichs, Torge and Iannone, Emanuele and Aladics, Tam\'{a}s and Hegedűs, P\'{e}ter and De Lucia, Andrea and Palomba, Fabio and Scandariato, Riccardo},
     title = {Back to the Roots: Assessing Mining Techniques for Java Vulnerability-Contributing Commits},
     year = {2025},
     publisher = {Association for Computing Machinery},
     address = {New York, NY, USA},
     issn = {1049-331X},
     url = {https://dl.acm.org/doi/10.1145/3769105},
     doi = {10.1145/3769105},
     journal = {ACM Trans. Softw. Eng. Methodol.},
     month = sep,
     keywords = {Mining Software Repositories, Software Vulnerability, Software Analytics, Machine Learning}
   }

2. ICSME

   

   Retrieve, Refine, or Both? Using Task-Specific Guidelines for Secure Python Code Generation

   Catherine Tony, Emanuele Iannone, and Riccardo Scandariato

   In 2025 IEEE International Conference on Software Maintenance and Evolution (ICSME), Sep 2025

   PDF Abstract BibTeX Publisher

   Large Language Models (LLMs) are increasingly used for code generation, but they often produce code with security vulnerabilities. While techniques like fine-tuning and instruction tuning can improve security, they are computationally expensive and require large amounts of secure code data. Recent studies have explored prompting techniques to enhance code security without additional training. Among these, Recursive Criticism and Improvement (RCI) has demonstrated strong improvements by iteratively refining the generated code by leveraging LLMs’ self-critiquing capabilities. However, RCI relies on the model’s ability to identify security flaws, which is constrained by its training data and susceptibility to hallucinations. This paper investigates the impact of incorporating task-specific secure coding guidelines extracted from MITRE’s CWE and CodeQL recommendations into LLM prompts. For this, we employ Retrieval-Augmented Generation (RAG) to dynamically retrieve the relevant guidelines that help the LLM avoid generating insecure code. We compare RAG with RCI, observing that both deliver comparable performance in terms of code security, with RAG consuming considerably less time and fewer tokens. Additionally, combining both approaches further reduces the amount of insecure code generated, requiring only slightly more resources than RCI alone, highlighting the benefit of adding relevant guidelines in improving LLM-generated code security.

     author = {Tony, Catherine and Iannone, Emanuele and Scandariato, Riccardo},
     booktitle = {2025 IEEE International Conference on Software Maintenance and Evolution (ICSME)},
     title = {Retrieve, Refine, or Both? Using Task-Specific Guidelines for Secure Python Code Generation},
     year = {2025},
     volume = {},
     number = {},
     pages = {368-379},
     keywords = {Training;Codes;Large language models;Retrieval augmented generation;Training data;Encoding;Security;Tuning;Guidelines;Python;Secure Code Generation;Retrieval Augmented Generation;Prompt Engineering;Large Language Models},
     doi = {10.1109/ICSME64153.2025.00041},
     url = {https://ieeexplore.ieee.org/document/11186069},
     issn = {2576-3148},
     month = sep
   }

2023

1. TSE

   

   The Secret Life of Software Vulnerabilities: A Large-Scale Empirical Study

   Emanuele Iannone, Roberta Guadagni, Filomena Ferrucci, Andrea De Lucia, and Fabio Palomba

   IEEE Transactions on Software Engineering, Jan 2023

   PDF Abstract BibTeX Publisher

   Software vulnerabilities are weaknesses in source code that can be potentially exploited to cause loss or harm. While researchers have been devising a number of methods to deal with vulnerabilities, there is still a noticeable lack of knowledge on their software engineering life cycle, for example how vulnerabilities are introduced and removed by developers. This information can be exploited to design more effective methods for vulnerability prevention and detection, as well as to understand the granularity at which these methods should aim. To investigate the life cycle of known software vulnerabilities, we focus on how, when, and under which circumstances the contributions to the introduction of vulnerabilities in software projects are made, as well as how long, and how they are removed. We consider 3,663 vulnerabilities with public patches from the National Vulnerability Database—pertaining to 1,096 open-source software projects on GitHub—and define an eight-step process involving both automated parts (e.g., using a procedure based on the SZZ algorithm to find the vulnerability-contributing commits) and manual analyses (e.g., how vulnerabilities were fixed). The investigated vulnerabilities can be classified in 144 categories, take on average at least 4 contributing commits before being introduced, and half of them remain unfixed for at least more than one year. Most of the contributions are done by developers with high workload, often when doing maintenance activities, and removed mostly with the addition of new source code aiming at implementing further checks on inputs. We conclude by distilling practical implications on how vulnerability detectors should work to assist developers in timely identifying these issues.

   @article{iannone:tse2022:secret:life,
     author = {Iannone, Emanuele and Guadagni, Roberta and Ferrucci, Filomena and De Lucia, Andrea and Palomba, Fabio},
     journal = {IEEE Transactions on Software Engineering},
     title = {The Secret Life of Software Vulnerabilities: A Large-Scale Empirical Study},
     year = {2023},
     volume = {49},
     number = {1},
     pages = {44-63},
     keywords = {},
     doi = {10.1109/TSE.2022.3140868},
     url = {https://ieeexplore.ieee.org/document/9672730},
     issn = {1939-3520},
     month = jan
   }