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.
Security: Built-In vs. Bolted On
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.
Always Choose To “Build Security In”
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.
How to “Build Security In”
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:
- During requirements gathering, you discuss the problem that the system needs to solve. Simply expand the discussion to also consider your threat model.
- During design, you define the system architecture, determining which components to build and how they’ll interact.
- During implementation, you code the system.
- During testing, you evaluate system performance.
- During deployment, you roll the solution out to customers and deal with the inevitable challenges that come with that. Now is when you also advise customers on configuration so they deploy your system securely.
- During maintenance, you’re in the never-ending cycle of resolving bugs. Same idea with security. Through reassessments, your security evaluators help you continually find and fix security flaws. As a result, you keep your system secure over time, all without too much heavy lifting by you.
As one of our security analysts put it: “Think about security when you’re doing things, not after you already did things.”
Always Keep Security Top of Mind
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:
