They knew that every day shaved off their anticipated time-to-release schedule meant approximately an additional $1,000,000 in profits to the business unit. But they had not considered the actual and realized costs if the product had a lot of security vulnerabilities that were discovered after release.
Once they did that risk analysis, they realized they would have very high remediation and patch costs, in fact, these costs dwarfed the million dollars/day savings they hoped to gain by shaving time off their product development lifecycle.
For the next release, they integrated security into their SDLC after sending one third of their developers through training. The result was that it added just six days to their release cycle (a “loss” of $6,000,000), but they had 14 fewer high-severity security defects (a savings estimated at $98,000,000 based on their historical costs.) And the $98M number ignored any impact to stock price.
In the following release of their product, they were only +1 in their time-to-market estimates and once again experienced a drop in number of security defects reports. An interesting side bar is their developers were coding about 20% fewer security defects per release, but their development and test teams were finding 85% more defect pre-release. That is a fix-find rate any team would be happy with.
Second Verse Same as the First
Security is just another aspect of software quality. Applying the same concepts and disciplines as designing for reliability and performance will work here too. You will suffer a short-term investment for a long-term gain.
Your customers are demanding secure products, so why not embrace this non-negotiable business driver as a necessary activity? Run the numbers for yourself and determine your total cost and the risks associated with introducing new activities into your development process.
So, what is a good balance between overwhelming your team with an entirely new security process and introducing new activities to help you minimize the impact of security defects in your software? An effective development process assumes that code will be attacked and embeds some kind of assessment at each phase as a health check.
Here are some keys to getting traction in your organization:
There is no short-cut to building more secure software, but there is a way to view the cost and risk of insecure software that helps you justify additional time and dollar investment.
Specifically, look at security activities that track and identify risks, activities like code reviews, threat modeling, and secure requirements analysis. These present ways to view tangible and “predictable” consequences of insecure software and identify “hidden costs” that often escape notice.
Security is very difficult (and too risky) to bolt in after the fact. (See misconception number one in this series: Over Relying on Network Defenses .) Many companies maintain the philosophy that to have secure applications they need a separate security team or they need to redefine their entire SDLC. Neither is true. Start light, but before you start at all, run the risk numbers and determine for yourself how important secure software is to your organization.
In the coming weeks look for more expanded articles from Ed Adams covering each of these themes: Over-relying on Network Defenses, Believing the Hype of Technology/Tools, Too Many People Assumptions, Assuming Secure Software is Costly, and Falling into the “Recency” Trap.
Ed Adams is CEO of Security Innovation, an independent provider of application security services that include security testing and training.