Recent research has shown that developers hesitate to update dependencies and mistrust automated approaches such as Dependabot, since they are afraid of introducing incompatibilities that break their project. In fact, such approaches only suggest naïve updates for a single outdated library but do not ensure compatibility with other dependent libraries in the project. To alleviate this situation and support developers in finding updates with minimal incompatibilities, we present UPCY. UPCY applies the min-(s,t)-cut algorithm and leverages a graph database of Maven Central to identify a list of valid update steps to update a dependency to a target version while minimizing incompatibilities with other libraries. By executing 29,698 updates in 380 projects, we compare the effectiveness of UPCY with the naïve updates applied by state-of-the-art tools. We find that in 41.1% of the cases where the naïve approach fails UPCY generates updates with fewer incompatibilities, and even 70.1% of the generated updates have zero incompatibilities.

The use of vulnerable open-source dependencies is a known problem in today's software development. Several vulnerability scanners to detect known-vulnerable dependencies appeared in the last decade, however, there exists no case study investigating the impact of development practices, e.g., forking, patching, re-bundling, on their performance. This paper studies (i) types of modifications that may affect vulnerable open-source dependencies and (ii) their impact on the performance of vulnerability scanners. Through an empirical study on 7,024 Java projects developed atSAP, we identified four types of modifications: re-compilation, re-bundling, metadata-removal and re-packaging. In particular, we found that more than 87 percent (56 percent, resp.) of the vulnerable Java classes considered occur in Maven Central in re-bundled (re-packaged, resp.) form. We assessed the impact of these modifications on the performance of the open-source vulnerability scanners OWASP Dependency-Check (OWASP) and Eclipse Steady, GitHub Security Alerts, and three commercial scanners. The results show that none of the scanners is able to handle all the types of modifications identified. Finally, we presentAchilles, a novel test suite with 2,505 test cases that allow replicating the modifications on open-source dependencies.

With version 9, Java has been given the new module system Jigsaw. Major goals were to simplify maintainability of the JDK and improve its security by encapsulating modules' internal types. While the module system successfully limits the visibility of internal types, it does not prevent sensitive data from escaping. Since the module system reasons about types only, objects are allowed to escape even if that module declares the type as internal. Finding such unintended escapes is important, as they may violate a module's integrity and confidentiality, but is a complex task as it requires one to reason about pointers and type hierarchy. We thus present ModGuard, a novel static analysis based on Doop which complements the Java module system with an analysis to automatically identify instances that escape their declaring module. Along with ModGuard we contribute a complete formal definition of a module's entrypoints, i.e., the method implementations that a module actually allows other modules to directly invoke. We further make available a novel micro-benchmark suite MIC9Bench to show the effectiveness but also current shortcomings of ModGuard, and to enable comparative studies in the future. Finally, we describe a case study that we conducted using Apache Tomcat, which shows that a migration of applications towards Jigsaw modules does not prevent sensitive instances from escaping, yet also shows that ModGuard is an effective aid in identifying integrity and confidentiality violations of sensitive instances.