DevOps is Now DevSecOps | DevOps Connect: DevSecOps 2023

So for those of you who don't know, the, the title of today's event was actually DevOps is Now DevSecOps. I spoke about it this morning briefly. I have to be honest, it wasn't my idea.

I, I stole it. Um, I, I stole it from some of the companies on this panel, right? com.

Eric Sikowski sitting here was there then, right? We had a real problem. People didn't even want to call it DevSecOps.

They were calling it rugged DevOps and all kinds of things, and not real is basically what they were calling it. And here we are today saying, no, it's, it's more real than ever. DevSecOps is DevOps.

DevOps is DevSecOps. So I first heard this enunciated by Shlomi, baka, uh, the C e O of Jro at a conference called Yala DevOps. I think it was last September.

He got up on the stage and said Jro was gonna be about security because security is what DevOps is about. And then I met a woman named Ashley Kramer, I think it was at AWS three event this past December, November. And she came up there and said, look, as far as GitLab's concerned, DevSecOps is DevOps.

DevOps is DevSecOps. I've interviewed numerous people from Cloud B's and a lot of their news, you know what, it's all about security and compliance and their whole C I C D pipeline. And the software supply chain is all about security right now, my friend Kobe here from Jack Marks, he'll tell you, it's been a, he knew it all the time.

He's there 10 years. This is a panel of mostly CPOs, but I'm gonna have each of them introduce themselves and we're gonna talk about why DevOps is now DevSecOps. And if there's one thing I want you all to take out of here when you leave this and go to the keynotes and the parties and everything else this week, is that DevOps is now DevSecOps.

Well, unless some of them disagree, we'll find out. Let me introduce you real quickly to our panel though. I'm gonna start to my, uh, nearest right here, gal Mar from Jfr Gal, if you wanna introduce yourself.

Thank you gal. If we can go next. Uh, David DeSanto, uh, chief Product Officer for GitLab Test.

It does work. Shawn me, CPO cloud piece. And I'm Susie Prince.

I'm head of product for DevOps at Atlassian. Fantastic. And guys, just so you know, I don't think you're gonna see a better high, more, more high powered panel anywhere in, in RSA this week.

So thank you all for coming. So I'm going to, I want each one of you to talk about security at your company as it relates to DevOps in, in regards to this whole DevOps is DevSecOps thing. Susie, if it's okay, can you start off on your side?

I Would love to Alan. Um, yeah, so I think maybe it's unexpected to see a vendor like, uh, Atlassian up here talking about, um, dev SecOps. But I think the most important thing for us is we recognize that software development, modern software development, which is DevOps, um, is a multidisciplinary, uh, team sport.

It requires many, many crafts. And one of those crafts that has been kind of left out of the conversation as we were talking about for a long time, is security. And we really wanna enable teams security craftspeople to be part of, uh, software development and also enable the entire software development team to think about software security, um, as part of their core, core job, um, when we're building modern software.

Excellent. Sean? Yeah, what exactly was the question again?

So, you know, in terms of security as it relates to DevOps, so DevOps is DevSecOps. What, what is the cloud B'S view on that? How your chief product officer, how is that manifesting itself?

Oh, Okay. Yeah. I mean, um, so cloudy's, uh, for those of you who don't know is the Jenkins company.

Uh, we've been building c i CD pipelines since the dawn of age. And, um, as we've, uh, continued to do that, we've hit the type of scale where, you know, we've got customers, clients using, um, Jenkins for tens and thousands of developers. And we saw a shift left occur about 5, 6, 7 years ago, uh, where security started moving more and more to the left, into the C I C D pipeline.

Um, it wasn't surprising, but what was surprising was how much of a cognitive load that was creating for developers, because so much of the shift left was requiring CVE management, regulatory compliance management to become, uh, sort of the, uh, developer's job. And, uh, what we realized is that exactly what you said, which is DevOps is a multidisciplinary sport, but the team players weren't playing as a team. And so, um, what we thought about was how exactly should we as a company be bringing security left, but not at the expense of the cognitive load it creates for developers.

So we have been sort of integrating, um, security to the left into the ci cd pipeline for the last, um, I would say two, three years now, Alan. And, and, and more and more it's about how we orchestrate and make sure the security folks compliance for will work well with the developers, um, but not shift the, uh, uh, cognitive load of that to the left. Yep.

Yeah, David, So I'll keep it short cause I'm very excited about security. But, uh, in 2018 or 2019, I joined GitLab. I came from actually from a security company because GitLab wanted to introduce security into DevOps.

And so our goal was to essentially help the users of GitLab who are trusting us with their source code management, C I C D, deploying applications, even planning what they're building. And we realized that we could have this unique approach to it to help them tie security through the entire lifecycle. And so we started with software composition analysis because that made the most amount of sense for a company like GitLab.

And over the course of the last almost four years, we're now doing all the types of different application security scanning as well as the compliance and so forth. I think for us, what it really meant was how do you make security approachable to a developer? And developers don't wake up in the morning and say, I wanna write a vulnerability in my application today.

Right? No. They wanna write the best application they can, and they have to be given the right tools to be able to do that.

And so forget what, that's what security really means, is helping companies secure their software supply chain. Kobe? Yeah.

Hi, I'm, uh, checkmarks. Checkmarks is a security company. Uh, and we actually started, uh, if you're talking left or right, we started at Le Lefthand side.

I've even with check marks for the last 10 years. And since 10 years ago, our vision was that our products will actually be part of the CI c d pipelines for US security within, back then it was called SDLC or C I C D. For US, security is just like quality for software engineering.

It's the same, you cannot, you, you cannot deploy into production, especially if it works fast. Now with, uh, with, with DevOps, you cannot deploy without security because at the end of the day it will fail. So, and if you ask DevOps people today, what are the three, what are the like, top three features that you need?

Security is part of them. Okay. So security, security is part of them.

So for us, uh, security, uh, for us, security within the pipelines and pipelines is like breathing. Okay. It's, it's, it's the same.

Um, and, and what we are trying to bring is, uh, is actually a com um, a platform that will actually, on one hand can bake into your C I C D and pipelines, make your DevOps people life, uh, easy and also have a very good, uh, developer experience for, for developers. And on top of that, on developers, in order for them, you know, to cooperate, we need them to be aware and we need them to be knowledgeable. And we're bringing these tools as well.

Absolutely. Yeah. So [unknown] we started from them, obviously, and, and we're very practical about it.

We want to remove any friction that exists in the development process. And only five years ago we started with, because we failed, we're managing batteries and the flow binaries. So why we also scan them and make sure that they, they are not vulnerable, but, and there were other great companies with point solutions and different areas of the software supply chain, but after a couple of years, we figured it doesn't work.

It doesn't work because there are so many tools with so many different inputs and so many different integrations and the cognitive loads and developers simply just shifting levels doesn't work. And we ended up in a situation when our customers are sharing with us, we're applying for methodologies, all tools, but we're still stuck. We're still working very hard.

Velocity is going down and again, move to conduction. So our approach to it to stay, okay, we are managing, essentially managing the software supply chain because software supply chain is a flow of minor from left to right, lower to production. And we want to apply a very practical way to share the local skin node between the different, um, the different steps within this, uh, software supply chain in a way that will help developers do what they can, but will keep the organizations as well with the control that they need.

Uh, and we do that by having a very tight integration between the software supply chain management and the different aspects of security scheme that are applied to it. And also by, by kind of realizing that focusing on sourcing on the left side only, I'm sorry, but it's a bit naive. There are so many things that are happening as that the source progressed to a binary and binary or binaries and things are being at like configuration and, and framework and understand that, that if you don't apply the same policies to that as well, you are just working hard, being frustrating, and like the partner nines staying expos at the end.

So, so this very frustra for a long Absolutely. So look, I've been, I've been in security for a long time, 25 years. Every one of these companies up here is for pro for profit company.

They, they don't do things that hurt their bottom line. So I'm gonna, I'd like to have a conversation, not just in order. Feel free to jump in what, what's driving this, right?

So security's important to all of you now. Hallelujah. What's driving it?

Is it, is it your customers telling you, I want security? Is it the government or the eu or someone else telling you? Or are we doing it for the good of mankind, right?

I I don't buy the mankind thing. What's driving this priority for you folks? For us, what we see, what we see is, uh, two, two directions.

First you mentioned is compliance. There are customers who are doing for the compliance, but there are also customers that are coming to us and say, Hey, we want to deliver a secure software because if our software will not be secured, that will hurt us. Okay?

That will hurt us as a company because you have all these breaches, you know, from, from the data that, that we haven't collect. Like 88% of our customers say that they experience some kind of a breach. So this is, this is also one area.

One, one. The second thing, third thing is what we see is that CISO come and say, or or security people come and say, we want to, uh, we are, we also want to bring money because if we will say to our customers, Hey, our software is secure, that is a competitive advantage and we can, we can be better than our competition and actually bring revenue. Uh, we're not just DevOps and Cecil, which are spending money, we're also bringing money inside.

So these three things are driving IT, compliance, uh, developing, uh, secure software and, and competition and bringing money. Anybody else? Go ahead.

I was just gonna say, echo that comment. I was gonna say, I, I don't think the future is gonna have less compliance or regulatory requirements on companies, and they're only going to increase from where they are. So, uh, for a lot of our customers, that is the initial driver, uh, to shift left.

Uh, I think, uh, the other one is just essentially development organizations saying we welcome security left. It's not about, not, it's a novel concept, but that we can't continue to have it be done the way that has been doing right now. We can't be managing CVE storm form 25 scanners in our ecosystem that was generated because of an infrastructure change that occurred and have developers figure out how to solve that problem.

And so how is it exactly that we can get these teams to operate and work together? Um, so that's kind of, you know, where we see the big two requirements coming in and, um, uh, which is why we, we, we released our compliance and security offering, you know, just five months ago. I can talk about that later.

So GitLab, I'd say it's really three main drivers. Uh, the first was we were spending a lot of time helping customers integrate insecurity that wasn't native to GitLab. And what we realized was that GitLab is helping people write their software, build their software, deploy their software.

We have a treasure trove of data about that software application that could be helping people secure it. And so we started down that path. That was really the first driver.

The second driver is what everyone's mentioned. Our customers started saying, I need to have visibility to my software supply chain. I feel like we are not secure enough, but I can't point to why.

And so we started partnering with them to understand how can we help them get better visibility. And then the last thing I is what it, so far everyone said is compliance. I actually agree.

I think compliance is gonna be like the curse word of the year with the amount of stuff that people are trying to now add regulations to. And so when you start looking at that, you have to start trying to figure out how do you help people understand their meeting or not meeting their compliance requirements. And I think that ties in really to like, maybe the core of, of the question is that like, Glab as an application is really a collaboration tool.

Yes, it's s e i, yes, it's ci, it's security, it's deployment, but it's a place where everyone kind of comes together in the company to work on something. And so having everyone come together, security was like the next best thing to have them all come together and work on fair. For us, it was again, about the customer, what we, we saw the customers starting going towards their cost and, and we just experienced, uh, their pain.

Okay, their pain. And eventually for them, pain came from not being able to move fast. And to be honest, for many years now, everyone will say, yeah, we have to keep it secure.

But we kind of felt comfortable with not really getting into that. And we didn't stop the developers from working fast, and we didn't stay secure. Now, we all know there were a few events of, between security breaches, okay, uh, you know, unfortunately to name one, but many others started before.

And that made the security people really concerned about software, supply chain security. And then we had amazing things of customers coming to us together, CISO or manager or someone from security together with the DevOps person saying, look, we have to help us because it's either the security people are kind of giving up and saying, okay, I'm just letting you go. Or the, the r e people, the developers are saying, okay, we can't move fast and we have to find a way.

So, so it came after a few years of trying to us as a, a really authentic pain of these people that this pain makes them wanna work, work together. And, and when this happened, we figured, okay, we have to find a solution that will really help to bring them on the same page. We saw them trying to wrap around different open source tools and, and, and different stuff.

That just doesn't work. Okay, it doesn't work. It's too much, it's too much effort.

They need to have one system of record, single source, source solution to build everything around it and to have brain scanners, but integrated into that. And I think that's what's what drove us into that, of course, regulation, of course, there are many other external things, but, but if I'm trying to focus on the core and what our customers are trying to achieve, this is it, this is the main way. And Alan, I'm gonna try and say for, for the better of mankind.

Can I try? Uh, no, I think we definitely see the same things. Compliance isn't going away.

Um, our customers are demanding it. Um, and they should be. I think one of the things that we see, um, you know, to your earlier point about the cognitive load on developers and software teams, it's changing.

And the demands on those teams are very high, and they're resting us practically, like, how do I bring security into my day-to-day work? Like how do I practically address this? And so one of the things we wanna do, you know, who doesn't know a team who's not using Jira software or an organization who doesn't bring Dira software, how can we bring security into the day-to-day rituals of our team and really help them triage security, understand their vulnerabilities?

That's what we wanna do. And so, you know, helping these teams improve and, and, and get better. Um, I think that's super important and what we are seeing from our customers.

I had a comment just on what you said, gal, I would love to get your point of view on this as well, is I think the interesting part about security is that it's not like it just happened, you know, just two, three years ago, all of a sudden we decided, you know, we got a shift left. I think the movement happened way long time ago, but the challenge we see, um, a lot in our customer base, particularly as a ci cd company, is that it was very symmetrical or, or, or, or it was like left to right sort of application of rules and, and, and, and codifying it in was never a centralized way to manage, um, any of the rules and codifications and where you were putting your scanners in the pipeline, what you're supposed to do with them. And over time just managing that has become such a nightmare.

Would you agree? Or what do you think? I Agree.

Point, point. There are few things. Sometimes integration central places is one thing that prevent this from happening.

Another thing I think, and all of us, most of us mentioned the cognitive road, I think there was no focus. You know, the fact that you have a scanner and then you have an endless list of cvs and you're taking new approach of saying, okay, everything is at a CSIS score. Yeah.

Eight and above, just fix it, it doesn't work. So I think it's time to get more practical, getting more practical means yet coming with the central solution that is tightly integrated into the process and the, the, the things that you are working with. This is one thing.

Second thing is coming with, uh, security posture management in my in mind and not giving a flat least our vulnerabilities, but actually thinking what's applicable, what's not applicable, what I have to focus on next, all this kind of ne next level of features. Yeah. For the security tools, I think that what can make the difference, um, successful implementation of, uh, software supply chain security practices within the organization as opposed to just getting all the tools in and, and, and fighting with them in a way, right, without getting the credit.

Well, Alan, this is why I wanted to ask al this question, because I feel I, sorry I used the wrong word earlier. I meant to say synchronous. Um, but yeah, I feel like, I feel like for us at cloud b's I think the answer has been to shift mentality from a very synchronous mode to asynchronous.

I think the shift left forced upon the ci cd pipeline, uh, this cognitive load by saying, everything has to run synchronous scanner starts here, then the next step, then the next step, decoupling it and centralizing it and making sure that the access to actually the, the, the data, uh, that you mentioned earlier that comes out of all of these scanners, being able to understand and see them in one plane. You spoke earlier about Sbam, I loved your talk, so thank you for that. But being able to tie it back to the sbam itself is critical.

And you can't do that if you're running its synchronous mode with shift left. And that's kind of what at cloud B's we think about every single day. And what we've released in terms of capabilities is in our platform, is to say, let's decouple it.

It's still a part of the platform, but decouple it from a synchronous execution to an asynchronous mode. You also have an awesome t-shirt too, by the way. Yeah, yeah.

To your, to your point of kind of centralizing it. Uh, we also see this that peop uh, that customers want to consolidate. Meaning they want to consolidate, they need like a, a central way to control it and to get their, uh, security posture.

Um, and it was also mentioned a lot the terms of shift left and the cognitive, uh, cognitive, uh, pressure on, on developers. So what we're trying to, uh, to do in order to, to solve that is also not to shift left, but also to integrate, right? Meaning to start and bring runtime data in order to understand what is exactly, what are you exactly running in production.

And if you have a result that, or, or if you have a a, um, if you have a binary which is not actually running in production, let's not show you these results. Meaning, so this is, so I think that the next step is not, you're talking about CBE Suppression, is what you're saying. The next step is not shift left is kind of shift everywhere.

Meaning you, in order to, in order to make everything like effective, because there's also an alert fatigue, people are tired from seeing so many alerts, they just want to tell you, okay, tell me where to nail it down. Okay, what, what, what, what kind of, what to take care of? Or I'm a DevOps, tell me where to break the build when.

Okay. And in order to do that, you have to be very, very precise. And in order to increase the, uh, the preciseness of, of, of our tools, uh, when we're a secured company, um, kind of our next step, which we already, uh, started to do is, is also to bring runtime data in order to all the redundant stuff which is there in your repos, et cetera.

Let's not show it to you in, in, in, in, in the, in, in the first place. You're, you're not using it. So while we're all talking, I actually thought of something, I'm curious to get your all take on it as I'm hijacking the panel.

No, go ahead. Uh, so I was thinking about the, why is it now DevSecOps versus DevOps? And what popped in my head is that there is, there's been one change, at least I've seen.

I'm curious if all of you have seen this as well. There's been better collaboration between the teams. Yeah.

And I feel like that's kind of what's making it okay to call DevSecOps today. Cuz I, I would argue that I wasn't popular at the time, but when I joined GitLab, I said, we're a DevSecOps company. Like, no, we're not, right?

Because it wasn't the buzzword yet that it's become mm-hmm. But the difference between like five years ago and today I see a lot more collaboration between the teams and we just had our annual DevSecOps survey, and that also showed that as well in the data that instead of security people blaming developers for vulnerabilities, they were giving them credit for fixing them before they hit the security team. And so I'm curious if you're all seeing that same thing too, and if that's what's helping the, the, the drive to it's okay to say DevSecOps now we, we, We, we are, we are seeing it.

Uh, I think it comes from, from like two places. First of all, uh, as, as I think Suzy, you mentioned that, uh, you know, security is, is not a one function is, is is not, is not a one function thing. Is, is, is is a multiple, uh, it's a multiple function.

And people understand that if they will not work together today with cloud cloud native, the how fast they, they they have to move. If they will not moved, if they will not work together, then it won't work for them. So they, they have, they, they, they have to work together.

I think that there was a ladder of a advancement also in the, uh, developer's experience of the tools in the market, which also brought developers, uh, more motivation to use, uh, uh, to use. And I think that dev sec, that DevOps, because it combines between the ops and development, the two sides started to understand each other better. Meaning what, what, what are the kind of, what are the challenges of, uh, you know, operations people?

What are the challenges of developers? And they can actually, they understand each other better. So this is why I think you, uh, you, uh, wait, we Yeah.

Is exactly, I'll answer it in a slightly different way, but it's a great question. I mean, um, when we think about security, we, you know, I, I don't know about all you all, but we think about it as, you know, there's security associated with your code. There's security associated with your binary, with your infrastructure, with your data, with your asset, with your identity, with your login.

And you step up from that a second and look at each one of those categories and you go, there's different teams operating, uh, and doing work in each one of these areas. And they're all changing the environment, variables and vectors. The one thing common among all of them is the code.

It's the code that you're writing that works across all of them. And so, um, for us, SEC became, okay, once our customers came, became, came to us and said, you know what? It's now our DevOps teams actually saying, come closer, come hither.

Because we cannot continue to have a developer write a piece of code. It sits in a ci cd pipeline, uh, it's in a queue for a release. And at the end, you know, uh, when that software is released, all of a sudden some CV alert goes off, something is wrong.

And now you've got a team scrambling trying to figure out when was this code written? By whom? When did the scan run?

Wait a second. Is it the infrastructure and the ops people going, no, it's you. Has anybody seen that?

The, the, the, the the spider-man picture? It's you. No, it's you, it's you.

And it's, it's, that can't exist anymore. So the whole topic of asynchronous centralization, security being okay, I think is actually, um, uh, in a weird way, um, thanks to the DevOps teams through the practice and the people saying we welcome. Um, but it certainly wasn't that, uh, in the start.

I felt like, I dunno if anybody else fills in well On, we haven't given su Susie do you have, We've given Susie two mics. Oh, okay. Give her two Mics.

Yeah. Okay. Um, uh, I, I, I agree, David, I think you're right.

I think the, the angle that I was thinking about is, um, it becomes okay to say it, um, and say that it's DevSecOps when the business people, the product people, this is a part of what they are considering to be high quality software. It's no longer this technical domain that's like, you know, I've pushed it and it's gonna be sorted out by some unknown team somewhere. Um, or even by a third party, you know, who's gonna be testing it after I've deployed it?

This is something that we see our customer business teams, our customer product teams are demanding, um, out of high quality software. And I think that's when it becomes something that we should all be talking about. So, yeah, I agree.

And now I have two, Now you have two. Michael, give one to Sean. Miguel, you want to say some?

Yeah, so I, I agree. I agree as well. I think it's, it's, the problem became painful enough that it became a business problem just as, and then, and then obviously the motivation came and people are coming, coming together.

But I think this, this puts us as mentors in a, in a different position. I think the responsibility is now on us when, when our customers, before we can kind of make it on them, okay, they don't want to do it, this is why it doesn't succeed. Now when, when the motivation is there and, and they, they're working together, it takes on us to provide them with the tools they, they need, uh, in order to be successful with their mission, that they're really, uh, willing to, to, to invest in.

And I must say that, that I think that, that, that, that we still have a gap. And, and for me, as I said, the gap is focus on being practical and not just showing one side of what's wrong with security or why it can't move. And the second thing is putting everything on one platform that handles both security and DevOps under one.

How you make Fine. Excellent. You know what, I'm afraid we're gonna run out of time and we already have at least one person.

So if you don't mind, I'm gonna let him ask his question and if anyone else has questions, please get to the mics cuz we're, I'll do my best. Go ahead. Thanks for the panel.

You guys, uh, represent an important part of some very important vendors. I appreciate you being here and talking to us. Um, integrating scanners into pipelines is great.

Um, but we know that one of the big problems with security in general is just that we tend to have a lot of tools that tell us, right? And if you ask a lot of people, what is security? I run a tool, it says that something's been found, then I go fix it.

That fundamental understanding of how the software works, what it's supposed to do, isn't there. A big part of the DevOps journey for us between dev ops was really getting to understand each other, not just adopt each other's tools. That was a big part of it.

Sure. But it was actually understanding what is it that we're actually trying to do and how do we get together? And it was a bi uh, bidirectional communication there.

You guys are in the middle of this process and, and are a really great place to be able to help us to bring people together to actually understand what their software does, how it actually works to meet those needs. Especially in a world where most people don't understand how the, the stuff works fundamentally right on the dev side, on the op side. And it's getting worse now that chat, G P T and other AI capabilities are gonna start writing most of our code, right?

It's just a reality. So they're, you're gonna have even fewer people in the organization who understand how any of it works. Just that it does.

So what can you guys do in your products in order to allow people to come together to actually understand the software better, not just run tools against It? Yeah. So, um, great question.

One of the things I think critical and crucial for us was exactly what you said, the, the, the learning that you get between the teams as you are discovering these vulnerabilities today. Um, as an example, we use the NIST standard and that was important to us because first of all, if you're gonna have a language, you need to speak with people, you need to have a set of framework that you all agree to. NIST was one that we just picked and felt that was the right one.

Second, by integrating G P T into it, as we are finding errors and challenges that are occurring in the code, we are using large language models to produce back learning modules and or correctional facilities back to the developer or to the user that's within the product whose responsibility is to fix something. So generally speaking, uh, topology of the software, or in this case the material is a critical aspect of what we do. We use the bill of material, we used it to essentially the topology of the software organization to say, if there are three people that are working on this, you have maybe a org model at the top, you have project second, you might have application, you might have microservices.

You have multiple number of people that work at in level of these apology. So we, we sort of surface from G P T when an error occurs or finds examples of what may have gone wrong and what examples of what right looks like. We surface that up to groups within the product itself so that groups can actually have asynchronous conversations over Slack or within our product itself, just to learn from the example of what needs to be fixed.

That's just one way of co-learning together, which I think is gonna be critical because I do believe that cognitive load is when exactly what you said, when the members of the team have no clue what's happening and they feel the burden and responsibility to go fix it. And I think generally speaking, that's what everybody does. Nobody wants to leave it running poorly.

I'm gonna leave that as one answer cause I we're over time and I gotta get these people. And ma'am, would you like to Certainly, um, I actually was gonna ask the same question he did earlier, but it's a really good answer. And yeah, you gotta get them to learn the security and what's important, but there's also, when people talk DevSecOps, and I've been a journalist in this space for about as long as Alan has and, um, the sock side, the ops side.

So to me, the operational side of the development team itself, like in SolarWinds bad password led to what happened at the binary scanner, right at the binary, uh, part where the, the code was being assembled, there was a bad password. Who's talking to them about their operational environments, making sure that where they're developing the code is secure, not just we have tools to make sure that you're being scanned in, scanned during your life cycle and development stages and at binary and, you know, maybe even purple teaming afterwards. But what about the operational environment for the developers themselves?

Because to me as a journalist, that is the interpretation of DevSecOps to me. It's the plumbing, at least what we're trying to do is, uh, is two things. First of all, uh, awareness and also, uh, enablement and, uh, and teaching, teaching the developers or, or, uh, teaching the developers how security should, uh, should look.

Okay. We, uh, we do have a product for it, which is called code bashing. Uh, through it you can, you can first of all your, um, your developers and, and your other teams, uh, ops teams can actually learn about security and what is application security.

Um, and this ca you can also use it, uh, in order to, uh, you know, raise, raise the, uh, uh, raise the, raise the awareness, uh, the, uh, also the platform is, uh, flexible enough. So, uh, you can also upload your own content. So, uh, if a customer has their own content of, uh, of teaching, of teaching or, or enabling or or training developers, they, they can do that as well.

So this is what we are, uh, we're, we're actually doing in order to, uh, in order to provide a solution to, to what you, to what you raised. I, I'm the author of something called the DevSecOps Playbook. So you can imagine that I have strong opinions on what DevSecOps is.

No kidding. Should we run from the stage right now? Run, Run, run.

We've run outta time. Um, the reality is that I, unfortunately, I think a lot of vendors and, and you can make this argument for GitLab, are defining DevSecOps as a small thing just around source code. But the reality is the applications we're building and deploying, they go into the cloud, right?

They're consuming things outside of source code. And so we've got check marks up there, we've got GitLab GitLab up there. Can we talk a little bit about let's the other parts of the DevSecOps lifecycle that need to be addressed as well so that people really understand what the scope of what they have to work on is.

So that's love it. Thanks. So I, I will say first apologies, that was not my intent to say we only secure source code.

So, uh, in fact, you're touching on why I thought it was important for me to come to GitLab. So security is something that if it's not built in from the beginning and goes all the way through, the entire lifecycle is not gonna be successful. And so you can almost tie the three questions together that you've all asked, because really the, the challenge when you're talking about securing is it's about the application and production.

Are you giving the tools, the operations team to understand something occurred and they need to look into it? Or, and that doesn't have to be a scan. We've talked a lot about scanning, that could just be alerts, right?

Something suspicious occurred and then you have the tools to do that. To your question, you're right. If it's not the entire thing, you're not gonna be securing yourself, right?

Because you can scan it all you want in the development side, but sometimes vulnerabilities only show when the application's actually running. And that kind of fits into the, the question about chat G p t as well. I, I think what sometimes we end up doing with, I'll call it chat gbt a buzzword cuz it kind of has become that, um, Code generation is only about 20% of the software development lifecycle.

So if you're applying AI to just generating code, you're not empowering the rest of the organization and be successful. And that kind of, again, fits into your question, right? If you're applying AI in a way that helps someone understand the vulnerability, they can fix it better.

If you're applying AI potentially to how monitoring alerts in production, you might be able to find that needle in the haystack. And so I, I think the root of your question is, we've talked a lot about the scanning part, but there's a lot more to security. If you're not doing the entire thing from planning to running the application production, you're only as secure as the last thing you scanned.

I just that in two words, I think yes, if you're not scanning, if you're not doing two things, scanning their binaries at later stages, you're just not scanning at least half of what's running the production. So definitely you're not, you're not being secure. Second thing is we, we keep on, I think forgetting that software supply chain security is about scanning what's going in production, but it's also about protecting the process itself.

If, for example, I'm scanning something, I'm sending everything and getting great results, but I cannot ensure that the same piece that I actually scanned in the middle of my C iic D is the one that is actually going to production. And I don't have that be attestation to that. And I don't know the providence to, to every piece of software, which is not about scanning, it's just about keeping track metadata and, and digital design things.

I'm also not secure because a minute after the scanning, someone can inject, uh, something else. So I totally agree. This is exactly why I think a solution must be a combined solution between what drives your releases to production kind pipeline.

And instead of scanners that are attack integrated together, it cannot be either one and it cannot be a scanner that focuses on, on one side, on the I I also think the tools on their own are, are not enough. Meaning you have to, you need tools and you need best practices and people that know how to apply the tools. So, uh, so at least we, this is what we're bringing to our customers, not only the tool, but also the know how, how to deploy them, and also also integrations.

Okay, how do I take my threat modeling if threat modeling and how do I, uh, how do I impact the threat modeling? Uh, how do I, uh, how do I better customize my scanners to, uh, um, to, to actually to, to, uh, to scan for the threats of that specific applications? Okay.

And, and that, and by the way, and that get me done. Okay. So, so as you say, it's something comprehensive.

It's not only tools, it's also, it's also the know-how on how to deploy them and how you actually, um, work from the threat modeling to what I said before, to runtime meaning how do you also bring runtime, uh, runtime data into it. So given the answers to all these questions, also the, the mention of kind of shift everywhere integrate, right? Does this kind of destroy the, I guess the discipline or profession of vulnerability management, does that just become subsumed by the DevSecOps DevOps profession?

I, I think very simply, I think no. Um, I think that as you bring all these teams and tools together, we're not saying these disciplines are, you know, obs we don't need 'em anymore. I think actually more importantly, this is when we need those core skills and crafts brought together to enable the whole team.

And I think that's how we see, it's how I see it. We're not gonna get it, you know, it's impossible for us to do it alone, but together we're all gonna do it. And I think that the most important thing is that those crafts and skills are not lost, but they are brought together to, with the whole team, um, to enable everybody to understand why it's so important.

This one's working if anybody else has announced. So I, what I would say is, I, I think the role of vulner vulnerability management has become mission one in the conversation today. Vulnerability management isn't just triaging vulnerabilities in development, it's also about triaging vulnerabilities in production.

And when you don't kind of lead with a, I'll say a vulnerability management principle in DevSecOps, it comes very hard to manage to the points earlier about there's so many vulnerabilities, what do I look on? Look at first. And so it's not just an application, it's a process and it's something the company has to define for themselves.

But, uh, I don't think it, it's lost. I think it's more, it's kind of how you title together. Uh, I think vulnerability management is starting to transform into, uh, into security posture, which is, which is what is really what is kind of really important, uh, because of the DevSecOps, because you have to take very bold and, uh, bold decisions a lot of time automated.

So you need to know your security posture. So the vulnerability management is, I think is actually turning into, into that May agree. I would say that that work management can be automated later.

Not, not all of us, uh, but every security posture is more that, and people can become more efficient with it, but they don't think we can give up. No, no responsibility. All security tools never die.

They just fade away. But I'm gonna ask Mark Miller to come on up here while my panel goes down so we could wrap up the ninth annual. Thanks for coming, everyone connect DevSecOps.

Thank you everyone. Right? For those of you who stayed here, did the bitter end, we appreciate you.

We've had about 700 people here today, believe it or not, throughout the day. So I was looking at the scanner numbers, so I appreciate all of you coming down. More importantly, I hope, I hope you found these sessions worthwhile today.

I thought they were amazing. Hey, how about a big thank you for Mark, because he puts the speakers roster together, man, I, I think mainly the concern that we wanna make sure is you're walking away with something you can use. That's the big thing about doing these things.

So thank you for staying all of you. That stayed the full day. Thank you for those that just came this afternoon.

Yeah. But in general, we'll see you next year and it looks like it's gonna keep growing, right? I hope so.

Thank you.