Daily software changes present an inherent risk of introducing bugs. To understand such bugs, it is crucial to understand why specific changes introduced the bugs. This is difficult and time-consuming. We propose Divergence-Driven Debugging, an approach using a debugger for detecting execution divergences between two versions of the same program. Developers can explore both versions' execution in full and compare them based on the detected divergences. We evaluate our approach on a bug scenario and show that our debugger highlights the live state and behavior required to understand why the changes produce the bug and to identify its root cause.

Migrating large monolithic systems to service-based architecture is a complex process, mainly due to the difficulty of extracting reusable functionality from tightly coupled components. To support this, Service Identification techniques have been proposed to decompose monoliths into service candidates. Implementing these service candidates requires significant restructuring efforts. To address this complexity and build confidence in the target architecture, prior research recommends using an incremental migration approach where services are extracted one at a time. However, incremental migration has been poorly explored in the literature and lacks dedicated tool support. Thus, we explore the idea of a tool-assisted service extraction to support incremental migration, where one service is extracted at each increment. This paper first discusses the challenges associated with incremental migration. Then, it presents a model-based extraction approach aimed at automatically extracting functionality as a service. The approach is supported by a tool prototype evaluated on an industrial system and an open-source project. Our results show that our tool can extract standalone services that are successfully invoked by a reduced version of the monolith.

Nowadays, an increasing number of applications use deserialization. This technique, based on rebuilding the instance of objects from serialized byte streams, can be dangerous since it can open the application to attacks such as remote code execution (RCE) if the data to deserialize is originating from an untrusted source. Deserialization vulnerabilities are so critical that they are in OWASP’s list of top 10 security risks for web applications. This is mainly caused by faults in the development process of applications and by flaws in their dependencies, i.e., flaws in the libraries used by these applications. No previous work has studied deserialization attacks in-depth: How are they performed? How are weaknesses introduced and patched? And for how long are vulnerabilities present in the codebase? To yield a deeper understanding of this important kind of vulnerability, we perform two main analyses: one on attack gadgets, i.e., exploitable pieces of code, present in Java libraries, and one on vulnerabilities present in Java applications. For the first analysis, we conduct an exploratory large-scale study by running 256515 experiments in which we vary the versions of libraries for each of the 19 publicly available exploits. Such attacks rely on a combination of gadgets present in one or multiple Java libraries. A gadget is a method which is using objects or fields that can be attacker-controlled. Our goal is to precisely identify library versions containing gadgets and to understand how gadgets have been introduced and how they have been patched. We observe that the modification of one innocent-looking detail in a class – such as making it public – can already introduce a gadget. Furthermore, we noticed that among the studied libraries, 37.5% are not patched, leaving gadgets available for future attacks. For the second analysis, we manually analyze 104 deserialization vulnerabilities CVEs to understand how vulnerabilities are introduced and patched in real-life Java applications. Results indicate that the vulnerabilities are not always completely patched or that a workaround solution is proposed. With a workaround solution, applications are still vulnerable since the code itself is unchanged.