It seems like you can’t talk about app security today without mentioning “left turn”.
This phrase refers to security on the “left” side of the software development lifecycle and vulnerability testing during code development rather than after it goes into production.
And while that sounds good, it’s difficult to successfully integrate AppSec into the developer workflow without causing friction. Teams are too used to working in silos, tools aren’t built for developers, and concepts are tricky for the uninitiated.
To overcome these challenges, CISOs like me have tried different approaches. I bought really Expensive AppSec tools I hired a lot from the AppSec pros and I sent numerous developers to AppSec training. But none of these ever really transferred security into the hands of developers.
Why? Let’s break down the three reasons why this is happening and how we can improve it.
Reason 1: The benevolent security team (or lack thereof)
If you’re lucky, your development team has some kind of security resource. But, a lot of organizations don’t.
There are 3.5 million unfilled cybersecurity jobs at the World level. So even if you have an AppSec pro or team that you work with, they’re probably too stretched.
So let’s just teach AppSec developers! If they can think like a hacker, they can hack themselves! Sounds good, doesn’t it?
But if we really think about what that entails, we can see how ridiculous this concept is.
Security training always begins with teaching developers that the Internet is, in fact, a bad place. And once we sell the fear of being hacked, we try to teach them eleven billion acronyms and make sure they know how to assess the risk.
It would be foolish to try and teach the management team the basics of accounting to understand the implications of a price increase. We wouldn’t teach them credits and debits. We would simply give them a pre-built model with a few cells to modify to understand the impact of their decisions.
So why are we trying this with the developers?
Reason 2: we broke your thing! And we’re super excited about it!
Security has a reputation for being the “no department”.
This establishes a conflicting relationship between security and just about any other department in an organization. It also creates a lot of emotional scar tissue that can accompany safety testing.
There are several things that make the situation worse:
- Security teams are motivated to find a large number of vulnerabilities rather than finding the ones that have the most impact on the business.
- Security teams are super excited to find vulnerabilities. They should be, because it means they did their job. But for developers, the 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) will take the time to fix them.
While it may sound harsh, it is a non-judgmental reality of how security teams may be viewed.
Third reason: production bias
Overall, security testing is now carried out in production. It’s not a good idea.
On the one hand, it makes security a blocker. Security can take the position that the code cannot be fully deployed until they can test the software. We spend so much time running our developers at the highest possible speed that security slows down and slows down a release. This negatively impacts business results and makes the team feel like they have no authority.
Some teams may prefer to test after an application goes into production. Keep your fingers crossed and hope this happens before a bad actor finds and exploits the vulnerabilities. Even if no one finds the vulnerabilities, there is a huge risk that the vulnerabilities will be put into production to be found by a company’s own team.
Security vulnerabilities are just bugs and should be found where 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?
Start, the right way
My work in the security industry with developers has shown me time and time again that in order to be successful at AppSec, we need to replace isolated work with work that fits easily into development processes.
For this to happen, we need to rethink our tools and our culture.
From a tooling perspective, it’s time to overcome the production bias in safety testing. Teams need a security tool that is built into the build pipeline and helps them write vulnerability-free code from day one. Security is just another measure of code quality, and it’s time we started treating it as such.
There are plenty of tools that make this possible with automation, CI / CD integrations, and other developer friendly features.
Then let’s reimagine the relationship between security and developers. It can take some tough conversations. But as leaders, it is our responsibility to unite these two organizations. Security shouldn’t focus on finding large numbers of bugs, creating tickets, and removing them. They should serve as strategic leaders to help developers make informed risk decisions and deliver secure code.
And finally, let’s challenge the assumption that developers don’t care about security. The developers absolutely care about security, they just care differently from the security team. Let’s give them resources and relationships that make it easier to integrate safety into their work.
Security can move to the left, and we can improve it for all the teams that touch the code. So get started today. Start small by changing the way you test a single app and focus on growing your successes from there.
To learn more about cloud native topics, join the Cloud Native Computing Foundation and the native cloud community of KubeCon + CloudNativeCon North America 2021 – October 11-15, 2021