DevSecOps Chronicles
Security’s Shift Right
Software development has gotten tricky. If you have been in the DevOps game for the last few years — and let’s be real here, who isn’t these days? — then you have no doubt noticed that there is a drumbeat of “shift left” echoing across your brainpan. You can’t escape it at conferences or blogs or the numerous podcasts. We know now to write tests before writing code —boom, we shifted left! We added acceptance testing in our CI system — notch one up for a shift left win.
Yet, with all this shifting left, it may be hard to hear, but there is a whisper in the wind, it is not really a new sound. It is more of a nagging reminder of a truth we knew long ago. It is the faint reverberation call to shift right.
Shift Right? But, I just started the Shift Left
First, take a moment and be upset that I am suggesting shifting left won’t solve the problems. That’s ok. There has been such an incredible push to shift left and all that goes with it that any advice to do otherwise might rightly get declared as unorthodox. But, 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 most organizations? Well, that is 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 is not all. Security has also been guilty of spending 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 has gained widespread acceptance across the board. It is the furthest shift left you can make. Just 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 as it was the last go around and which is telling in and of itself — and getting lectured on how to write secure code. Yet, here we are.
I think Steven 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
To teach developers to write secure code is not realistic because security vulnerabilities are just bugs. Yes they are that can be exploited and they are a small set of all all the bugs written, however 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 do we do?
Once you give up on the idea of teaching developers to not write bugs, you are free 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).
Why can’t we take the same approach with security? This is the idea, expose security feedback from production to developers. This gives developers and security a way 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?”
Of course at Signal Sciences, we believe that this feedback loop is critical to establishing a DevSecOps approach that actually works. We help customers of all sizes answer this fundamental question of, “are we being attacked?” But, we go a step further, we provide a way for developers, operation engineers and security pros to instrument any application for security. We do this by providing Power Rules which are easily composable and can be tuned for your application without being a security expert.
This level of instrumentation provides the feedback loop that developers need. Rather than focusing on teaching people to not write bugs, this enables people to ship software and instrument for security. It gives the team insight into the real, live attacks they are facing and put an active defense in place. At Signal Sciences, this isn’t theoretical, we have 95% of our customers in full blocking mode on their production traffic. And, this isn’t for small shops, our customers include some of the largest companies on the planet and some of the most visited sites on the internet.
Developers want more
Before you think about shifting left more, consider if really you should be shifting right. Is now the time to include production in our DevSecOps journey? By putting production security defense and instrumentation in place, you are able to bridge security and development and operations.
In the DevSecOps Community Survey for 2018, we found a few stats that were eye-openers.
An amazing 80% of respondents, most of which were developers, reported they thought security was part of everyone’s role, however 48% 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.
