We know there’s tension between security teams and developers. But where does this tension start? Is the constant friction between developers and security teams is a leadership problem disguised as a team problem?

Check out this post for the discussion that is the basis of our conversation on this week’s episode co-hosted by me, David Spark, the producer of CISO Series, and Steve Zalewski. Joining us is our sponsored guest, Matt Brown, Solutions Architect, Endor Labs.

Join the conversation on LinkedIn

Huge thanks to our sponsor, Endor Labs

Intro 

0:00.000 

[David Spark] We know there’s tension between security teams and developers, but where does this tension start? Is the constant friction between developers and security teams really a leadership problem disguised as a team problem? 

[Voiceover] You’re listening to Defense in Depth. 

[David Spark] Welcome to Defense in Depth. My name is David Spark, I’m the producer of the CISO series, and joining me as my co-host, it’s one of your favorites. If it’s not one of your favorites, then you’re not enjoying half of our programming, and it should be one of your favorites.

It’s none other than Steve Zalewski. Steve, say hello to the audience. 

[Steve Zalewski] Hello, audience. 

[David Spark] And as we have said before, if you see Steve in person, he responds warmly if you go, “Hello, Steve.”

[Steve Zalewski] [Laughter] 

[David Spark] So, feel free to do that. Our sponsor for today’s episode is Endor Labs, multiple AI agents, one force for AppSec, zero distractions for developers. They are sponsoring this episode, and they brought our guest today. But first, let’s talk about the topic at hand I teased it at the beginning of the show, Steve.

Here’s the issue. What are the structural issues that cause tension with secure software development? We’ve talked about this endlessly on our programming. Does it come down to security being seen as a roadblock to developer productivity or does the conflict start from the very top all the way down?

What do you think, Steve, from your experience? 

[Steve Zalewski] Yeah, when we put the post out there, that was my premise was, okay, let’s take a step back and look at it from a different perspective of not the friction between AppSec and AppDev, but are we fundamentally, from a senior management down perspective, not characterizing this problem correctly that we can’t seem to solve it?

[David Spark] This was explosive. I mean, there were almost a hundred comments on this and lots of shares. This is definitely hitting a nerve because I will just say, traditionally, we just see, oh, it’s just developers acting whiny and security teams nagging them, and there’s more to the story, isn’t there, Steve?

[Steve Zalewski] There is. And the other thing is there were 15,000 views of this post. And so, again, we hit a nerve. A hundred responded, but there’s a whole lot of people that are pondering this problem as to how we get it better, either to build better technology or recharacterize how we move forward.

So, that’s why I was kind of excited for this episode as that’s, I think, what we’re going to explore. 

[David Spark] And I’m very excited to bring our sponsor guest on because actually, it was through a discussion with him that this very topic came up. So, he is perfect for this discussion. It is the solutions architect over at Endor Labs, none other than Matt Brown.

Matt, thank you so much for joining us. 

[Matt Brown] Thanks for having me, David. Appreciate it. 

What is everyone complaining about?

2:54.803

[David Spark] James Jardine of DevelopSec said, “We have always struggled from the disconnect between security and development.” All right. So, he goes through a process here. Listen up. “Security, early on, said they would do security. Don’t worry about it.

Then security built tools without development input, created policies without development input, built training programs without development input, and set expectations without development input.” Seeing a pattern here?

[Laughter] 

[David Spark] Hold on, James goes on. “There might be a theme starting to form there. They tried to correct this with the idea of champions. What would happen if we put the control in the hands of the developers to solve these problems security wants solved?

What would your SAST setup look like if security gave the requirements but left the implementation to the development team? The part of the business that are focused on engineering solutions is often the first team left out of security solutions. Instead, teams that aren’t involved in those processes try to push tools that don’t really fit those processes into the mix.

Might be time to start thinking about a development-first view on application security and see where that gets us.” Very interesting. All right. 

Andrew Wilder, CSO over at Vetcor, said, “AppSec is hard because we’ve spent a decade telling developers to think like hackers when their job is to act like builders. We don’t need developers to be security experts. We need security experts to build better tools that make it impossible or very difficult to do the wrong thing.” All right.

Steve, in both of these quotes, they’re pretty much saying, hey, the problem comes from the beginning of this whole process, not shift left. It’s just the way the whole dynamic of production began, and that could be a top-down issue. Yes, Steve? 

[Steve Zalewski] Could be. But I think we want to take a step a little bit further back, which is we’re talking about, again, AppSec and AppDev. The business, ultimately, is the one that’s paying the bill. So, if we take a step back there and go, look at the line of business, look at the people that run the business that have hired the developers that security is trying to work with.

And so, to a certain extent, I say how does the business see security relative to selling more jeans? And that’s what I said is let’s make it a higher management conversation because if they don’t see security as important, and if after 15 years of us telling them that it’s important, maybe it’s time for a different message.

[David Spark] All right. I am throwing this over to you, Matt. I like the setup of all this. It’s just like, hey, it’s not like this happened overnight. We were building it this way, weren’t we? 

[Matt Brown] Right. There’s a lot to unpack here. So, a couple of these comments were like, oh, we got to think about tooling, tooling, tooling, right? Make it easier for developers to use the security tooling, whatever have you, right? Sure, that’s a big chunk of it.

The other big chunk of it is a cultural thing. And if somebody in management or whoever is saying security isn’t important, it is very important. What’s more important is fixing the right stuff. And what does that actually mean? Developers, what do they get paid to do?

They get paid to build cool stuff, to innovate that ends up beating competition, innovating, and making new products so that the company makes money. That’s really what developers get paid to do. That’s their main responsibility is to build. Fixing vulnerabilities is not part of their main responsibility.

At least that’s a lot of people don’t get into development to say, “Oh, I want to fix a lot of vulnerabilities.” Maybe an AppSec engineer or something like that, sure. But it’s a cultural thing to say, and you heard it here, “Hey, we didn’t include our developers.

We didn’t include the development team. We didn’t include the people that are actually building the stuff into these decisions from the get-go.”

That affects the business because what ends up happening is we buy these security tools that we don’t get input from the development team from. It slows the development down. It slows innovation down. It slows features getting built and pushed out to prod down.

Everything gets slowed down and you end up losing money from it. You end up losing revenue from it. It’s super important to have not only good tooling, but also a good culture and good practice and good mentality on both teams, security and application development, to really be able to not slow development teams down and for also development not to, I don’t know, slow security down, but to make decisions or choices that could introduce risk to the business because.

So, it’s almost like was it the snake eating the snake in the circle, right? It’s almost like that, where you kind of got to break that out and say, okay, how can we involve each other in this? Because developers want to build cool stuff, but they want to do it in a good and secure way.

They don’t want to introduce vulnerabilities. But when you’re getting told that then, hey, it will slow things down. 

[David Spark] Steve, go ahead. Do you want to jump in? 

[Steve Zalewski] I was just going to say where I get from this is the business is like the parent. Security is brushing your teeth. It’s a hygiene issue, fundamentally, so we don’t get cavities. Well, the dentist tells us to do it. We don’t. The parent keeps reminding us.

That’s what I’m getting at which is where’s management? Where’s the parents in all this? Because we don’t seem to have a successful kind of relationship between the three, and that’s why I’m taking a step back and saying, okay, we get it. Exactly what Matt said.

Talking about it some more isn’t going to fix it. How do we recharacterize stopping a helicopter parent, start being an experiential parent? Let’s feel a little pain to have the business practice security and security to also understand what is good enough.

Why does this still happen? 

8:55.126 

[David Spark] Ezra Ortiz of Peraton said, “Developers don’t develop for security, they develop for functionality. Is it a today pain or a today value? This is a strategy from a leadership perspective. If you start with the problem, use the why model to get to the root cause, most of the time it comes down to leadership.

Minimum viable product is fine for features. MVP is not fine for trust. Ultimately, trying to address all problems is the wrong approach. Identify addressable problems or non-negotiables.”

And Daniel Frye of BreachRx said, “The brutal truth is that nobody wants to patch.” Alluding to what you said, Matt. [Laughter] “It’s overhead and drag on the work that both dev and security want to be and are incentivized to be doing.” Oh, my God. I strongly agree here.

He goes on to say, “Following the shift left doubles down on the drag for dev. Kind of how like 2FA, two-factor authentication, doubles down on the drive for user authentication. So, feels like resistance there is natural. I feel like AppSec is an area that’s ripe for automation, AI, whatever you want to call it.

AppSec is a class of work that takes away from more meaningful work for both dev and security. And tools are starting to arrive that can measurably reduce the amount of time spent. Rather than solve the problem, remove the root of the problem entirely.” 

So, I go back to the sort of the beginning of what Daniel said and also talking about like what pain to deal with. What we’ve kind of all been saying is if your job is to do X and you’re being measured on your performance at X and someone asks you to do Y, that takes as far back a seat as possible.

And we’ve seen this in sales. We’ve seen this in product development. We see it everywhere. So, if you want people to do Y, make it part of the job and measure their performance on it. Yes, Matt?

[Matt Brown] I’ve always been an advocate of having vulnerabilities fixed or something like that, like impactful vulnerabilities fixed as part of almost like a bonus structure. Like if you want people to get something done, pay them for it kind of thing.

That’s one way to do it, sure. That’s a pipe dream, in my opinion. But how many times have we already heard shift left in these first few comments? I think like at least twice, maybe even three times. Everybody says, “Oh, shift left, you got to bring it to the developer at their workstation or at their laptop.” And sure.

Do you want to know what the most developer friendly thing is? The least amount of JIRA tickets for vulnerability issues or no JIRA tickets for vulnerability issues. And the first commenter here said it like fixing all the problems is wrong, is so wrong.

Because let’s be honest here. Let’s take SCA, Software Composition Analysis, open-source dependencies. There are so many CVEs in that. How many are actually dangerous? When you kind of take a look at your whole production, your whole SCLC, there’s really not that many that are actually a threat because you have so many controls in place.

So, instead of sending me a list of 6,000 CVEs in a spreadsheet or 6,000 JIRA tickets, send me the 6 issues I need to fix because they are critical, reachable, fixable, have an EPSS of this, have this, have that. At that point, it’s no longer a vulnerability, it’s a bug or a defect, and what do developers love to do?

Like to fix bugs and defects. We want to ship good code. We don’t want bugs and defects. So, just tell me the things I should and absolutely have to fix. We’ll fix them. 

[David Spark] Let me push back a little bit on that. I know pushing the 6,000 list is easy, but how difficult is it to find that 6 that you refer to? That doesn’t seem like an easy task. 

[Matt Brown] It’s not. [Laughter] 

[David Spark] So, where are we coming up with and how are we determining what are these six we have to fix kind of a thing? 

[Matt Brown] This is a very corny term, but I like to look at it as like the pillars of prioritization or the pieces of the prioritization puzzle, right? Alliteration. You have to evaluate the risk. So, can I even fix it in the first place? What’s the severity?

Does my code that I write actually call and reach the vulnerable code that’s in that open source dependency? Is it a true positive or a false positive? What are the breaking changes if I do fix it? Like what’s it going to cost to actually try to fix this?

There’s so many things that you could take into place, even more downstream. Oh, do I have a WAF enabled more later downstream that even if my code was reachable and all these different things, we have a WAF that’s in place that we can go ahead and look at, and that’s another mitigating control?

So, it’s hard to do. 

Software is very complicated. People go open an app on their phone, and it works, and “Oh, my gosh, this is amazing.” Nobody ever says like, ” wonder how complicated this is to run.” It is so complicated and so many things can go wrong. So, that’s why we got to kind of figure out, well, what are your risk mitigations?

How do you prioritize? What do you want to prioritize? And it’s like, hey, instead of this huge list, here are the things that actually matter because they meet our risk criteria. 

[David Spark] All right, Steve, I’m throwing this to you. Some really good points brought up in terms of figuring out what those top six are and that this is kind of a top-down approach thing, how are we going to measure this? 

[Steve Zalewski] So, I agree with everything that Matt said in our challenge here, but I’m going to say, but we’re looking at the wrong problem now. And here’s why I say that, which was you’re trying to find the right six. Well, look at how application development has changed even in the last 36 months.

Okay? We used to write the code. We used to then analyze the code. We changed small amounts of it with functional improvements. 

Look at how Matt develops code now. He basically incorporates libraries. He uses AI to write a whole bunch of code and cobbles it together as opposed to develops it. So, third-party and fourth-party risk for vulnerabilities is not that we have control over the code that we’re writing.

We only write 20% of it. It’s the 80% that we’re incorporating that’s outside of our purview is where most of the problems are now showing up. That vulnerability management and patch management becomes incredibly difficult. And so, that’s why I say let’s go back up to the executive team because we fundamentally changed the way that developers develop, and in doing that, we’ve incorporated a set of risks we can’t currently manage and now let’s understand how we put a defensive perimeter around that process.

Sponsor – Endor Labs 

15:49.431

[David Spark] Before I go on any further, let me tell you about our spectacular sponsor, and that would be Endor Labs. Now, Endor Labs helps organizations secure the modern software supply chain, exactly what we’ve been talking about today, by focusing on what actually matters – exploitable risk.

Just any risk doesn’t matter. It’s what can be exploited. So, as software teams increasingly rely on open-source cloud-native architecture – geez, what Steve was just talking about – and now AI-generated code, traditional vulnerability scanning creates overwhelming noise without clear prioritization.

Endor Labs changes that. Built by industry experts in open-source security, Endor Labs provides a dependency-centric approach to application security. 

This is the keystone of it all, people. Their platform analyzes how software is actually built and used, identifying which dependencies are reachable, exploitable, and truly risky. Ah, there’s your triumvirate. So, security teams can focus remediation efforts where it counts.

By combining deep dependency graph analysis with runtime context and policy enforcement, Endor Labs enables engineering and security teams to reduce risk without slowing development. That’s our goal here. As AI coding assistants accelerate software creation, dependency sprawl and hidden risks grow even faster.

Endor Labs is purpose-built for this new reality, helping organizations safely adopt AI-powered development while maintaining strong security posture and developer velocity. You need to learn more about this. You got to go to their site. Go to EndorLabs.com.

This is not just a security issue. 

17:37.256 

[David Spark] Greg Notch, CSO of Expel, said, “The problem is rooted in economics and incentives.” Ooh, this came up before, let’s hear it again. “Engineering organizations are funded, tasked, and measured on shipping features that deliver outcomes. If you’re selling software and business side has little incentive to fund AppSec because they have already externalized all of that risk to their customers with limitation of liability clauses,” good for them, by the way.

[Laughter] 

[David Spark] Going back to the quote. 

[Matt Brown] Yeah.

[Laughter] 

[David Spark] By the way, let’s just stop the quote. If you can pull that off, none of this is important. 

[Laughter] 

[David Spark] None of this is important. Going back to Greg’s quote. If you’re developing software for internal customers, there is even less incentive to care. The core problem is that there is very little real downside risk, except in extreme black swan type situations, and the probability of that is low enough, most will accept the risk and probably have a completely rational argument for doing so.

This is hard for security people to hear, of course. The extreme example of this is the proliferation of vibe coding. Literally no one on the business side cares that it is introducing security issues if the marginal cost of software development drops precipitously and the shipping velocity increases at the same time.” That’s a great quote, but I’ve got two more for you.

Andrew Livanos of Wiz said, “It’s usually about incentives and visibility. Giving teams ownership of their part of the environment with enough context to understand real risk tends to change the dynamic.” And lastly, Matthew Zhou of PolarStar Cybersecurity said, “The problem isn’t engineering versus security.

The problem has always been security. Security teams across the industry do not consistently align their guidance with the objectives of the business,” kind of alluding to the very first quote we read here in the top of the show. “Engineering team success is based on their ability to deliver value to customers.

If security practitioners can consistently make that link to why security matters to the business, and therefore the outcomes of engineering, then the friction becomes alleviated.” Steve, I love all these quotes. I mean, these all hit a major nail on the head here.

What’s your take? 

[Steve Zalewski] I really like this one, and this is under the it’s not a security issue. Okay? And I agree. Now, here’s the way I come back to it is something you said when you were doing the indoor thing, which was we have to embrace AI-powered development in conjunction with all of the third-party code development.

That is how development is fundamentally changed. And so, development in doing that, we have to adapt. The business has to understand what risks are reasonable, because I agree, many of them can be ignored. And security is still trying to push the old way of doing business.

So, what I love about those three is you have got to incorporate all three of those in rethinking with the executive team how AI-powered development and the adoption of all of the third-party open libraries has fundamentally changed how the business develops an app, citizen developer.

Let’s have that conversation. Now, let’s try to put a protective envelope around it, and we’re going to make progress. 

[David Spark] Matt, I’m throwing this to you. These quotes kind of hit a lot of your hot button issues, kind of like what I was just doing in the read, doesn’t it? 

[Matt Brown] Yeah, I’m glad to see that the real practitioners agree with me on this. That’s always comforting to see and have my thoughts validated every once in a while. 

[Laughter] 

[Matt Brown] But it’s true. And I love, Steve, that you’re saying, okay, the third-party libraries in conjunction with the AI code that’s being generated. Guess what all these LLMs are trained on? Open source code. That’s why we have CVEs in the first place, kind of.

We have to keep this stuff in mind. And at the end of the day, whether I write the code, you write the code, or AI writes the code, code is still code, right? Except for me, I know, “Hey, I probably shouldn’t do that,” where AI says, “Well, I saw this in an open source project one time, and it makes sense to use it here.

So, I’m going to go ahead and use it anyway.” 

The fact of the matter is not only are you going to be getting code written by AI, you’re just going to be getting more code, more slop, more stuff that you got to keep an eye on. And we have to be able to really filter that stuff down and focus on, okay, yeah, we got a lot more, but still, once we kind of sift through everything, this is what we really do need to focus on.

It’s these particular types of issues. And deliver those to the developer with the confidence, context, and information that they need in order to actually properly implement that fix easily as well. 

[Steve Zalewski] Okay, I agree. Okay?

[Matt Brown] But. [Laughter] 

[Steve Zalewski] In a perfect world…

[Matt Brown] Yes. 

[David Spark] Well, I mean, he did map out a perfect world. So, why can’t we have a perfect world, Steve? 

[Steve Zalewski] Right.

[Matt Brown] Yeah, cone on.

[David Spark] [Laughter] 

[Steve Zalewski] If you do what I say, then you’ll be secure, right? All you have to do is do what I say. Part of the challenge we have here when I introduced AI development and third-party code is you, the developer, don’t actually know what the stuff does.

So, when you’re presented with the opportunity that says there’s a vulnerability here that we want to fix it, you don’t necessarily understand the functional implication of that fix that security says you have to do. We have lost the fundamental discipline that the engineer knows what they’re doing, he developer, and we’re relying on AI to be able to do it, which means we’re going to have to rely on AI to augment the developer to know how to protect it.

Because the developer isn’t in a position to make an intelligent decision because he doesn’t understand how it functions anymore, which is a very scary statement to say, but I think that’s why we’re getting back to the from the top down. We have to re-evaluate what our true capabilities are as actually being an app developer and actually if you look at what the security perimeter is.

Would this work? 

23:55.776 

[David Spark] Shawn Kahalewai Reilly of SAP said, “Focus on velocity. The requirements need to be met, but the implementation patterns we use commonly disrupt velocity. If you introduce disruptions to flow and speed, then you have an anti-pattern that will cause people to become upset.

If you focus on a problem specifically from the perspective of velocity, you start with different objectives and often you get different results. We don’t want to make things more secure. We want to make them more secure and faster and easier.” Well said.

“When someone feels like you have made their life easier and saved some pain and made things faster, you get instant adoption, and this is the path to harmony.” It’s an interesting take of if you make everyone’s life easier, who’s going to complain?

Right, Matt? 

[Matt Brown] I’ll tell you exactly this is what would happen to me. All right? When I was a developer, I would literally get a spreadsheet. This was years ago. I won’t say how many years ago. I won’t give my age that easily. This is years ago we’d get a spreadsheet, and I’ll never forget the 6,183 rows in that spreadsheet of just CVEs.

And I’m looking at that like, what do you want me to do with this? Honestly, do you want me to go through these and to try to fit? “Well, we have to do it for compliance reasons. Can you just do it quick?” I’m like, “I won’t do anything for three months.”

[David Spark] Can you just do it quickly?

[Matt Brown] So, we had to say like, “No, we cannot do this,” right? There’s just no way. We can help. We’ll try to help, but we have all this other work to do. So, a couple months go by, went through the whole list. Okay, 6,000 of these CVEs. “Sorry about sending you this list, number one.

Number two, here are the 15 that you actually have to fix. Here’s why you have to fix them. They’re critical, reachable, our code calls it this way, plethora of reasons. Here’s why you have to fix them, here’s how you fix them, and we also just did the work for you to tell you if you make these fixes, it will not break your code.

Can you please fix these?” At that point, we’re like, “Yes.” 

There is no reason not to fix them at that point, when you have all that information and context. That’s the work you have to do if you want to actually focus on what matters and then deliver it in a nice package, like a pull request to a developer where they live in GitHub or GitLab, whatever.

And then things get fixed at that point. Because at that point, it’s like, okay, these are real. These are serious. I’m not just going to sneak my way around and still push to prod. That should never be the reaction to a broken build in CI because of a security issue.

The reaction should be, uh-oh, my builds don’t usually break because of a security issue. This must be legit and this must be a real problem. I should fix this because it’s rare that it happens. And by the way, here’s the fix. Here’s all the information.

[David Spark] That basic philosophy of it’s reachable, it’s exploitable, this can be a problem. I mean, what else do you need to know, Steve, than that? 

[Matt Brown] Will it break my code? You need to know that too. [Laughter] 

[David Spark] Yeah, break the code. That too.

[Steve Zalewski] Here’s what I totally appreciate what Matt just did, and I’m going to call out my security brethren as the security guy, which is what Matt said was making it more secure is not what we should be doing. We need to make it secure enough to make it faster and easier.

Our obligation as a security practice is not to show you more problems and have the developers somehow figure out how to parse through it. We have to take accountability. We have to own the problem. We’ll tell them, “Fix these eight and leave the rest alone.” So, until security steps up now and says, “We will take the risk of telling you which ones to fix and why,” we keep dumping it on the developer to go ahead and try to figure out what to do, and therefore we get to blame them.

And that is the root cause of a problem. 

[David Spark] Very well said, Steve. 

Closing 

28:16.737

[David Spark] All right. This comes to the portion of the show, Matt, I’m going to be throwing this to you first, where I ask you, which quote of these was your favorite and why? And there’s a lot of good ones in here, so narrow it down to one. 

[Matt Brown] It was that first one, the very, very first one by James, DevelopSec. 

[David Spark] Oh, where he spelled out the fact that security did all this stuff with no input from development. 

[Matt Brown] Yeah, exactly. Because it’s so true. I can’t tell you how many people I’ve worked with where a new security leader comes in and is like, “Yep, I just walked into this and I’m trying to put together an application security program.” And the development team does not like the security tooling at all, and it’s because they weren’t consulted with.

Nobody asked them, “Hey, what do you all think if we do this? What do you folks think? How should we?” They just did it and was like, “You have to fix this.” Nothing got fixed ever, and that’s why security tools amongst developers get such a bad rep because they’re not involved at all.

Like any time I work with a customer and we do a proof of concept and there’s not a developer on the call, I say, “Where’s your developer? Where’s your development team? Bring them in. I want to talk to them. I want them involved.” Because they need to be.

At the end of the day, who fixes the issues? Developers. [Laughter] Software engineers are the ones actually fixing the issues. They need to get a seat at the table there. So, I loved that quote in the beginning. 

[David Spark] Steve, your favorite quote and why? 

[Steve Zalewski] Yes, David, this was a tough one. There were too many good ones, honestly. But here’s what I’m going to focus on. It’s kind of what I close with, which was security has to step up now and tell the developer what’s good enough for security, as opposed to just what all the problems are.

So, I’m going to go with the last one, with Shawn Reilly from SAP. “We want to make things more secure and faster and easier.” What I’m going to say is that’s fundamentally wrong now. That what we talked about with development and AI development and open source is we need to make the application secure enough and faster and easier.

And that is a management issue that we need to think about. 

[David Spark] Excellent. Well, that now brings us to the very tail end of the show. I want to thank your company, Matt. That would be Endor Labs, multiple AI agents, one force for AppSec, zero distractions for developers. In fact, everything we were talking about today, very much in their sweet spot.

Go check them out at EndorLabs.com. Matt, I’m going to let you have the very last word. If you’ve got an offer, any suggestions you have for our audience, can they reach out to you? And is Endor Labs hiring? 

[Matt Brown] Yes, we’re hiring. Go to EndorLabs.com/careers. We have about 17, 18 different open positions.

[David Spark] Oh, wow.

[Matt Brown] Everything from customer solutions. Yeah, we’re growing. So, please do check that out. Please do feel free to contact me. My LinkedIn information will be up. I’m happy to chat with anybody about any of these topics. Like I said, this is kind of what I’ve…

I’ve been in SCA, static analysis container scanning for about seven years now. The context and information that Endor Labs can supply folks, if you actually want to fix things and get things done and actually speed up velocity and be secure enough and have that confidence to say, “Hey, we are protected and we are secure,” while not slowing down developers or development work.

But more importantly, if you want to gain a better relationship with your developer team and have that kind of cohesion, that’s just running like a well-oiled machine, we can definitely help you out with that. So, if you need help with software composition analysis, AI security code reviews, static analysis, or reducing false positives, container scanning, amongst many other things, we’re more than happy to help out and hope to talk to anybody soon.

[David Spark] So, to take those 6,100 CVEs and bring them down to around 15 so everyone will be a lot happier. Awesome. Well, thank you very much, Matt. Thank you very much, Steve. And to our audience, we greatly appreciate your contributions and also for listening to Defense in Depth.

[Voiceover] We’ve reached the end of Defense in Depth. Make sure to subscribe so you don’t miss yet another hot topic in cybersecurity. This show thrives on your contributions. Please write a review, leave a comment on LinkedIn or on our site CISOseries.com where you’ll also see plenty of ways to participate, including recording a question or a comment for the show.

If you’re interested in sponsoring the podcast, contact David Spark directly at David@CISOseries.com. Thank you for listening to Defense in Depth.