Larry Maccherone Explores Several Advantages of Adding Security to DevOps

For many dev and security teams, a reset on culture and mindset is critical to begin integrating security into every phase of the software development lifecycle as a shared responsibility, as opposed to addressing security after development.

In this archived keynote session, Larry Maccherone, DevSecOps transformation architect of Contrast Security, highlights ways to fundamentally transform the process of AppSec and DevOps, to a modern DevSecOps approach. This segment was part of our live webinar titled, “How to Amplify DevOps with DevSecOps.” The event was presented by InformationWeek on May 22, 2024.

A transcript of the video follows below. Minor edits have been made for clarity.

Larry Maccherone: So, I'll start off with the bad news, the way we do AppSec fundamentally today is broken. There's an assumption that there is a time that security gets with the product before it gets to production, which is an old way of thinking.

They still have the mentalities that went with that mindset, like gatekeeping. If you have a team that's following DevOps, there's no way that they're going to be releasing multiple times a day to production.

Even if it's once every two weeks, or even every two months, security can't do a full audit of that and gatekeep into production effectively, especially without several resources. The first bullet there is the thing that everyone says is the problem with the traditional way of doing security, and why DevSecOps is becoming the new model.

Related:No-Code and Low-Code Apps: Look Before You Leap

But I think there's some more insidious problems with it. This work involves the security people finding things wrong with the engineer's work, and then they must go call the engineer's baby ugly to them. It's time-consuming work, and typically, the engineers don't want to hear it.

By the time the feedback comes to them, they've already moved on to several other features. The whole thing is just an annoyance to them, and they'll do the minimum amount of work required to get it to go away. The conversation can be very confrontational.

You'll often get a response like, what is the minimum I can do to get you to stop bothering me? That's usually not an effective answer, because the whole idea of gatekeeping is out of date. Typically, the specifics of the policies just don't fit with the way modern development is done, which causes friction that enables the security teams to choose not to enforce all of them.

But when you selectively enforce them, it seems arbitrary, and you get this broken window effect. If I can ignore those policies, why can’t I ignore all of them? So, I would argue that full audits are too much information and depressing. If you can't audit those policies, you’ll never get any healthy responses.

Related:Can Your Developers Benefit from Platform Engineering?

How do you fix this? How do you get over this? Well, there's several challenges, and I'm not going to get to all of them today in this short time, but I'll try to address the biggest ones. First, you essentially must consider how people think about AppSec.

Generally, AppSec leaders think that they can fix these problems that I described by doing things on this list of actions. Create more relevant and consumable product policies, so that they aren't outdated. Let's get better at enforcing the policy and implement the right metrics-based incentives.

Sometimes the thought is to train more, because the assumption is that teams just don't know enough, and if we train them, then it'll all be better. We could collaborate and work together better and even buy new tools.

Almost all of these are good things, but they are not sufficient to solve the problem. I have a cultural transformation approach that I'm going to introduce to you that will allow you to fundamentally transform the process and the current operating model you use to do AppSec, to a modern DevSecOps approach.

Related:How Developers of All Skill Levels Can Best Leverage AI

It utilizes several DevOps concepts, which is something they're already familiar with. To motivate you to stick with the concept, this is essentially the transformation blueprint process that I developed at Comcast where I captured the data for it.

The teams that went through this program took more ownership and did it the way I'm going to describe here. They had one-sixth as many vulnerabilities in production as the other teams that hadn't gone through the process.

In addition, the number was roughly about one-sixth in comparison to the number of vulnerabilities they had before they entered my program and started doing it, and we can run this program with one-fourth as many people.

It was so effective that we scaled it to all 600 teams at Comcast, and they essentially shut down the old AppSec program by the time we got to critical mass on this. You pretty much had to onboard using the program that I developed there.

Watch the archived “How to Amplify DevOps with DevSecOps” live webinar on-demand today.