What you might find interesting about the article are the descriptions of the types of vulnerabilities we routinely identify and the odd situations we encounter when doing so. For example when vulnerabilities spontaneously open and close from scan to scan or when they reopen months later for no apparent reason. Overall Simson did a really good job highlighting the more important aspects of the field in an easy to understand way that CIOs can digest. Then this quote really made my day:

"I’ve never been a big fan of penetration testing, but the two hours that I spent talking with Grossman convinced me that it’s a necessary part of today’s e-commerce websites. Yes, it would be nice to eliminate these well-known bugs with better coding practices. But we live in the real world. It’s better to look for the bugs and fix them than to simply cross your fingers and hope that they aren’t there."

penetration testing is cool, but rather trying to discover these bugs when the application is completed i think it is better to anticipate the bugs throughout the whole dev process and most important when conducting threat modeling in the beginning

alik levin, thanks for the comment and generally I agree with the process when building any new web applications. However, please consider the following:

1) Not all vulnerabilities in production first existed in development (forced browser, config issues, hot fixes, etc.) and its highly unlikely for ANY developer to write bug free code. Best test production before the bad buys do because they will no matter what.

2) The VAST majority of web applications in existence have already been built and deployed without the process you described. Its unlikely that they'll be re-coded from scratch within the next 10 years using this process. More likely we'll get more code and additional complexity. One benefit of vulnerability assessment is we can measure the security of existing websites and fix what issues we can, however we can.

To be clear though, my advocacy of vulnerability assessment does not conflict or replace a solid SDLC.

At a high level we can make just about anything appear simple. Its only when we get into the nitty gritty details of say SDLC, VA, Business Process, Compliance, Best Practices, Ajax, do things become somewhat complicated. :)