[mcguire]

In about 2008 I started working for SAIC, on a contract to NASA's "Enterprise Applications Competency Center". While I was waiting for my computer and all the accounts and permissions to get set up, I was sent to do a code review for a minor application written in Flash/Flex/ActionScript + Java as was popular at the time, written by one guy. Everything looked pretty decent to me, except that he'd done all of the authentication/authorization in the Flash frontend. I pointed out that anyone who could connect to the app and fake the protocol could do anything the app could do, at a minimum. He said yeah, he'd have to do something about that. It went into production the next week. He's now part of the architecture/"engineering" group.

All of the things you mention are great, but they don't really address the problem. You need developers who know what the issues are and are willing to do the work to fix them even though they don't add anything to the feature list. In my experience, I don't have much reason to believe that today's developers are any better about that than yesterday's. There is a lot of security cargo-culting going on, which probably does improve the situation, but there's also a lot of "bootcamp" developers without the background to know that there are issues.

[salawat]

First thing I have a group of developers do in a new context is learn the existing business process without automating or writing a line of code. They can dissect, name, and research any code they want generated by who they are to build for, but no writing until they get the business context.

You'll never build a better tool than the one that eases your own pain. Make the user's pain your own, and beautiful things happen.