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.
Security is part of what makes a product viable. Your customers expect it. Just like you can’t postpone a feature that is core to your value proposition, you can’t defer security either. However, if you do it right, you avoid the headache and heartache that otherwise is waiting for you later.
However, proper security is about timing. Doing it later is easier at first but a nightmare overall. Doing it now is easier overall but often dismissed at first.
Most people unwittingly pursue the approach that makes their lives harder. Instead, pursue the approach that makes your life easier. If you want to do it the easy way, you need to take action early by building security into the development process. If you don’t, you’ve signed up for the hard way.
Build security into the development process: it is more effective and less expensive than delaying security.
Most people approach security of their application with a “build first, consider security later” approach. The reasons for this are many: there’s pressure to meet deadlines, and security is often not viewed as something that’s required prior to release. People don’t realize it’s more expensive and more painful to delay security. There’s a misperception that you need to see how the market responds to a release before it’s worth trying to secure it.
In a moment, I’ll teach you why this approach is painful. But first, let’s explore what you should do instead: “build security in.” This is when you consider security at each stage of the development process. Some elements you handle in-house, other elements your security partner handles (I’ll explain who does what and when). This way, you invest incrementally along the way. It makes your life easier and is less expensive overall. It also ensures that you get security right.
Security done early is less expensive than security done later. This is thanks primarily to avoiding that unnecessary work while you also save on consulting fees. Upon analyzing thirteen years of our own assessment data, we discovered that companies who “built security in” spent 10.1 percent less on consulting fees than those who didn’t. That’s not a mind-blowing savings, but hey, 10.1 percent is 10.1 percent! That’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.
Better yet, as cool as it is to save 10.1 percent on consulting fees, that pales in comparison to the savings 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 twenty-five times more effort.
Twenty. Five. Times. More. Effort.
That’s bananas!
When developers are fixing systems they already built, they’re not working on other things. Salary, benefits, and overhead appear on company financial statements either way; however, developers’ productivity plummets. This decreases the value the company gets out of each developer. It’s a massive hit to your output. If this isn’t alarming you, you’re not human. No one likes waste, especially when it doesn’t improve outcomes.
No rational person wants anything to be twenty-five times harder than it needs to be. Yet, people do this all the time. This happens not because people want to make their lives harder; it happens because they don’t realize it’s happening. My mission is to help you stop incurring this waste. Whenever you postpone security, you incur this terrible tradeoff. Every single time.
Introducing vulnerabilities is going to happen—that’s a reality of software development (and is the reason that this book exists). But it’s hugely inefficient to let them linger in your system any longer than they need to. The book Applied Software Management spells out this truth. It explains that (a) most vulnerabilities are introduced during development, but (b) most testing isn’t done until after release, yet (c) remediation costs rise exponentially after release.
It’s literally that simple: when you delay, it costs you.
Now that you’ve explored why to build security into the development process, let’s talk about how.
Simply put: in each step of the development process, there’s a security step, too.
That might sound like a big undertaking, but really it’s not. It’s just a small change. You already have all of the right people in the right room having the right conversations; you just need them to consider security as well. The activities that are more involved (such as security testing) are handled by your security partner anyway, so the additional burden on your own developers is offloaded.
Many companies use a linear-sequential software development methodology, such as Waterfall. In this type of development methodology, the entire development project is approached as a whole, with each phase being completed across the entire system before the next phase begins. Here’s how you’d build security into this type of methodology:
As one of our security analysts put it: “Think about security when you’re doing things, not after you already did things.”
Many software companies tend to think that security slows down the development process. It’s seen as important for sure but not as the most important thing right now. It’s seen as something that can come later. It’s seen as something that causes delays in hitting release milestones and overall makes lives harder for developers.
There’s just one thing, though: it’s not true. It’s one of the biggest fallacies in all of computer science. “Security slows me down!” False.
It makes your life harder, costs more, and is less effective. It’s taking a short-term view on a long-term problem. When you delay security now, you accept massive slowdowns in the long run.
Build security into the development process, and you’ll get better security that costs you less.
Content adapted from: