3 Reasons Teams Struggle to Shift Security Left
It seems like you can’t talk about application security today without mentioning “shifting left.”
This phrase refers to bringing security into the ‘left’ side of the software development life cycle and testing for vulnerabilities while code is being developed instead of after it is live in production.
And while this sounds good, it is difficult to successfully integrate AppSec into the developer workflow without causing friction. The teams are too used to working in silos, the tools aren’t built for developers, and the concepts are tricky for the uninitiated.
To overcome these challenges, CISOs like myself have tried different approaches. I’ve bought really expensive AppSec tools, I’ve hired lots of AppSec pros and I’ve sent many developers to AppSec training. But none of these ever truly shifted security into the hands of developers.
Why? Let’s break down the three reasons why this happens and how we can make it better.
Reason One: The Benevolent Security Team (Or Lack Thereof)
If you are lucky, your development team has a security resource of some kind. But, a lot of orgs don’t.
There are 3.5 million unfilled cybersecurity jobs globally. So, even if you do have an AppSec pro or team that you work with, they are probably stretched too thin.
So let’s just teach developers AppSec! If they can think like a hacker, they will be able to hack themselves! Sounds good, right?
But if we actually think about what this involves, we can see how ridiculous this concept actually is.
Security training always begins with teaching developers that the internet is, in fact, a bad place. And once we sell the fear of getting hacked, we try to teach them eleventy billion acronyms and make sure they know how to assess risk.
It would be silly to try to teach the executive team the basics of accounting when it comes to understanding the implications of a price increase. We wouldn’t teach them credits and debits. We would just give them a pre-built model with some cells to edit to understand what impact their decisions would have.
So why do we try this with developers?
Reason Two: We Broke Your Thing! And We’re Super Excited About It!
Security has gotten the reputation for being the “Department of No.”
This sets up an adversarial relationship between security and pretty much any other department in an organization. It also makes for a lot of emotional scar tissue that can go along with security testing.
There are a couple of things that make this worse:
- Security teams are motivated to find a high number of vulnerabilities versus finding those that have the greatest impact on the business.
- Security teams are super excited to find vulns. They should be—because that means they have done their job. But for developers, new findings mean a lot of work for them.
- When security teams find bugs, they throw them over the Jira wall and hope someone (read: The developer) takes the time to fix them.
While this may sound harsh, it’s a judgement-free reality of how security teams can be perceived.
Reason Three: The Production Bias
By and large, security testing today is run in production. This is not a good idea.
For one, it makes security a blocker. Security may take the position that the code cannot be fully deployed until they can test the software. We spend so much time getting our developers to operate at the highest possible velocity only to have security slam on the brakes and slow down a release. It negatively impacts business outcomes and makes the team feel like they have no authority.
Some teams may prefer to test after an app is live in prod. Cross your fingers and hope that this happens before a bad actor finds and exploits vulnerabilities. Even if no one finds the vulnerabilities, it is a huge risk that vulnerabilities have to make it to production to be found by a company’s own team.
Security vulnerabilities are just bugs and should be found the same place we find all of our other bugs—in development. We use unit testing, build testing and integration testing to make sure things work as expected. So why is security so different?
Getting Started, The Right Way
My time working in the security industry with developers has shown me time and again that, in order to succeed at AppSec, we need to replace work in isolation with work that is easily integrated into the development processes.
Making this happen means we need to rethink our tooling and our culture.
From a tooling perspective, it is time to get over the production bias in security testing. Teams need a security tool that is integrated into the build pipeline and helps them write vulnerability-free code from day one. Security is just another metric of code quality, and it is time we started treating it as such.
There are a lot of tools out there that make this possible with automation, CI/CD integrations and other dev-friendly features.
Next, let’s reimagine the relationship between security and developers. This may take some hard conversations. But as leaders, it is our responsibility to unite these two organizations. Security should not be focused on finding a high number of bugs, creating tickets and walking away. They should be serving as strategic leaders to help developers make informed risk decisions and ship secure code.
And lastly, let’s challenge the assumption that developers don’t care about security. Developers absolutely do care about security—they just care differently than the security team. Lets give them resources and relationships that make it easy to embrace security as part of their jobs.
Security can shift left, and we can make it better for all teams that touch code. So get started today. Start small by changing how you test a single app and focus on growing your successes from there.
To hear more about cloud-native topics, join the Cloud Native Computing Foundation and the cloud-native community at KubeCon+CloudNativeCon North America 2021 – October 11-15, 2021