Integrating Security into the QA Process

I just listened to the latest podcast from Rafal Los's site "Down the Rabbit Hole":
http://podcast.wh1t3rabbit.net/down-the-rabbithole-episode-3-qa-and-security-can-we-make-it-work-

On the show, they discuss integrating security testing into the QA process, which isn't terribly new, but what I got really excited about was the discussion about *how* to integrate it.  Security testing is difficult for QA teams. Security testing requires specific skill sets and knowledge.  QA teams don't know how to run automated security testing tools, have trouble interpreting the assessment results, and usually focus on testing defined requirements rather than having an open-ended mandate to look for security defects.

On the podcast, they recommend breaking security testing up and distributing it across the organization as much as possible.  Security testing should be a normal part of developing and testing software.  In regards to QA testing, define specific security tests, in a similar manner to the way functional or business requirements are tested, and provide those to the QA team.  Step by step directions, training on a particular tool (like the web developer toolbar plugin for Firefox, not necessarily a static code analysis tool), or custom scripts may be required and included in these test definitions (use templates if possible).  Link all of these security defect QA tests to functional or business requirements (this may require the organization to define new ones).  Then, add these requirements back into the software development process, so they are included during the planning, design, or coding phases.  Finally, provide secure coding standards that show step by step directions or specific code examples for accomplishing the functional or business requirements in the team's language, framework, library, or other software component.