Build security into software up front: Believe it or not, it’s cheaper and faster

build secure software“You can pay me now, or you can pay me later” was the tagline of a 1981 ad promoting oil filters.

Seems simple, but the implied message was much stronger: It wasn’t about paying the same amount now or later. It was about paying a little now for an oil change or vastly more for an engine rebuild later—which made the choice pretty much a no-brainer.

For anybody in the business of building software products, the same logic applies. The financial benefits of finding and fixing defects throughout the software development life cycle (SDLC)—starting at the very beginning—ought to make doing it a no-brainer. It is both easier and cheaper.

But it remains a tough sell.

Not that security evangelists haven’t tried. They’ve made the business case, offering various physical illustrations to help organizations understand the importance of building security in throughout the SDLC. Jim Routh, chief security officer at Aetna, spoke with an information security publication in June, and didn’t talk oil changes, but he stuck with the automotive concept, comparing the SDLC to a production line where 10% of the vehicles were coming off with a dented door.

It would take a special kind of insanity to argue that it would be better to keep everything running and repair the doors as the damaged cars came off the line, rather than spending much less time and money to shut it down, fix the problem, and stop the damage from occurring at all.

It would be even worse, of course, if the cars with dented doors, or perhaps other potentially lethal defects, were shipped out to be sold. Then the manufacturer would face brand-name damage (imagine the ridicule), the expense of a recall, likely litigation, and an almost-certain decline in both profits and the value of company stock.

These same risks apply to the code streams that are the building blocks of software. It’s true that eliminating “dents” from them doesn’t come cheap—it can easily run into the millions. But, so can the savings at the other end.

The findings of a 2016 Forrester Research study call to mind an ancient proverb: A stitch in time saves nine. Or, in the case of software development, fixing defects early in the SDLC could reduce remediation costs by a factor of anywhere from 5 to 15.

The study set a baseline example of 5 hours of work to fix a defect in the coding/development stage. Finding and fixing that same defect in the final testing phase would take 5–7 times longer. And waiting until after the product was on the market to discover and fix the same defect would take even longer and cost 10–15 times more.

That doesn’t include the potential cost of damages from a bad guy discovering the defect first and exploiting it to attack users.

And to the frequently stated worry that ongoing security testing creates intolerable delays in time to market, Forrester found the opposite: that it cuts time to market by 25%.

Gary McGraw, vice president of security technology at Synopsys, said one reason developers don’t “build security in” to their products is that they don’t think about the total cost of a product—which includes not just development and production but also maintenance through its life cycle.

“People don’t understand how much they can save,” he said. “I can release bad stuff really fast, but then it’s going to cost me later.”

Another misconception, he said, is that people think security testing means penetration testing, which generally occurs right before a product ships, when finding and fixing defects is more expensive. “We have a new definition,” McGraw said. “Fix it while you’re building it.”

Yes, you have to “pay now” to do secure code review with a static analysis tool. But you’ll find bugs as the code is being written, which is much cheaper than “paying later” to find them during penetration testing or, even worse, when your product is on the market and hackers are exploiting the bugs you should have found first.

Don't miss