Matt's written an interesting article sharing his experience "from the coal face" gained during years of exerience advising the military and leading companies in writing more secure software. I share Matt's view that it's far less expensive to fix security at the inital development stage rather than to retro-fit it. IMHO there are direct parallels with the cost of changing functionality once the code is complete - clearly it's a nightmare if your customer mandates a change during acceptance testing!
This article is not purely for the attention of developers though. Matt's informal style lends itself well to informing business and IT Professionals in the reasons WHY much code is inherently insecure - just blaming the dev guys(and gals!) isn't fair. For security to be effective it has to be part of the culture of all involved, from the end user through to implementation team, operations and development. Just think about it for a moment, if the user is asked a "security question" by the application but not given enough information (in their terms) to make a sensible decision then it's hardly surprising if they make a bad choice.
Something that I know Matt's passionate about is incorporating assessment of code security at user acceptance testing and indeed specifing it at the functional definition stage too. Personally I think this is essential - consumers have the right to expect code to be secure BUT they should be able to clearly state what they mean by "secure" and therefore enable the developers to incorporate the appropriate security controls to mitigate the expressed risk.
Err, aren't your chart axes' labels reversed? In other words shouldn't 'Design', 'Build', 'Deploy' be going along the time axis, with the exponentially increasing cost being in the upwards direction??
Tony> Thank you for pointing that out - D'oh! What did you make of the article itself?