Have I mentioned how much inspiration for these posts I get from you guys and gals, the readers? Well, this post is entirely based off of a comment on one of my previous posts, "The Infinite Feedback Loop" made by Jeff Kirsch.
Jeff makes mention of an interesting paradigm... there really are two distinct types of development organizations. The first is a software shop which churns out software as a business, and the second is a business that just happens to write software (applications) for itself.
You'd probably assume that fundamentally these two would behave entirely differently when it came to software security, and assuring the integrity and resiliency of their code... right? If so, you'd be surprised, here's why.
The Two Dev Houses
Let's look at how these two organizations function, what drives them and how they survive. We'll look at a few key factors including business model, motivation, and 'security drivers'.
Casual Dev Org
- Business Model - Organization produces software to support the business, but does not depend solely on producing software. Software produced in-house is a business enabler and must be done to specification, delivered on time, and on budget.
- Motivation - Use technology (software) to create a competitive advantage for the business, enabling it to deliver faster, less expensive and more efficiently the products/services that are at the core of the business model.
- Security Drivers - Primarily compliance, also customer pressures (internal & external)
Dedicated Dev House
- Business Model - Organization develops and markets software (applications) for their customers as a core business function. Software development is the business model therefore it must be done to specification, delivered on time, and on budget.
- Motivation - Produce software (applications) quickly, minimize project costs and timelines enabling faster development/release and enabling the organization to take on more business.
- Security Drivers - Customer-driven when defined as a requirement.
The Dirty Little Secret
Here's a secret. Neither of these organizations generally see security as a competitive differentiator... so they don't have it as a core requirement in development processes.
Security becomes a requirement when it is requested, but it generally slows down development, adds cost, and increases test time... so it is not seen as a general practice.
In fact... the dedicated dev house has an incentive not to have security as a core requirement... why?
Simple - they want to churn out code/projects faster, and it's a rare thing to see a customer say "your code is less secure, so I'm going to pay more, and wait longer for more secure code from your competitor".
There we have the crux of the issue. Cost. Security is still a cost. Until customers demand secure software and are willing to wait just a little longer, and pay just a little more - it's not going to be a core requirement... anywhere.
We're going to be stuck finding bugs and patching, dropping WAFs into place to cover 'unfixable bugs', and complaining that business doesn't take security seriously.
So there needs to be a catalyst to make this fundamental shift happen. What is that catalyst ...any ideas?
Cross-posted from Following the White Rabbit