We are happy to announce, that a paper on our new algorithm for demand-driven context- and flow-sensitive points-to analysis, called Boomerang, has been accepted at the ECOOP 2016 conference. Download the paper here.

Boomerang is the first points-to analysis algorithm which on demand delivers in addition to computing points-to sets also the reverse information. Along with an allocation site, the analysis delivers all possible pointers in the current scope which point-to that particular allocation site. This feature is crucial for state-of-the-art clients such as taint and typestate analysis. On top of that, Boomerang enables client-driven context-resolution: The client can limit the search scope for the points-to analysis to the methods of interest.

For the evaluation we introduce PointerBench, the first benchmark suite to evaluate precision and soundness of points-to analyses. We hope for contributions to further enhance the benchmark suite and make points-to analyses comparable more easily.

Boomerang also received the artifact evaluation award.

Today Steven Arzt and Eric Bodden are releasing a Technical Report on Reviser, our novel tool for automatically and Efficiently updating IDE-based data-flow analyses in response to incremental program changes. I think the title pretty much speaks for itself. Reviser is available as an open-source extension to Heros. Enjoy!

On Wednesday I will be presenting an invited paper which I wrote together with Ben Hermann, Johannes Lerch and Mira Mezini for a special session at this year’s Future Security Conference. In this work, we give a retrospective survey about the different software security architectures that come with common current programming-language runtimes.The more we learned about these models the less it came as a surprise to us that the world is now seeing the problems and vulnerabilities that it is seeing. In retrospect it is often simple to blame “stupid developers” for including a programming mistake that leads to an exploitable vulnerability. In practice, however, this is just a too simple answer. To truly understand what causes the inclusion of such code one must understand the development history of the respective projects, the organizational structure in which development happens and also the number of constraints a developer has to keep in mind to avoid such mistakes. We argue that, at first, simpler security models are preferable because in such models mistakes are less likely to occur. The trick is then to retain a security model that is restrictive enough. We discuss object capabilities as one mechanism to support models that can be relatively expressive and maintainable at the same time.

Reducing human factors in software security architectures
In the recent past it has become clear that there are inherent problems with the security models of popular programming platforms such as Java, Android, and so forth. In this work we pinpoint sources of those problems, and explain the relative strengths and weaknesses of the security models for C/C++, Java, .NET, Android and JavaScript. As it turns out, many problems are caused by the fact that the models are so complex that they overstrain not only end-users but even expert developers. Out of this experience we argue that a new line of security models, based on object-capabilities, can help reduce the inherent complexity, preparing the ground for software that is secure by design.