Why “Shift Left” is Bulls*t…and Imperative

DevSecOps has eclipsed DevOps as the most annoyingly overused portmanteau of the software world. And “Shift Left” is the central concept in DevSecOps, stating that security should be addressed earlier in the CD pipeline. Great. But many have taken “Shift Left” to mean, “it’s all on developers’ plates now!” Since developers are the source of most vulnerabilities — so the theory goes — they should be the ones responsible for security. This sounds great…to everyone who isn’t a developer!

Shift Left spends a lot of time pointing a finger at developers while leaving the Sec and Ops members of the DevSecOps triad strangely unaddressed. We need to refocus on all three parts – dev, security, and operations – to really understand how to build and deploy secure software. Shift left must be about timing, not about ownership.

Leaving security to a security team doesn’t work

The later an application problem is discovered, the more costly and complex it is to fix. This has been true for the entire history of software development. And it’s not just for security — any bug is easier and cheaper to fix the nearer it’s discovered to when the code was written. Quality, performance, security — all these needs are best addressed early.

Unfortunately, application security has traditionally been something left to the very end of a development process — and it’s been focused on detection, not remediation. A small team or third party would test an application just prior to its production deployment. If a problem was found, deployment was halted and the app was sent back to dev. Security experts are good at discovering application security problems, but they have no ability to fix them!

Bear in mind, this bad situation is only the case for organizations who have an application security team — a 2016 survey found that only 7% of organizations have a security expert outside of IT. It’s actually worse for most others. The vast majority of organizations leave application security until after the very end. They only “find” a problem after it’s been exploited resulting in a breach (see Equifax for a refresher on the potential damage that can be done by that).

Developers Don’t Care about Security

If we can’t leave security to security teams (because orgs simply don’t have them, or because it’s too difficult and costly to address security problems late, and security folks can find, but not fix, problems), that means that developers should handle it — right? Well, I’ve been building developer tools and security products for many years and if there’s one phrase I’ve heard more than any other, it’s “developers don’t care about security.”

Before security, I used to hear the same thing about quality — developers don’t care about quality, they just want to write code and chuck it over the wall to QA. Then it was developers don’t care about performance. But they did (and do) care about both of those things — they just needed an easy way to work them into their dev process.

Developers want to build good software — that’s software that works well and delivers value. Good software doesn’t have bugs. Good software is fast. And good software shouldn’t be vulnerable to attacks. No developer wants to be the person responsible for committing the code that brought the company down! So, yes, actually, developers do care about security. Unfortunately, not all developers know how to build secure software.

Shift Left is a Mandate for a Whole Team

Fixing security issues late is too complex and costly. Security teams are stretched thin (or not present at all), and developers aren’t security experts and need assistance to understand how to build security into their apps. So how can we “shift left” realistically? Security must be a full-team effort. Yes, address security early and often — but it’s not solely the responsibility of developers.

Security teams need to work with developers to help them improve their secure software development skills. Threat modelling, writing abuse cases along with use cases, and regular training and professional development all are good places to start. If you don’t have a security team, look to tools and online training to help with these goals.

Operations teams need to incorporate application security tools into the CD pipeline and production environments, just like they do for quality and performance. APM tools assist developers in identifying ways to improve performance during development, and then monitor production apps at runtime for problems. Likewise, a runtime application security tool (like Bluefyre) does the same for security.

Finally developers need to consider security — just as they consider quality, performance, scalability, etc. — as another aspect of good software. It should be discussed when planning an app, and tested while developing.

Shift Left is about timing, not about ownership. You wouldn’t wait until an application was in production to see if it was fast enough, would you? You wouldn’t wait until a user reported a bug to think about quality? So integrate security into the entire process, just like you do those attributes of good software. Just don’t cite “shift left” as an excuse to dump all the responsibility on devs alone.

Originally published at www.bluefyre.io on June 19, 2018.