Secure code review process: How many review rounds are needed?

I see other departments at my company (e.g., marketing writing copy) go through several different revision cycles to review new projects, but when it comes to writing secure code, the programmers usually just release it when it works and worry about security later. How can I advocate for a secure code review process, and how many layers of review do you think are necessary to release secure code?

 

Humans are visual creatures and what users -- and the boss -- all see when they look at a website is the work of the graphic design team and their interpretation of the marketing and sales departments' brief. This is why those departments are allowed countless revisions, and usually larger budgets, than those responsible for security. They also tend to have more influence over what goes into a website and rarely allow security to compromise its look and feel because nobody sees security.
The benefits of good security only come into effect once the site is live and the design team is off on its next assignment; the costs of remediating a software security flaw often fall to the operations team, not development. Even then, it's a lot harder to assign any monetary value to security in the way the effects of a new online marketing campaign can be tracked by the hour using Web analytics and goal conversion results.
Arguing for more secure coding practices can be hard, particularly as many well-known sites have been hacked due to vulnerabilities in their design with seemingly little damage dealt to their public popularity. There are some cases you can refer to that can highlight why security is important. For example, DigiNotar was a Dutch certificate authority that was forced into bankruptcy when it was discovered a security breach allowed attackers to issue fraudulent certificates. Perhaps a more persuasive argument would be the increasing number of laws and penalties that come into play if a data breach results in data being compromised.
U.S. health insurance company BlueCross BlueShield of Tennessee is being fined $1.5 million for a data breach in 2009 that violated the HIPPA Security Rule and Health Information Technology for Economic and Clinical Health (HITECH) breach notification requirements. This fine comes on top of the $17 million the company has already spent on investigation, notification and protection. Sony's European arm has been fined $390,000 following the hacking of its PlayStation Network online database. Could your organization survive this type of fine or the cost of cleaning up after a similarly devastating data breach?
Stories like this (and real monetary values of the losses that resulted) get the attention of senior managers. Your goal should be to persuade them to adopt the Simplified Implementation of the Microsoft Security Development Lifecycle (SDL). This is a version of their widely adopted SDL aimed at development projects with limited resources. It will help make security and privacy a priority throughout all phases of the development process, with many of the associated tools, such as threat modeling tools and vulnerability scanners, being either free or open source. The Microsoft SDL will also show when and how to review code prior to its release.
The threat modeling exercise will identify potential security issues and components of the application that should be subjected to closer inspection. By finding the areas that have the most potential to introduce vulnerabilities early in a project's lifecycle, the organization can take ownership of them while they are relatively easy and cost-effective to resolve. You can also introduce a Model-View-Controller development framework, which splits application development into three distinct spheres so projects can move forward without different teams delaying each other, hopefully reducing the frustration of those not used to building secure applications.
Finally, I would aim to have a senior manager responsible for signing off on the successful completion of each security requirement, and have the appropriate developers included in the incident response plan should vulnerabilities come to light once the application is released. This is always an effective incentive to ensure everyone focuses on writing secure code the first time around.