I have just published the following article on handling application security defects (vulnerabilities) in development and QA.

"If you've worked in information security you've likely had to report a security defect to development in an effort to  remediate the issue. Depending on your organization and its culture this can be a rather difficult task. As an information security professional it is your job to detect, communicate, and see to the remediation of such issues in your company as these issues are discovered. Likely development is saying that they're to busy to fix the issue and that if they try fixing it they'll miss the deadline for their release, resulting in their group getting penalized (sometimes bonuses are tied to release cycles) or getting a negative comment on their performance review. In other situations development may just be stubborn requiring full proof of concept code before taking your security defect seriously. Development may even refer to infosec as a group that impedes progress by throwing bugs into the grinding gears of a given software release.

As an infosec professional you may feel at times helpless, or unable to do your job successfully due to the actions and stances of other groups. If you're currently in this situation there are a few things that you can do to get development either on the same page as you, or at least in agreement to the handling of these issues when they inevitably creep up."

Setting the appropriate security defect handling expectations in development and QA
http://www.qasec.com/2009/06/setting-the-appropriate-security-defect-handling-expectations-in-development-and-qa.html

If you haven't seen 'QASec.com' before it's another website of mine where I post about application security, and vulnerability remediation in the real world (no vendor posts/viewpoints here). I haven't been posting to it that frequently but expect additional updates in the upcoming months.