Application security

Why you should build security into your system, rather than bolt it on

Carbon monoxide is colorless, odorless and tasteless. You don’t even know it’s there until it kills you. 

You may be facing your own silent killer: your delay. When you postpone security until later in the software development process, that delay costs you enormously in both obvious and unexpected ways.

I get it: you need to develop and release as fast as possible. There’s enormous pressure to hit milestone dates. The reality, though, is that security really can’t wait. Security is part of what makes a product viable — your customers expect your software system to be secure, and if you fail to deliver on that, you fail your customers. It also costs more and creates massive headaches if you postpone it.

Download Ted's free ebook, "How to secure your software faster and better."

Get Your Copy

But if you do security earlier in the process, there's a really beautiful upside: not only does that deliver better security, it also makes it easier and less expensive!

“Build security in” vs. “bolt security on”

These concepts have become commonplace amongst the security community, but what’s the practical difference between them? The former is when security is part of the development process; the latter is when security is not considered until later.

Consider my friend’s incredible roof deck: it has everything you could want, including a grill, big-screen TV and amazing views. But it’s missing an important element: a permit. 

When he built the roof deck, my friend skipped that step. He planned to come back to it later, but he didn’t. Then, when he tried to sell the house, a buyer’s inspection flagged the lack of a permit, which killed the sale. 

To get the permit so he could sell the house, he had to overhaul the work he’d already done on the roof deck. It was expensive and took forever. If he had just done it right in the first place, his life would have been so much simpler. 

That’s what it’s like to “bolt security on.” It’s how most people approach the security of their application, and — like my friend and his roof deck — it’s a great way to cause problems for yourself later on. 

People simply don’t realize it’s more expensive and more painful to delay security. But there’s a better way ...

Save your company money and effort by building in security

Instead of postponing security to later, make it a core part of your development process. Not only will your system be stronger because you’re injecting security into every development decision, but your security efforts will also cost less overall. 

You save in two ways: consulting fees and effort. Let’s talk about fees first.

Upon analyzing 13 years of our own security assessment data, we discovered that companies who “built security in” spent an average of 10.1 percent less on consulting fees than those who “bolted security on.” That’s not mind-blowing savings, but it’s real money that doesn’t go out your door. Why waste it?

You might not even realize it, but when you push security off until later, you’re taking on that waste. You’re making it cost more. This costs more because your security partner has to spend more time and effort (which equates to your money) in addressing a higher volume of security issues than if those security issues had been addressed during the development process first.

However, as cool as that 10.1 percent savings might seem, the real benefit comes in terms of your effort. It’s easiest to fix a flaw at the moment when it’s introduced. It’s exponentially harder to fix it later. For example, a flaw introduced in the design phase that isn’t addressed until after deployment is going to require a ton more effort to fix. In fact, the data shows it takes 25 times more effort.

25x more effort!

That’s bananas. It’s pure lost efficiency. It means your developers are spending time redoing work they already did, and are not working on other things to drive the business forward.

Whenever you postpone security, you incur this terrible tradeoff. Every single time. However, when you build security in, you eliminate that effort waste. Just like that, you capture a 25x effort savings. Whose CFO wouldn’t love to hear about that?!

So, in summary: when you do it earlier, you get better security, which costs you less in fees and requires substantially less effort.

Make security part of the development process

If my friend had known what a headache his deck would become, he would have secured a permit from the start. Similarly, I encourage you to build security into your development process. 

No rational person wants anything to be 25 times harder or 10.1 percent more expensive than it needs to be. Yet, companies do this all the time when they choose to bolt on security.  

When you build security in, you convert this waste into efficiency. You save effort, maximize productivity, quickly resolve vulnerabilities as they’re introduced or — even better — avoid introducing them altogether.