No matter how good programmers get at making secure software, it will never be perfect—we will always have to contend with incomplete or inadequate code. Most efforts at living with bad code have focused on shoring it up from the outside: limiting network access or watching for suspicious behavior. This session takes a different perspective, it looks at methods for identifying and blunting the effects of software shortcomings from the inside by watching the software run. For some years now we've focused on eliminating well-known classes of defects such as SQL injection and cross-site scripting. This is a battle worth fighting, and there are big benefits to eliminating defects early, but we will never be able to make perfect software. Instead we must build software that allows us to compensate for defects after the fact. On the cloud computing front, much of the energy around security in the cloud has gone towards either figuring out how cloud customers and cloud vendors can trust each other, or finding ways to deliver security as a service in the cloud. The more interesting challenges come from a less explored topic: creating code that's ready for the cloud. The usual suspects (SQL injection and XSS) are uglier in the cloud because it's harder to defend against them with network devices, but more generally cloud-ready code needs to take its security with it wherever it goes. This puts additional emphasis on some old refrains (eliminate defects early) and creates new emphasis on creating software that's able to defend itself.
