Modern applications often rely on rich frameworks to provide functionality. Android, for instance, handles many aspects of building a mobile app. But these frameworks also have costs. Given the importance of application security and tools to ensure it, one major cost is that framework complicate tools based on static analysis: (1) They hurt analysis quality by including large amounts of complex, dynamic, and native library code. (2) Frameworks like Android become the main program, making whole program analysis of the app problematic.Mechanisms such as Averroes have been developed to handle unknown library code for Java, and have proven effective for some analyses. However, they have two main limitations in the context of our complications: (1) They do not provide the precision required for security analysis. (2) They assume a main program, which is not the case for frameworks. To address this, we present GenCG, which extends Averroes to support taint analysis for Android and Spring. Evaluation with real-world Android applications shows that call graphs using the models generated by GenCG cover significantly more code of the app, improves recall of a client security analysis, and, at the same time, does not introduce more false positives.

As an alternative to Java, Kotlin has gained rapid popularity since its introduction and has become the default choice for developing Android apps. However, due to its inter-operability with Java, Kotlin programs may contain almost the same security vulnerabilities as their Java counterparts. Hence, we question: to what extent can one use an existing Java static taint analysis on Kotlin code? In this paper, we investigate the challenges in implementing a taint analysis for Kotlin compared to Java. To answer this question, we performed an exploratory study where each Kotlin construct was examined and compared to its Java equivalent. We identified 18 engineering challenges that static-analysis writers need to handle differently due to Kotlin's unique constructs or the differences in the generated bytecode between the Kotlin and Java compilers. For eight of them, we provide a conceptual solution, while six of those we implemented as part of SECUCHECK-KOTLIN, an extension to the existing Java taint analysis Secucheck.

Due to its ability to detect many frequently occurring security vulnerabilities, taint analysis is one of the core static analyses used by many static application security testing (SAST) tools. Previous studies have identified issues that software developers face with SAST tools. This paper reports on our experience in building a configurable taint analysis tool, named SecuCheck, that runs in multiple integrated development environments. SecuCheck is built on top of multiple existing components and comes with a Java-internal domain-specific language fluentTQL for specifying taint-flows, designed for software developers. We evaluate the applicability of SecuCheck in detecting eleven taint-style vulnerabilities in microbench programs and three real-world Java applications with known vulnerabilities. Empirically, we identify factors that impact the runtime of SecuCheck.