We have to face a simple, yet, disturbing fact: current computing is inherently insecure. The systems we develop and maintain have outgrown our capacity to prove them secure in every instance. Moreover, we became increasingly dependent on these systems. From small firmware running in cars and household appliances to smart phones and large-scale banking systems, software systems permeate our every day life. We rely on the safety and security of these systems, yet, we encounter threats to these properties every day.#R##N#Therefore, systems have be secure by construction and not by maintenance. The principles to achieve this are well known. The Principle of Least Privilege has been published in 1975, yet, software systems do not generally apply it. We argue that new, lightweight methods based on sound theory have to be put forward so that developers can efficiently check that their software is secure in their domain context.#R##N#In this thesis, we present three analysis techniques that help programmers develop more secure software by informing them about the current state of unsafe operation usage, extensive capability use in third-party components, and suspicious dead software paths that point to programming errors that could lead to insecurity. These three analyses inspect the full stack of a Java program from the application code over library and base-library code down to the native code level. If programmers use the information provided by the analyses, they are able to reduce the attack surface of their applications and provide more safe and secure systems to their users.#R##N#Furthermore, we contribute two concepts for automated isolation. While the first concept reduces the attack surface by slicing third-party components to their necessary parts, the second concept is more fundamental and aims at achieving a fine-grained privilege separation.#R##N#We believe that the software engineering discipline needs more research on these language-based approaches that tackle the problem of software security at its root cause: defective implementation. Using formal methods to construct these tools is necessary, yet, software developers cannot be overburdened with new requirements to their work process. Automated tools need to derive security properties from program code by them- selves with as little input required from the programmer as possible. By these means software can be developed reliably secure in an efficient fashion.
['Ben Hermann']
Full-Stack Static Security Analysis for the Java Platform