Putting the “Sec” in DevSecOps – Predict 2025

Hey everyone. Thanks so much for joining me today. My name's Jonathan Singer, I'm from Check marks.

And today I'm gonna talk a little bit about putting the SEC into DevSecOps today. There are three things that I want to convince you. The first is that high performing code that is not secure, it's not high performing.

So in secure code it's actually a, a culture problem. The second thing, security tools are or must be developer tools. And the third thing is that DevSecOps is a culture problem.

Before it's a technology problem, I'm also going to give you five requirements to build your organization's DevSecOps maturity. Those are one, education, two automation, three speed, four shared measurements, and five integrations. Let's begin.

I wanna start by asking us where are we today on our DevSecOps journey? We ran a survey of over 200 chief information security officers and only one in five that we surveyed have actually begun integration and automation. And that's a lot of the main work of DevSecOps.

Alright, so you know, we look up at these survey numbers and it looks like we're not really doing DevSecOps yet as an industry. So the question is why is that? Well, look at the way the answers here are formatted.

You know, I work for an AppSec vendor and do any of the answers here mention a tool? No, they don't because buying a tool is easy. Well easy, I'll put that in quotes because you have to go through procurement and, and all that.

Um, but honestly, you wanna buy something. Send me a message on LinkedIn, I'll introduce you to my sales rep. You can go buy something, but getting you to buy something is hard work for my company.

But it's not the hard work that you need to do. If you wanna do DevSecOps, the hard work for you is in building a DevSecOps culture. So let's talk about DevSecOps at the highest level.

What is it exactly? What it's not is not just DevOps with security. 'cause a lot of you are probably already trying.

What DevSecOps is, is the continued merging of organizational cultures that began with DevOps, right? So if you go back to 2009, that's when DevOps really kind of started to hit the ground running. And from there it's been a series of cultural challenges.

And now remember the, the name of the stocks square PE in a round hole. Why did I name it that? Well, where did DevOps people come from?

They come from the land of move fast and break things, right? They they, they build applications, they try things, they get them to work, they're about getting product out value out quickly. Cool.

They spend all their day as developers hopefully in their IDE coding as quickly as possible, trying to be really thoughtful about what they're building. Where do security people come from? Well, they come from the land of never ever, ever let anything break.

We'll be in trouble, right? So it's, it's just a very different mentality. Um, DevOps or sorry, security people live all day getting alerts flashing at them.

You know, we've got a WAF problem here, we've got a problem with this tool. They get alerts all day and their job is to keep the organization safe and not let things break. So if you wanna talk about Dev SecOps, it's about taking the needs and outcomes of security, which are risk management and mitigation of threats and integrating them into the processes and culture of DevOps.

And this is possible, the point is for DevOps DevSecOps to become the same thing, just differently. I would argue that they are. Alright, so cool.

How do we get there? I wanna talk next about DevSecOps maturity. So what you see here is a graph that I definitely didn't free draw with my track A and then have the design team put some lipstick on.

Um, alright, that's exactly what I did. But what it represents is actually how organizations at a very high level end up on the road to DevSecOps. If you want a super formal maturity model with like a lot of really detailed steps, Gartner's got you covered for that.

They got a great report, but this is a really easy place to start your thinking. So let's look at the three different levels, the bottom level security focused. This is where the application security team gets a tool, scans for some vulnerabilities and hucks them over the wall to developers saying, here you go, it's your problem.

Now. Um, so that's not entirely fair to security people, but I'm gonna be even more unfair here for a second. This right here, that's shift left.

We've shifted the problem left, we're scanning earlier and here are some vulnerabilities. We need to fix them, right? And it's a really important first step and it's important that your AppSec team takes it, but you really need to then take the next step.

And that's developer experience. Here's where it starts to get in. Interesting for the people who are probably watching this presentation, right?

This is where we start thinking about how you as developers work, right? And that's integrations. That's can you sit in your IDE and get your results there?

Can you get remediation guidance there? Can you get everything you need there? How do we make it easier for developers to stay in their workflow, right?

So once the AppSec team starts thinking about that, providing you with tools that integrate, you're getting on the road towards DevSecOps, but you haven't necessarily had all the important conversations. This last part of, uh, of maturity where we get to actually DevSecOps equaling DevOps, right? That's where we really start to work together, right?

We figured it out, we've got some tools, we've made sure that they're connected. But here's where we realized that that's not entirely enough. And and you've probably been doing some of this work along the way, so I'm not gonna say that it just appears here, but this is where security and development teams and platform engineers, they all sit down and they set joint policies and they enable developers to be more secure wherever they are in the software development life cycle, right?

This is where you get automations going, this is where you really, really start working together smoothly and it just becomes a part of your cycle. And if you wanna see what it actually looks like in person, this is actually what it can look like. So this is a customer of ours, uh, fortune 100 utility provider, pretty big company, no joke.

And you'll note if you go all the way to far left of this graph, they had a tool, they bought that tool, it was in fact our tool for a year and a half. And uh, they were gonna get rid of us because as you can see, they're not really using it. Why weren't they using it?

Security is flowing things down. Developers aren't fixing the vulnerabilities. Vulnerabilities we send them, right?

So you've got developers saying things are slow and security is saying you're not doing the work, right? They shifted, left, didn't really work, okay? So then we started to talk to them about the process, about how do you fit AppSec into the development process.

Why do you give developers a good experience? Oh, and then you start to see it start to perve up. Then you start to form some joint policies and you realize, hey, we've got these joint workflows and we're really starting to get some work done.

We're really making our applications more secure. And so here's where you say that you know a tool, it's a tool, but security is the process. And that's why, because it's process oriented in the end, security can find a successful home in DevOps.

But what it means is that next we need to talk about DevOps and DevSecOps in the lens of human culture, right? Enablement, measurement, speed, automation, integration. How do we make these things work together?

So we need for the DevOps crowd to get to DevSecOps. We need platform engineers, architects, developers, we all need them to see security tools as developer tools and secure code as performance code. So I told you that I was gonna talk about integrations well or sorry about um, about DevSecOps requirements.

And I've put together, I thought like kind of long and hard about this and I put together a few and I lined them up with columns from the DevOps handbook, right? Columns as great accurate culture automation, lean measurement sharing. I'm sure that you've read the book.

Um, I've come up with my own list of, um, requirements that nest within columns. I'm not gonna do it in that order, but I think that these are gonna help you get you on your way. So we've got integrations, we've got shared measurements, we've got useful security education, we've got matching security velocity to developer velocity and we've got automations.

So let's talk about requirements. If you remember back to our maturity model, the first step away from throwing vulnerabilities over the wall is thinking about the developer experience. So the first requirement for DevSecOps is to keep developers in their flow state.

That means tools need to be delivered directly to the ID to keep things moving. So if you're a platform architect, architect and you're picking a tool, you know, you likely have, you know, multiple, possibly thousands of pipelines. But what does that mean in terms of support?

How many different tools does whatever you're gonna buy integrate with any languages it does it support, right? These are all tool questions and that's because it, these integrations actually become culture themself. The culture part is where it's security thinking about how developers work and how they operate.

And that's how you take that first step up in maturity. If security isn't thinking about how developers work, you're not even on the road, right? And all this is important because the goal in the end again, is for developers to see security as a tool at their disposal in developing high performing code and not a rate block.

The second requirement is what I call shared metrics. What are shared metrics? 'cause if you've got metrics, presumably you're sharing them with someone.

But simply put, these are metrics that everyone on the DevOps side and the security side can relate to. And it's actually not what this graph shows. In fact, um, sorry about this graph.

If you're colorblind, I'm super sorry about this graph 'cause there's no way you can read it. All I can say is even if you can still see colors, you probably can read it, but I'm gonna talk about it for a second. 'cause what it shows is all the way on one side what developers care about in jail is their responsibility.

And on the other side what security believes is their responsibility. And you can kind of see where they sort of meet in the middle. Um, but the point is this illustrates how security and development at DevOps, they're thinking about vastly different things, right?

So security teams and development teams, we know already that they think in very different metrics and they feel responsible for very different metrics and they contribute to tracking different metrics. But if you wanna do DevSecOps, you need everyone thinking about the same things to to a point, right? So sure security can go where they can look at total number of vulnerabilities, they can look at how many of each severity they have, uh, that's been remediated and that's really good for them for their own reasons.

Um, it's really helpful for security to show that they're doing things but it doesn't drive forward to have SecOps. So the question becomes what are good metrics? So good metrics from a DevSecOps perspective are those that show you how quickly your integrated team is delivering value for the organization.

Metrics that help you direct your efforts, identify problems in your pipeline so that you can work more efficiently. And that isn't to say that these other metrics don't have a place. You know that the DevOps metrics, if you're a developer or a platform engineer or an architect, you know that those are useful and you know why they're useful.

Um, and these, these numbers on the left, the AppSec metrics, those are fantastic for application security teams to say, Hey, we're doing work. Justify it up the chain, justify the purchase of tools, justify headcount, which they need to do a lot of, right? 'cause a lot of people see security as just a cost center.

So they need those justifications. But what you need to get to together is you need to get over to the right where you're watching these DevSecOps metrics that are gonna keep your machine running, right? And the most important of those is mean time to remediate.

So that is how quickly our security and developers working together to get vulnerabilities fixed, right? Mean time to detect how quickly are we detecting metrics? How quickly are we getting them through the pipeline issue volume?

How many security vulnerabilities are there? And that's becomes really interesting if you can break it up by application and team, what are your top vulnerable applications? Where do you need to really like spend your limited security resources?

Do you have a security champion program? Do you have security consulting teams internally? Where do they need to spend their effort?

Security coverage? How deep are we actually scanning applications? How does that factor into the risk?

Are we looking at internal applications that are behind internal firewalls, not as risky. Maybe we give them quicker scans versus the stuff that's really important that goes out there in front of customers collects PII that needs the really deep scanning. These are all things that need to be figured out and need to be measured to show that your DevSecOps effort is really working together as a machine.

Third thing I wanna talk about is security education. So performance is really firmly ingrained in development culture. You can see it along the timeline here.

The problem is security isn't. So, you know, 20 years ago performance wasn't really either, but now it's, so if we're looking at this timeline, we're saying, okay, you know, the building blocks for DevOps happened in the early two thousands, 2009. We've got that great presentation.

Things start to take off. You know, it's now, it's been 15 years since 2009 and still in some places DevOps efforts are just getting off the ground, right? So DevSecOps, we know we've been talking about it for a few years, it's gone probably another time 10 years before we're really getting it down.

Well, but we know we need to get it down faster than that. We know that, uh, you know, there are a lot of threats out there and they're all targeting, uh, these new applications that people are building. So, you know, how do we get, we follow on the road of tho those next 10 years and get to the place we need to be at?

And education is a big part of that. So if you look at the stat at the bottom, only 50% of de bars state that they have access to security training. That's because we know that universities don't teach secure coding.

We know bootcamps don't really train depths in secure coding. And we know that it's also a big complaint of security teams. Uh, the developers don't know secure coding, but we also know that's not really developers' fault, right?

Developers learn through especially about security through experience. So like, hey, that guy over there, he had a problem with a big cross-site scripting vulnerability and he had to fix that. He's the guy who can tell you all about it.

Or, oh, that lady over there, um, she was working on the lock four J stuff, so she really knows her stuff, right? It's, it's not their fault and knowledge becomes tribal here and there, but what do we do about that? And what we need to do is give developers options, right?

And we've got three different types of options. We've got training, we've got just in time and we've got inline education, right? So what do these look like?

Formal training? It's you get access to a security coding course, uh, or a secure coding course and you put your developers through it takes a lot of time. Um, and maybe, maybe they have time to work on it during the week.

You know, I know that, uh, developers focus a lot on learning and maybe you have like a Tech Thursdays or Coffee Mondays or you know, some sort of learning program and, but this is just a part of it, right? So who has time to really sit and do formal training all the time? Not everyone, but it needs to be an option.

The next is just in time training. So this is how when they need it. So do, when you get a vulnerability sent to you through a tool, is there a mediation guidance attached to it?

Can we save developers the effort of spending an hour or two hours going to Google, doing as much research, figuring out what is this vulnerability? How does it manifest? How do I fix it?

Am I doing this properly? Right? What can we give them right there in that moment to help them learn?

And then going even faster than that, there's inline training. So that's, you know, do you have some sort of a probably gen AI tool that's gonna give you feedback as you're coding, right? And some of those are available in various states.

So these are the three sorts of things that, um, you know, platform engineering teams need to be thinking about when they're enabling their developers, right? This is the thing that development teams need to look at. Hey, we need education.

We know we need to get better at security. How do we do it? Here's three different types that are available.

Next I want to talk about getting security up to the speed of DevOps. And usually I'll ask people in the room, Hey, how often do you release? And I presented this live recently, and the general answer I get is, you know, two weeks or three weeks and how often you release drives the rhythm for everything else you do.

And for DevSecOps, that means it needs to include security. So the question becomes how does security fit into that release schedule? And we start at the conversation earlier with metrics.

All right? So now what does security need to do? If you were to speak to a vendor like my company, these are some of the answers you'd get.

And these are really good questions to ask in comparing tools during a purchase cycle. They're good for internal requirements building, can this tool do these things for me? And you should ask these questions.

You know, these are all methods of reducing developer toil. Very important, right? Because in the end you don't wanna buy a junkie tool.

But do these questions get you to DevSecOps? No. 'cause again, DevSecOps, it's people, processes and then tools.

So when you think about speed, you need to think about it from a DevOps perspective, right? What's the business goal? What's gonna drive value?

And the business goal of DevSecOps is to quickly deliver secure features and applications. And I want you to take a second and think about how important this is, right? 77, and this is all some survey data that we've put out there, but 77% of CISOs say that at least 50% of their organization's revenue runs on application for the responsibility for protecting.

91% of organizations have deployed no vulnerable code into production to meet deadlines. And 92% of organizations have had at least one breach as a result of a vulnerable application they deployed, right? So revenue's coming in through your apps, everyone's deploying known vulnerable code and everyone is getting breached.

So the question becomes, if you grind through your DevOps processes, you release an app quickly and it gets breached, maybe your company gets fined, there's brand reputation damage and you need to maybe take an app offline for a big emergency patch session. So the question is, did DevOps work and was it actually fast or was it just fast in the moment? And I think we know the answer to that, right?

Remember the original agile manifesto was about responding to business needs, and did the business need that breach? No, it needed a secure application. So then what really is speed?

It's how quickly you as a team solve problems. It's about meantime to re remediation. It's about training developers to understand risk and about training security teams to understand how they contribute to developer velocity, right?

It's training and it's culture. It's about redefining high performing code as secure code where the biggest risks have already been mitigated. And if your organization doesn't believe this, it's never gonna do DevSecOps.

Everyone needs to be on board with everyone else's needs and that of the business as a whole. I'm gonna talk about automation last because you just can't do it very well without everything else coming together from a culture perspective, right? But everyone's got their own role to play.

Everyone's got their own little bits and pieces and we know that automation is absolutely what you need to get to, right? If you wanna reduce friction with security teams, everyone has to be going in the same direction. And again, this is the coming together of very different cultures we've been talking about this entire time.

But in the end, they're both primarily interested in what's best for the business. So the point to get to automation is to get them both thinking about what's best for the business in the same way. So let's talk about automation.

But first some survey data. We asked our group of CISOs where they were putting their security controls and you can see some red flags here, right? Raining, not a lot going on there.

Uh, go live also pretty low. So we know we as an industry need to do a better job of folding that into AppSec, but there is this reasonable bulge in the middle of our data that's around code, build, test, and deploy. It's a good place to start with automation.

And the question is what's possible? And if we line up potential automations with the SDLC like I've done here, we get lots of options. And I'll leave you all afterwards to take a look at this slide.

I'm sure the slides will be distributed. Um, I'm gonna pick a few, uh, I'm gonna pick one from each section here just to talk about examples. Um, so the first in in training is security tickets, right?

Um, that security tickets being auto-populated with remediation guidance. This is something I talked about earlier when I was talking about education, right? And that is, it's a basic automation.

Your tools can do it. Basically everyone out on the market has some form of remediation, guidance, guidance. We think ours is the best, but you know, that's my job to say that.

Um, but just getting developers right away in a ticket in their IDE, here's your vulnerability and here's how to fix it, that's a great help. That's an automation right there. Next, uh, in design phase, secure by default pipeline templates.

And honestly, this is just like standardizing your build, right? So if you do the security work back, then you get to reduce developer toil on security fixes later. If everything you're working for has been hardened to begin with, if I go to this third section, I wanna talk about fast lanes for a second, they're super aspirational and they happen when security teams and DevOps teams are really, really tightly aligned.

It's about trust in one another and in your tools. So this is essentially, um, an automatic approval to deploy to production from a security scale, right? So essentially what you've got is you've got different dev teams and they're working on different applications.

And when you get to a certain level of, Hey, I, we've built out this code, we've got no high or no critical vulnerabilities, rather than saying this has to go through all of your security processes, boop, you can you just get the okay to deploy, right? So if you're looking at, if you know it, it's essentially about removing humans from the loop as much as possible, right? You've looked at your results, you're feeling confident, why not take an auto approval, right?

If you get this, the scan, again, no highs, handful of new mediums, just deploy it automatically get there, and you can set different levels of fast lanes as you go. Um, and it takes really strong governance and cooperation efforts between security and development teams. But the more that you're able to set these up, the more that you're able to, uh, allow developers to kind of get things out into production as quickly as possible and have the security team feel confident about what's been going on.

The question is next, alright, we've talked about what can be automated, what can't remediation. You're not gonna let an outside vendor change your code. You're not gonna let it, you know, AI automatically remediate your stuff.

Yet there are limits to automation. So if there are limits, especially around remediation, what can we do to make remediation as fast as possible for developers? All right?

It looks a lot like what we've been talking about just in time training, trusted scanning, gen ai, remediation guidance, right? Production and security, uh, champions and me, right? All these sorts of cultural things and these tool things, they all come together and it's about getting developers the most information, um, that they can get.

And that last thing on there, I, I know I mentioned it only briefly, security champions, that's like its own talk entirely. Um, but if you do automation and training correctly, you can actually free up developer resources for this sort of team, right? So imagine having the floating team of developers and security people who keep an eye on the metrics, they know, hey, this team over here is having trouble, their applications are the most risky, consistently what's going on?

Send in that team to do training, to do mentorship, right? Help them, uh, for extra remediation, you know, and make loads of coding. Really get them in there and help.

And I highly recommend you look into security champion programs. There's a lot of other information out there, but I think it's an important part of the culture. I wanna end with a slide that I usually put at the beginning, and that's because you all know everyone who's watching this, you know, you're all a part of this, this evolution of application development.

Everything about your job is changing year after year. And I would say that you have an opportunity right now to think more about security, to work with AppSec teams, to build DevSecOps pipelines. Because as you look at this, if your business doesn't already demand it, with everything that's happening in your applications, your business is gonna demand it pretty soon.

So what I urge you to do is take some of today's keys concepts back to your organization. Think about how you would do your job differently if everyone believed that high performing code was secure code. If everyone believed AppSec tools were developer tools that must be part of their workflow.

And if DevSecOps was a culture problem that your organization needed to solve, because it does. So thank you all so much for your time today. I appreciate it very much and have a great rest of your day.