This is a great scenario that I’m sure happens everywhere (yes, everywhere):
…if you go to the development organization and ask about software security they will immediately refer you to the network security people. “We have a department for that security stuff,” they say while ushering you out the door. But when you make your way to the network security department and ask them about software security, they say something like, “Yeah, those developers really should produce code that doesn’t suck. Those guys ruin our perfectly configured network with their broken applications.”
He also throws this gem in:
To make perfectly clear that this is a management issue, ask yourself who gets fired when your firm experiences a software security problem? Who gets rewarded when your firm does a good job with software security? If the answer is “nobody,” then you have a real problem.
The only downside to this set of data and underlying conclusion can be exposed in the last few paragraphs of the article: the size of the companies McGraw deals with are probably pretty large. In other words, they have the opportunity for real security groups. I’d wager a vast majority of firms don’t have that freedom (or budget), and have to make do with, at best, part-time security. Sadly, this either comes in the form of small, annual security tests after the real work is done, or some unlucky bloke’s duties which are shared with his day-to-day tasks and projects. And we all know which half of those duties he will be pressured to do first. (Let alone the arguably expert-level amount of knowledge one needs…)
Even deeper than this being a management issue, this is an issue of how important security is. If it is important, then management will maybe properly do it. If it is not important, then you better just hope you are a big enough org to create a dedicated group for it.