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 drum beat of “shift left” echoing across your brainpan. You can’t escape it — it’s at conferences, in blogs, and on 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 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.
Security’s Faulty 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 with 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?”
Of course at Signal Sciences, we believe that this feedback loop is critical to establishing a DevSecOps approach that actually works. In fact, it’s one of the four key areas for security and DevOps to unify as outlined in our DevOps Roadmap for Security eBook. We help customers of all sizes answer the is fundamental question of, “are we being attacked?” We show the details of why we block OWASP injection attacks without touching a single regex signature. The details allow teams to gain confidence in our blocking abilities. But, then we go a step further, and we provide a way for developers, operation engineers and security pros to instrument any application for application-specific misuse and abuse. We do this by providing Power Rules which are easily composed and can be tailored to your application without being a security expert.
This level of instrumentation provides the feedback loop that developers need. It 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 are in full blocking mode on their production traffic — including many of the largest companies on the planet and some of the most visited sites on the internet.
Developers Want More
In the DevSecOps Community Survey for 2018, we found a few stats that were eye-openers.
An amazing 80% of respondents, most of which are 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.
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.
Originally published at labs.signalsciences.com.
