SANER 2026
Tue 17 - Fri 20 March 2026 Limassol, Cyprus

Accepted Papers

Title
Agentic LLM-Driven C++ Build Automation: An Empirical Study
Research Track
A Multi-Modal Retrieval-Augmented Framework for Compiler Backend Generation with LLMs
Research Track
An Empirical Analysis of Code Clones in GitHub Actions Workflows
Research Track
An Empirical Study of Privacy Leakage Vulnerability in Third-Party Android Logs Libraries
Research Track
Assessing Large Language Models in Verifying Concurrent Programs
Research Track
A Story About Cohesion and Separation: Unsupervised Metric for Log Parser Evaluation
Research Track
Beyond Lexical: Functional Semantics and Fusion for Precise Architecture Recovery
Research Track
Can LLMs Keep Up with Library Changes? An Exploratory Study on LLM-Generated Code
Research Track
CloudFix: Automated Policy Repair for Cloud Access Control Policies Using Large Language Models
Research Track
Cold-Start Anti-Patterns and Refactorings in Serverless Systems: An Empirical Study
Research Track
Combining Static Code Analysis and Large Language Models Improves Correctness and Performance of Algorithm Recognition
Research Track
CoMRA:A Framework for Automated Code Migration via Retrieval-Augmented Generation and Multi-Agent Collaboration
Research Track
CONCORD: A DSL for Generating Simplified and Scalable Graph-Based Code Representations
Research Track
Pre-print
Coverage-Guided Road Selection and Prioritization for Efficient Testing in Autonomous Driving Systems
Research Track
Pre-print
Dialing Danger: Large-Scale Mining and Risk Assessment of Android Secret Codes in OEM Firmware
Research Track
Does one CI-ze fit all? How Continuous Integration Performs in Different Contexts
Research Track
Efficient Translation of Long Code Blocks using Large Language Models
Research Track
From LLMs to Agents in Programming: The Impact of Providing an LLM with a Compiler
Research Track
From Patterns to Precision: LLM-Guided Detection of Signature Verification Flaws in Smart Contracts
Research Track
GDPO: Dual Learning for Self-Supervised Code Summarization in the Era of Large Language Models
Research Track
HieraTest: Hierarchical Dependency–Driven Framework with Multi-Strategy Repair for LLM-based Unit Test Generation
Research Track
InstruMate: A Systematic Framework for Assessing Android App Repackaging Resilience
Research Track
Leveraging Commit-Size Context and Hyper Co-Change Graph Centralities for Defect Prediction
Research Track
Leveraging Enhanced Test-Driven Development for Accurate Code Generation in LLMs
Research Track
Mind the Merge: Evaluating the Effects of Token Merging on Pre-trained Models for Code
Research Track
MLmisFinder: A Specification and Detection Approach of Machine Learning Service Misuses
Research Track
Path-Optimal Symbolic Execution of Heap-Manipulating Programs
Research Track
PiCo: Privacy-preserving Code Sanitization for Cloud-based LLMs
Research Track
ProfRCA: LLM-Enabled Fine-grained Root Cause Analysis with Continuous Profiling Data
Research Track
Programming Language Confusion: When Code LLMs Can't Keep their Languages Straight
Research Track
Progressively Mitigating API Hallucination in LLM-Generated Code via Knowledge Graph Reasoning
Research Track
Relocate and Emulate: Re-Hosting Android’s Application Layer
Research Track
Requirement Formalization using Large Language Models
Research Track
Reusing Legacy Code in Wasm: Key Challenges of Compilation and Code Semantics Preservation
Research Track
RM -RF: Reward Model for Run-Free Unit Test Evaluation
Research Track
Pre-print
Scratching the Iceberg: Unveiling the Outdated Third-Party Native Libraries in Android Apps
Research Track
SeBERTis: A Framework for Producing Classifiers of Security-Related Issue Reports
Research Track
STELLAR: A Search-Based Testing Framework for Large Language Model Applications
Research Track
Symbolic Analysis for Repairing Bugs in Concurrent Persistent-Memory Programs
Research Track
TestForge: A Benchmarking Framework for LLM-Based Test Case Generation
Research Track
The SBOM Gap: Adoption and Compliance in Open Source Software
Research Track
Towards Secure Oracle Usage: Understanding and Detecting Oracle Vulnerabilities in Smart Contracts
Research Track
Understanding the Effectiveness of Mutators in Mutation-based Protocol Fuzzing
Research Track
VFLAGENT: A Chain-of-Thought-Guided Multi-Agent Collaboration Framework for Vulnerable Function Localization
Research Track
VulCMS: A Vulnerability Detection System Based on Centrality Analysis and Multi-Scale Attention
Research Track
VulTerminator: Bringing Back Template-Based Automated Repair for Fixing Java Vulnerabilities
Research Track
What You Trust Is Insecure: Demystifying How Developers (Mis)Use Trusted Execution Environments in Practice
Research Track

Call for Papers

 

The Research Track of the 33rd edition of the IEEE International Conference on Software Analysis, Evolution, and Reengineering (SANER 2026) invites high-quality submissions of papers describing original and unpublished research. We encourage submissions describing various types of research, e.g., empirical, theoretical, and tool-oriented work. The topics of the submissions should be of direct interest to the software analysis, evolution, and reengineering community (including researchers, practitioners, educators). Topics of interest include, but are not limited to:

  • AI for Software Engineering and Software Engineering for AI (see note below);
  • Generative AI and LLM applied to analysis, evolution and reengineering of software;
  • Software Analysis, Parsing, and Fact Extraction;
  • Software Maintenance and Evolution, Evolution Analysis;
  • Software Reverse Engineering and Reengineering;
  • Program Comprehension;
  • Software Architecture Recovery and Reverse Architecting;
  • Program Transformation and Refactoring;
  • Mining Software Repositories and Software Analytics;
  • Software Visualization;
  • Software Reconstruction and Migration;
  • Program Repair;
  • Software Release Engineering, Continuous Integration and Delivery;
  • Software Security, Safety, Reliability and Quality Analysis;
  • Software Tools for Software Evolution and Maintenance;
  • Human factors and legal aspects in the context of Software Analysis, Evolution and Reengineering
  • Empirical studies in the context of Software Analysis, Evolution and Reengineering;
  • Education and Training in the context of Software Analysis, Evolution and Reengineering;

All papers must be full papers.

 

Papers involving AI and ML

Papers involving AI or ML must either

  • (a) concern a software system as a whole, or a subsystem, and not simply its AI or ML component
  • (b) consider software engineering artifacts
  • (c) target a novel context for a software engineering task
  • (d) study human, social, socio-technical, and organizational aspects in the development of AI- or ML-intensive software systems (see also "Scoping Software Engineering for AI: The TSE Perspective", 10.1109/TSE.2024.3470368).
Papers involving AI or ML must explicitly explain how they address a software engineering problem. Papers not meeting these criteria may be more suitable for AI- or ML-focused venues instead. Papers that do not clearly explain how they address a software engineering problem or don't meet the above criteria will be desk-rejected.

Special Issue

Authors of selected research papers accepted at SANER 2026 will be invited to submit revised, extended versions of their manuscripts for a special issue featured by Springer’s Empirical Software Engineering Journal (EMSE).

Evaluation Criteria

Research papers will be reviewed by at least three members of the Program Committee. Submissions will be evaluated based on the following criteria:

  • Originality and novelty: The extent to which the contribution is sufficiently original and is clearly explained with respect to the state-of-the-art;
  • Importance of contribution and significance: The extent to which the paper’s contributions are important with respect to open software engineering challenges, or how the paper’s contributions may impact the field of software analysis, evolution and reengineering;
  • Soundness: The extent to which the paper’s contributions are supported by rigorous application of appropriate research methods;
  • Open Science and Verifiability: The extent to which the paper includes sufficient information to support independent verification or replication of the paper’s claimed contributions;
  • Presentation: The extent to which the paper’s quality of writing meets the standards of SANER, including clear descriptions and explanations, appropriate use of the English language, absence of major ambiguity, clearly readable figures and tables, and adherence to the formatting instructions provided below.
Submission Instructions

Submitted papers must have been neither previously accepted for publication nor concurrently submitted for review in another journal, book, conference, or workshop. All submissions must come in PDF format and conform, at the time of submission, to the IEEE Conference Proceedings Formatting Guidelines (title in 24pt font and full text in 10pt font, LaTEX users must use \documentclass[10pt,conference]{IEEEtran} without including the compsoc or compsocconf option. IEEE paper templates can be accessed from their official location. Also, papers must comply with the IEEE Policy on Authorship. All submissions must be in English. Submissions should not exceed 10 pages (with 2 additional pages for references only) and should be uploaded electronically in PDF format via EasyChair

All papers must be submitted in PDF format through the web-based submission system https://easychair.org/my/conference?conf=saner2026. After clicking on “Make a New Submission,” you will be presented with a list of all available tracks. Be sure to select the correct track (i.e., Research Track).

Submissions that do not adhere to these limits or that violate the formatting guidelines will be desk-rejected without review.

 

Use of GenAI

Submissions must follow the latest “IEEE Submission and Peer Review Policy” and “ACM Policy on Authorship” (with associated FAQ, which includes a policy regarding the use of generative AI tools and technologies, such as ChatGPT.

Double-blind Review

SANER 2026 follows a full double-anonymous review process. To be compliant with the double-anonymous policy, submitted papers must adhere to the following rules (largely reused from ASE 2017 and SANER 2026 double-anonymous instructions):

  • Author names and affiliations must be omitted;
  • References to authors’ own related work must be in the third person. (For example, not We build on our previous work… but rather We build on the work of…);
  • There may be cases in which the current submission is a clear follow-up of one of your previous works, and despite what was recommended in the previous point, reviewers will associate authorship of such a previous work with the current submission. In this case, you may decide to anonymize the reference itself at submission time. For example: based on previous results [10] .. where the reference is reported as [10] Anonymous Authors. Omitted per double-blind reviewing. In doing so, however, please make sure that the SANER 2026 submission is self-contained and that its content can be reviewed and understood without accessing the previous paper;
  • Do not include acknowledgments of people, grants, organizations, etc. that would give away your identity. You may, of course, add these acknowledgments in the camera-ready version;
  • If you use an identifiable naming convention for your work, such as a project name, use a different name for your submission, which you may indicate has been changed for double-blind reviewing. This includes names that may unblind individual authors and their institutions. For example, if your project is called GoogleDeveloperHelper, which makes it clear the work was done at Google, for the submission version, use the name DeveloperHelper or BigCompanyDeveloperHelper instead;
  • Avoid revealing the institution affiliations of authors or at which the work was performed. For example, if the evaluation includes a user study conducted with undergraduates from the CS 101 class that you teach, you might say “The study participants consist of 200 students in an introductory CS course”. You can of course add the institutional information to the camera-ready. Similar suggestions apply to work conducted in specific organizations (e.g., industrial studies). In such cases, avoid mentioning the organization’s name. Instead, you may refer to the organization as Org or Company. When appropriate and when this does not help too much in revealing the company’s name, you might mention the context (e.g., financial organization, game development company, etc.);
  • Avoid linking directly to code repositories or tool deployments which can reveal your identity. Whenever possible, please use the EasyChair additional material field to submit a .zip or .tgz file including additional material. This is of course possible for small attachments. In other cases, you may post anonymized links (with a warning that the following link may reveal authors’ identities), including links to anonymized code or deployments. When creating such repositories, a good practice can be asking somebody in your team to test the anonymization of the repository and its content. If the anonymization is difficult to achieve and you still want to provide the availability of data/tools, you can simply state that you will link to the code or deployment in the camera-ready version. Program committee members are asked to keep into account the double-blind policy when reviewing papers, and therefore not require full availability of artifacts at submission time.

Submissions that do not adhere to the above guidelines will be desk-rejected without review. It is the responsibility of the authors to ensure that their papers and any supplementary material are prepared for a double-blind review.

Open Science

SANER 2026 supports an Open Science policy. We encourage all contributing authors to disclose (anonymized and curated) data/artifacts to increase reproducibility. While sharing research artifacts is not mandatory for submission or acceptance, authors should include a Data Availability statement after the Conclusions section in a section named "Data Availability". This statement should be used to:

  • To make their artifact available (via a link to an anonymous repository) and provide instructions on how to access this data in the paper; or
  • To include an explanation as to why this is not possible or desirable; and
  • To indicate why the authors do not intend to make their data or study materials publicly available upon acceptance, if that is the case.

We encourage authors to consider disclosing the source code and datasets used within their paper, including extractors, survey data, etc. By sharing this information your contribution will be more impactful because others can follow up on your work and cite it. Please consider using Zenodo, Figshare, or other services that provide DOIs and allow anonymous and semi-anonymous methods of archiving software and datasets. These datasets, anonymized through Zenodo and other services, should be linked within the paper itself. Instructions for double-blind friendly uploading of datasets are available here: https://github.com/dgraziotin/disclose-data-dbr-first-then-opendata.

Accepted Papers

All accepted papers will be included in the IEEE Digital Library as part of the SANER 2026 conference proceedings, provided that at least one author registers for SANER 2026 (full registration, not student registration) and presents the paper at the conference. Papers that are not presented will be removed from the proceedings. The authors of accepted papers are encouraged to incorporate reviewers’ comments as much as possible in the camera-ready version. After acceptance, the list of authors cannot be changed under any circumstances, and the author list in the camera-ready version must be identical to that of the submitted paper. Paper titles cannot be changed unless approved by the Program Co-Chairs, and title changes are only allowed if recommended by reviewers for clarity or accuracy.

 

 

To ensure a fair and unbiased double-blind review process, authors must comply with the following guidelines regarding the handling of non-anonymized versions. A non-anonymized version is considered any publicly available document (e.g., on arXiv) that contains essentially the same scientific content as the submitted paper, even if it differs in minor ways such as the title, paper structure or organization, length, or formatting.

Preprints Posted Before the Anonymity Period

Authors may make a non-anonymized version of their paper publicly available before the anonymity period. The anonymity period starts one month before the submission deadline and ends when the paper is accepted, rejected, or withdrawn. However, in such cases, authors are responsible for minimizing the risk that reviewers can easily link the submitted paper to a public version.

Specifically, authors must: * Take care to prevent the submitted manuscript from being associated with the non-anonymized version. * Avoid reusing distinctive phrases (e.g., title, keywords) from the submitted manuscript that would make the non-anonymized version easily discoverable via search engines. * Not update the non-anonymized version during the anonymity period. * Not actively promote the non-anonymized version (e.g., via social media, blogs, or mailing lists). * Not reference, cite, or link to the non-anonymized version within the submitted manuscript.

Post-Publication Preprint Policy (IEEE Guidelines)

Upon acceptance and publication by IEEE, authors must update any publicly available non-anonymized version in one of the following ways: * Replace it with the full IEEE citation, including the Digital Object Identifier (DOI), or * Post the accepted version of the paper (i.e., the author’s final version before IEEE formatting), along with the DOI. The IEEE-published version itself must not be posted.

IEEE will provide each author with a preprint version of the article that includes the DOI, IEEE copyright notice, and a statement confirming that the article has been accepted. Authors may post this version in accordance with IEEE’s guidelines.

For details, see: https://conferences.ieeeauthorcenter.ieee.org/get-published/post-your-paper/

Questions

If you have any questions about pre-prints for your track, please contact the relevant track chairs.