The security of an application is a continuous struggle between solid proactive controls and quality in SDLC versus human weakness and resource restrictions. As the pentester's experience confirms, unfortunatelly even in high-risk (e.g. banking) applications, developed by recognized vendors, the latter often wins - and we end up with critical vulnerabilities.
One of the primary reasons is lack of mechanisms enforcing secure code by default, as opposed to manual adding security per each function. Whenever the secure configuration is not default, there will almost inevitably be bugs, especially in complex systems.
I will pinpoint what should be taken into consideration in the architecture and design process of the application. I will show solutions that impose security in ways difficult to circumvent unintentionally by creative developers. I will also share with the audience the pentester's (=attacker's) perspective, and a few clever tricks that made the pentest
(=attack) painful, or just rendered the scenarios irrelevant.