DevSecOps is the latest in a long line of buzzwords. The core makes sense: work on security earlier. But why isn’t this everywhere? Here’s the biggest mistakes teams are making trying to “do” DevSecOps.
Learn more in the video 👆 or read through the transcript 👇.
Transcript
I see security teams making the same mistake over and over again when it comes to “shifting left.” It’s frustrating from afar and infuriating when you have to deal with it day-to-day.
Let’s dig in to the disaster that is DevSecOps…
[00:15]
Imagine for a minute, you’re in your kitchen preparing dinner. You’re a reasonably good home cook. More often than not, what you put on the table is enjoyed by those you’re sharing with it.
Sure, every once and a while you miss. But that’s the rare case, so when it does happen everyone smiles, you laugh, and then place an order for take out. Mistakes happen.
Not too bad, right?
[00:29]
Now, let’s say while you’re getting ready to sit down for a wonderful home cooked meal, you neighbour invites themselves in. They immediate start hammering you with questions like, “How sharp is that knife?”, “Do you know who grew that broccoli?”, “Are there too many ovens in this neighbourhood?”
Taken aback, you politely ask, “Um, are you a professional chef? Do you have a lot of experience cooking?”
They reply, “Oh no, I don’t even have a kitchen in my place. I just order food every once and a while.”
That’s basically the scenario I see play out in organizations around the world.
The development teams and builders are working to solve business problems and address customer needs.
Then the security team shows up out of no where and starts asking seemingly irrelevant questions and demanding that priorities change in the name “reducing risk” and “improving the overall security posture” without understanding what you’re working on or how you work.
[01:37]
This is why even the name DevSecOps frustrates me to no end. The DevOps philosophy already assumes that you want to build a resilient, reliable system. There’s no need to jam another acronym in there.
Teams know that security is important, they just need the information and support to make smart decisions at the right time.
So is this whole “shift left” thing doomed?
No.
Not if you do it well.
[02:06]
If you’re on the security team, the first thing you need to understand is that you probably don’t understand how the builders are working.
You can fix that.
Spend some time with them. Ask lots of questions to better understand their workflow and concerns.
Most important of all, make sure that the information from security tools that shift left provide information with the proper context and enough data for teams to make an informed decision.
[02:34]
Just because it’s a security priority, doesn’t mean it’s a business priority.
For developers and builders, understand that security controls can provide real value to you. The whole goal of these controls is to make sure things work as intended.
Network security tools look for malicious activity and malformed traffic. You don’t want that anywhere near your app.
Threat detection on your servers and containers is looking for errant processes and other indicators of compromise. This makes sure that your resources are only working for you instead of doing things like mining cryptocurrency for cybercriminals.
Posture management—ugh, horrible name—looks at the cloud services you’re using to make sure that you have configured them in a way that matches your risk appetite.
Vulnerability scanners look at your tech stack trying to find known issue before so they don’t bite you in the you-know-what.
[03:26]
Everything on this list and most of the other security controls out there can dramatic HELP you meet your goals.
With that understanding, you need to make sure that you have access to the outputs of these tools. You need to know that they are in place and doing their job, so that you can focus on other parts of yours.
By now, you’ve figured out that the number one mistake I see security teams making when they “shift left” is IGNORING the developers and builders.
For some reason, security teams assume that to “shift left” means doing their isolated security work earlier in the development process. That’s an archaic way of thinking.
[04:05]
To truly shift left, you need to leverage the capability of security tools and processes to help developers and builders identify risks with their systems earlier in THEIR processes.
This data will help the teams make informed decisions about what actions should be taken to meet the business goals.
Shifting security left can help reduce the risks to the business while improving the quality of the systems your build.
Who wouldn’t want that?
Top comments (0)