Previous work has shown that early resolution of issues detected by static code analyzers can prevent major costs later on. However, developers often ignore such issues for two main reasons. First, many issues should be interpreted to determine if they correspond to actual flaws in the program. Second, static analyzers often do not present the issues in a way that is actionable. To address these problems, we present Sorald: a novel system that uses metaprogramming templates to transform the abstract syntax trees of programs and suggests fixes for static analysis warnings. Thus, the burden on the developer is reduced from interpreting and fixing static issues, to inspecting and approving full fledged solutions. Sorald fixes violations of 10 rules from SonarJava, one of the most widely used static analyzers for Java. We evaluate Sorald on a dataset of 161 popular repositories on Github. Our analysis shows the effectiveness of Sorald as it fixes 65% (852/1,307) of the violations that meets the repair preconditions. Overall, our experiments show it is possible to automatically fix notable violations of the static analysis rules produced by the state-of-the-art static analyzer SonarJava.

Hyrum's law states a common observation in the software industry: "With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody". Meanwhile, recent research results seem to contradict this observation when they state that "for most APIs, there is a small number of features that are actually used". In this work, we perform a large scale empirical study of client-API relationships in the Maven ecosystem, in order to investigate this seeming paradox between the observations in industry and the research literature. We study the 94 most popular libraries in Maven Central, as well as the 829,410 client artifacts that declare a dependency to these libraries and that are available in Maven Central, summing up to 2.2M dependencies. Our analysis indicates the existence of a wide spectrum of API usages, with enough clients, most API types end up being used at least once. Our second key observation is that, for all libraries, there is a small set of API types that are used by the vast majority of its clients. The practical consequences of this study are two-fold: (i) it is possible for API maintainers to find an essential part of their API on which they can focus their efforts; (ii) API developers should limit the public API elements to the set of features for which they are ready to have users. (C) 2021 The Author(s). Published by Elsevier Inc.

Software bloat is code that is packaged in an application but is actually not necessary to run the application. The presence of software bloat is an issue for security, for performance, and for maintenance. In this paper, we introduce a novel technique for debloating, which we call coverage-based debloating. We implement the technique for one single language: Java bytecode. We leverage a combination of state-of-the-art Java bytecode coverage tools to precisely capture what parts of a project and its dependencies are used when running with a specific workload. Then, we automatically remove the parts that are not covered, in order to generate a debloated version of the project. We succeed to debloat 211 library versions from a dataset of 94 unique  open-source Java libraries. The debloated versions are syntactically correct and preserve their original behavior according to the workload. Our results indicate that 68.3% of the libraries’ bytecode and 20.3% of their total dependencies can be removed through coverage-based debloating.

For the first time in the literature on software debloating, we assess the utility of debloated libraries with respect to client applications that reuse them. We select 988 client projects that either have a direct reference to the debloated library in their source code or which test suite covers at least one class of the libraries that we debloat. Our results show that 81.5% of the clients, with at least one test that uses the library, successfully compile and pass their test suite when the original library is replaced by its debloated version.

Thanks to the emergence of package managers and online software repositories, modern software development heavily relies on the reuse of third-party libraries. This practice has significant benefits in terms of productivity and reliability. Yet, the reuse of software libraries leads large groups of applications to share a significant amount of code, including potential defects such as bugs or vulnerabilities. The lack of diversity in these group of applications make them more prone to large-scale failures, and more predictable for attackers attempting to exploit their shared vulnerabilities.To mitigate these risks opened by library reuse, this dissertation proposes to introduce diversity in software applications.We create variants of software applications through transformations targeting the libraries they depend on. These variants provide functionalities equivalent to their original, while not sharing the exact same behavior.

In this dissertation, we cover three aspects of software diversity.First, we study the existing behavioral diversity of alternative libraries implementing similar functionalities.We perform two case studies on two families of reusable software artifacts: JSON libraries and Bytecode decompilers. We provide empirical evidence that both groups of artifacts exhibit significant natural input/output behavioral diversity.

Second, we study software transformations targeting libraries themselves. We propose six source-to-source transformations targeting software libraries, as well as a general architecture to implement library substitution. We implement this architecture in a JSON library substitution framework, leveraging the diversity of behavior we observe in JSON libraries. We assess the impact of these transformations on open-source libraries and software applications through two experiments.

Finally, we study the properties of software applications and libraries that make them prone to transformation without changing their functionalities. We analyze the variants produced during our software diversification experiments and discuss our findings. In particular, we observe that the existence of alternative implementations at different granularity, instructions, methods, classes, and libraries, provides an important source of potential diversity that can be leveraged.

Tack vare uppkomsten av pakethanterare och mjukvaruförråd på nätet ärmodern programvaruutveckling i hög grad beroende av återanvändning avbibliotek från tredje part. Denna praxis har betydande fördelar när det gällerproduktivitet och tillförlitlighet. Återanvändning av programvarubibliotek iett stort antal program leder dock till att dessa program delar en betydandemängd kod, inklusive potentiella fel som buggar och sårbarheter. Omprogramvarudefekter delas i stor utsträckning uppstår en risk för storskaligafel. Dessutom ökar risken för att samma sårbarhet kan användas mot fleraprogram med samma tredje-partsbibliotek. För att minska riskerna medåteranvändning av bibliotek föreslås i denna avhandling att man skaparvarianter av programvaror genom omvandlingar som är inriktade på debibliotek programvarorna är beroende av.I denna avhandling täcker vi tre aspekter av mjukvarumångfald. Förststuderar vi den befintliga beteendemässiga mångfalden hos alternativabibliotek som implementerar likvärdig funktionalitet. Vi genomför tvåfallstudier av två familjer av återanvändbar mjukvara: JSON-bibliotek ochBytecode-dekompilatorer. Vi ger empiriska bevis för att båda grupperna avmjukvara uppvisar en betydande beteendemässig mångfald när det gällerinput/output.Den andra aspekten som vi studerar är programvaruomvandlingarinriktade på själva biblioteken. Vi föreslår sex omvandlingar från källkodtill källkod inriktade på mjukvarubibliotek, samt en generell arkitektur föratt genomföra ersättningar av hela bibliotek. Vi tillämpar denna arkitekturi ett ramverk för att ersätta JSON-bibliotek och utnyttjar den mångfaldav beteenden som vi observerar i dessa. Vi bedömer effekterna av dessaomvandlingar på bibliotek och program med öppen källkod genom tvåexperiment.Slutligen studerar vi de egenskaper hos programvara och bibliotek somgör att de lämpar sig för omvandling utan att deras funktionalitet ändras.Vi analyserar de varianter som produceras under våra mjukvarudiversifieringsexperiment och diskuterar våra resultat. Vi konstaterar särskilt att förekomsten av alternativa implementeringar i olika skala, instruktioner, metoder,klasser och bibliotek, utgör en viktig källa till potentiell mångfald som kanutnyttjas.

Build automation tools and package managers have a profound influence on software development. They facilitate the reuse of third-party libraries, support a clear separation between the application's code and its external dependencies, and automate several software development tasks. However, the wide adoption of these tools introduces new challenges related to dependency management. In this paper, we propose an original study of one such challenge: the emergence of bloated dependencies. Bloated dependencies are libraries that are packaged with the application's compiled code but that are actually not necessary to build and run the application. They artificially grow the size of the built binary and increase maintenance effort. We propose DepClean, a tool to determine the presence of bloated dependencies in Maven artifacts. We analyze 9,639 Java artifacts hosted on Maven Central, which include a total of 723,444 dependency relationships. Our key result is as follows: 2.7% of the dependencies directly declared are bloated, 15.4% of the inherited dependencies are bloated, and 57% of the transitive dependencies of the studied artifacts are bloated. In other words, it is feasible to reduce the number of dependencies of Maven artifacts to 1/4 of its current count. Our qualitative assessment with 30 notable open-source projects indicates that developers pay attention to their dependencies when they are notified of the problem. They are willing to remove bloated dependencies: 21/26 answered pull requests were accepted and merged by developers, removing 140 dependencies in total: 75 direct and 65 transitive.

Despite its obvious benefits, the increased adoption of package managers to automate the reuse of libraries has opened the door to a new class of hazards: supply chain attacks. By injecting malicious code in one library, an attacker may compromise all instances of all applications that depend on the library. To mitigate the impact of supply chain attacks, we propose the concept of Library Substitution Framework. This novel concept leverages one key observation: when an application depends on a library, it is very likely that there exists other libraries that provide similar features. The key objective of Library Substitution Framework is to enable the developers of an application to harness this diversity of libraries in their supply chain. The framework lets them generate a population of application variants, each depending on a different alternative library that provides similar functionalities. To investigate the relevance of this concept, we develop ARGO, a proof-of-concept implementation of this framework that harnesses the diversity of JSON suppliers. We study the feasibility of library substitution and its impact on a set of 368 clients. Our empirical results show that for 195 of the 368 java applications tested, we can substitute the original JSON library used by the client by at least 15 other JSON libraries without modifying the client's code. These results show the capacity of a Library Substitution Framework to diversify the supply chain of the client applications of the libraries it targets.

JSON is an essential file and data format in domains that span scientific computing, web APIs or configuration management. Its popularity has motivated significant software development effort to build multiple libraries to process JSON data. Previous studies focus on performance comparison among these libraries and lack a software engineering perspective. We present the first systematic analysis and comparison of the input / output behavior of 20 JSON libraries, in a single software ecosystem: Java/Maven. We assess behavior diversity by running each library against a curated set of 473 JSON files, including both well-formed and ill-formed files. The main design differences, which influence the behavior of the libraries, relate to the choice of data structure to represent JSON objects and to the encoding of numbers. We observe a remarkable behavioral diversity with ill-formed files, or corner cases such as large numbers or duplicate data. Our unique behavioral assessment of JSON libraries paves the way for a robust processing of ill-formed files, through a multi-version architecture.

During compilation from Java source code to bytecode, some information is irreversibly lost. In other words, compilation and decompilation of Java code is not symmetric. Consequently, decompilation, which aims at producing source code from bytecode, relies on strategies to reconstruct the information that has been lost. Different Java decompilers use distinct strategies to achieve proper decompilation. In this work, we hypothesize that the diverse ways in which bytecode can be decompiled has a direct impact on the quality of the source code produced by decompilers. In this paper, we assess the strategies of eight Java decompilers with respect to three quality indicators: syntactic correctness, syntactic distortion and semantic equivalence modulo inputs. Our results show that no single modern decompiler is able to correctly handle the variety of bytecode structures coming from real-world programs. The highest ranking decompiler in this study produces syntactically correct, and semantically equivalent code output for 84%, respectively 78%, of the classes in our dataset. Our results demonstrate that each decompiler correctly handles a different set of bytecode classes. We propose a new decompiler called Arlecchino that leverages the diversity of existing decompilers. To do so, we merge partial decompilation into a new one based on compilation errors. Arlecchino handles 37.6% of bytecode classes that were previously handled by no decompiler. We publish the sources of this new bytecode decompiler. (C) 2020 Published by Elsevier Inc.

Neutral program variants are alternative implementations of a program, yet equivalent with respect to the test suite. Techniques such as approximate computing or genetic improvement share the intuition that potential for enhancements lies in these acceptable behavioral differences (e.g., enhanced performance or reliability). Yet, the automatic synthesis of neutral program variants, through program transformations remains a key challenge. This work aims at characterizing plastic code regions in Java programs, i.e., the code regions that are modifiable while maintaining functional correctness, according to a test suite. Our empirical study relies on automatic variations of 6 real-world Java programs. First, we transform these programs with three state-of-the-art program transformations: add, replace and delete statements. We get a pool of 23,445 neutral variants, from which we gather the following novel insights: developers naturally write code that supports fine-grain behavioral changes; statement deletion is a surprisingly effective program transformation; high-level design decisions, such as the choice of a data structure, are natural points that can evolve while keeping functionality. Second, we design 3 novel program transformations, targeted at specific plastic regions. New experiments reveal that respectively 60%, 58% and 73% of the synthesized variants (175,688 in total) are neutral and exhibit execution traces that are different from the original.

Maven artifacts are immutable: an artifact that is uploaded on Maven Central cannot be removed nor modified. The only way for developers to upgrade their library is to releasea new version. Consequently, Maven Central accumulates all the versions of all the libraries that are published there, and applications that declare a dependency towards a library can pick any version. In this work, we hypothesize that the immutability of Maven artifacts and the ability to choose any version naturally support the emergence of software diversity within Maven Central. We analyze 1,487,956 artifacts that represent all the versions of 73,653 libraries. We observe that more than 30% of libraries have multiple versions that are actively used by latest artifacts. In the case of popular libraries, more than 50% of their versions are used. We also observe that more than 17% of libraries have several versions that are significantly more used than the other versions. Our results indicate that the immutability of artifacts in Maven Central does support a sustained level of diversity among versions of libraries in the repository.