Security's Shift Right

Software development has gotten tricky. If you have been in the DevOps game in the past few years, then you have noticed a drumbeat of "shift left" echoing across your brainpan. You can't escape it — it's at conferences, in blogs, and on numerous podcasts. We know how to write tests before writing code — boom, we shifted left! We added acceptance testing in our CI system — notch one up for another shift-left win. 

Yet, with all this shifting left, there is a whisper in the wind (it may be hard to hear), but it is not a new sound. It is a more of a nagging reminder of a truth we knew long ago — it's the faint reverberation call to shift right. 

Shift Right? But, I Just Started the Shift Left 

First, take a moment, it's OK to be dismayed that I am suggesting that shifting left won't solve all your problems. That's a normal feeling you are experiencing. There has been such an incredible push to shift left that any advice to do otherwise might rightly get declared as unorthodox. Moreover, I imagine readers will ask, "isn't shifting right what got us into trouble in the first place? Didn't security spend decades at the right side of the software delivery lifecycle through penetration testing, compliance, and building a culture of 'no' in more organizations?" 

Yes, that is all true. 

Security has been guilty of spending too much time on the right, and has done the majority of testing at the end of development and focused on perimeter defenses like firewalls. However, that's not all. Security has also been guilty of using a lot of resources shifting left way before 'shift left' ever became a thing. Just think of application security training classes. Security, as an industry, came up with a premise: 

We can solve our security problems if developers could just learn how to write secure code.

It's a bit of a tautology and a head-scratcher, but it gained widespread adoption across the board. It is the furthest shift left you can make — teach the developers before they write any code. As a result, developers en masse have been paraded through security training classes year after year, learning the latest OWASP Top Ten — which is largely the same list as it was the last go-around — and getting lectured on how to write secure code. Yet, here we are. 

I think Steve Bellovin's sentiment sums this up nicely. 

Companies are spending a great deal on security, but we read of massive computer-related attacks. Clearly, something is wrong. The root of the problem is twofold: we're protecting the wrong things, and we're hurting productivity in the process. 

- Steven M. Bellovin, Thinking Security

Requiring developers to write secure code is not realistic because security vulnerabilities are just bugs. Yes, there are bugs that can be exploited and they are a small set of all bugs written, but they are bugs, nonetheless. No matter what you do, you cannot prevent developers from writing bugs. Not as long as humans are at the keyboard.

So, What Is the Solution?

Once you give up on the idea of teaching developers to not write bugs, you are freer to think of approaches to help them. One of the best approaches is to provide rapid feedback to developers. In the land of application performance, we found that running APM tools in production was a way to help developers find places to optimize their code. This created a feedback loop from production (the right) to development (the left).

Let's take the same approach to security. By exposing security feedback from production to developers, both teams are enabled to communicate about real problems facing the application or service. We can be able to answer the basic question of "is our application being attacked right now?"

Developers Want More

In the DevSecOps Community Survey for 2018, we found a few stats that were eye-openers.

From the DevSecOps Community Survey 2018 Results

An amazing 80 percent of respondents, most of which are developers, reported they thought security was part of everyone’s role. However, 48 percent of developers reported they don’t have enough time to spend on security. When combined with the fact that 1 out of 3 breaches are happening due to web apps, we feel now is the time to make the shift right and add instrumentation and defense where it is needed most.

Before you think about shifting even further left, consider if you should actually be shifting right. 

Is now the time to include production in your DevSecOps journey? By putting production security defense and instrumentation in place, you are able to bridge security and development and operations.