Veracode Marketplace Tackles AI Security Vendor Sprawl

Hey guys, thanks for the throw. We're here with Anthony Barkley, who's the chief strategy officer for Veracode, and we're having a chat about marketplaces because, well, they have one now, and we're going to dive into what does that mean, and how is it different. Anthony, welcome to the show.

Thank you, Mike. I appreciate you having me on. There are a lot of marketplaces out there now, so the question becomes, what makes the Veracode one different, noteworthy, and what is it you guys are trying to achieve here?

Yeah, no, thanks for the question, Mike. Yeah, I think when I really look at all the different marketplaces out there, so many of them are just intended as a vehicle for paper or a mechanism for bringing in more technology. What we started recognizing with our customers is they were running into a lot of challenges related to just the wild proliferation of AI security vendors in the market today.

I think the last time I looked at IT Harvest, it was up to about 520. So just an amazing number of vendors to have to manage. And they bring us net new needs almost monthly.

The evolution with AI of just new challenges, new needs, new requirements is kind of outpacing what traditional vendors can do, both through organic and inorganic types of activities. And so what we started doing was looking out at the ecosystem to try to identify a few key vendors that could specifically address these areas and at the scales of the enterprise customers that we were working with. It also seems like in the age of AI, no one's quite clear what's a feature and what's a platform these days.

So given all these vendors that are out there, how do you see all of this evolving? Yeah, I will tell you, it is quite interesting. When I talk to our largest enterprise customers, they are struggling.

The fact of the matter is you'll have anywhere from 10 to 40 vendors in almost the exact same space as saying they do the same types of things. I think the biggest challenges they're dealing with is just the fact that the sheer volume of code that's being created within these agentic frameworks is mind-boggling. It's almost 20 X in just the last 18 to 24 months.

In addition to this, these LLM models, while they continue to improve, and syntactically it is incredibly accurate code, what we find is somewhere between 40% and 60% of that code getting created has some type of vulnerability in it. So our customers are still facing the same types of challenges that they have in the past, but just at an exponentially greater scale. And they're taking on a lot of new situations.

It's not just the code, it's also securing the agents that are creating those codes. It's the wild number of not only models, but skills, even MCP servers that provide all types of different capabilities that they're trying to consume. All of this coming together is creating just a whole new set of threats that they're not used to encountering.

To your point, do those two things converge? I've got this kind of need to change my DevSecOps workflows in the agentic AI age and a desire to kind of maybe reduce the total number of vendors I got to deal with? Yeah, I think it's a couple of things in there.

So not just looking at the total number of vendors, it's looking at, as you mentioned earlier, those features, those capabilities, and understanding how to aggregate those into a platform that can be easily consumed, both by the security operators, researchers, and the responders, but also by the developers, right? Being able to shift that as far left as possible. This actually brings up one of the first partners that we selected in this process.

So a company by the name of Dryrun Security. Something that was really powerful about them when we started talking was they sat down almost three years ago and started identifying these challenges were coming, not just in code in general, but with AI and a lot of the different types of changes, but also the way that the tools think about the code. So if I look at our traditional Veracode code scanners, these were deterministic scanners.

It's the way all of us have operated for many years. And now we bring in this new probabilistic scanner, these LLM models that look at more of the intent and what the operator was trying to create. We've got to be able to bring both of those things together to actually address these challenges that our customers are having.

Is the fact that some other third-party vendor in the marketplace also a signal that the cost of integrating that thing is going to be lower? Because I think one of the things you hear people complaining about all the time, it's like, "Now I do have all these vendors," but there's a significant integration burden that comes with them. It is.

It's interesting. I've spent over 30 years in security and applications, and we look back at the kind of open source explosion 20 years ago and what that meant with build versus buy. I think everybody's going through that same type of mindset right now.

They're looking at these new AI models and large language models and tools and new harnesses and frameworks, and they're all trying to figure out, is this something I could do myself? Could I bring it in-house? Could I build and manage it without needing to bring in multiple third-party tools?

Do I still need large vendors to integrate and build platforms around these solutions? And everyone's kind of coming at this from different angles, but the conversations that I continue to have with our largest customers really get into the time, the effort, the maintenance, and the sheer speed of change that we're dealing with right now. I think what we have been able to do with this marketplace is find a few unique vendors that actually have very specific technology that aligns with the capabilities we've already been bringing to our customers and allows us to show them a well-integrated solution that they can start deploying immediately.

And that's actually been one of the concerns that they brought to us is not only is it hard to go out across all these vendors and find one that actually meets your needs, but then will that customer scale? Do they have the appropriate backing? Will they be there in 24 months if these customers go spend significant time and resources getting that deployed within their organization?

How proactive are people being about all this? Or are they kind of just backing their way through this conversation because they've added some AI coding tools, and then they realize that the hip bone is connected to the thigh bone, et cetera, or are they looking at this more holistically? No, I think they are looking at this more holistically.

Look, I'll be very frank. The customers we talk to, they are being very methodical about the approaches they're taking. They're bringing very skilled teams together to go assess the large language models, to look at the types of things that would be involved in putting together their own harnesses, understanding all of the different systems, and the potential risk factors of connecting to those different systems to bring these solutions together.

I think the challenge starts to get into the long-term view. It's easy to really think through that scenario with one or a dozen applications, but so many of these enterprise customers are managing 500, 2,000, exponentially more than that numbers of applications on a daily basis. That scale becomes a true burden.

That amount of change becomes the true burden, and so helping them understand what we can bring together today and work with the tools and the capabilities they've built within their organizations, but also create a path toward the future where they're running these solutions, these harnesses, these models, these skills at scale, and doing that in a way that reduces risk for the business. A lot of this revolves around the assumption that there's going to be a tsunami of vulnerabilities and subsequent attacks. " What's your sense of where are we on this journey and what's real and what's not real?

Yeah. I'll tell you, Mike, I do genuinely believe, based on some of what I've seen across some of these different- frontier models, there are some incredibly unique vulnerabilities that are being brought forth, and it's combinations of different elements brought together to create a very specific exploit. The sheer volume is absolutely going up, but that's just a function of the amount of code that's being created.

You can't create 20X the code with LLMs that were actually trained on the same code that we've used for 20 years that had issues and vulnerabilities. We're seeing those same types of issues and vulnerabilities, just at a much larger scale. Not necessarily more levels of risk or creating greater exposure, but I think over time, we will continue to see that.

The problem isn't the discovery. I've never felt discovery was the issue. Long before the LLMs came up, we were still managing large numbers of discovered vulnerabilities within organizations and findings, and trying to understand from a risk perspective which one should we go prioritize.

That's always been a challenge. We've had security debt for 20 years. It's just escalating at a rate that's really gotten people's attention.

I think remediation is still going to be the really hard element that we've got to work on with our customers, making sure that we can validate and prioritize and then ultimately fix or patch with a degree of safety that is acceptable for the business. Automation isn't going to happen overnight. I joke with people, you can implement automation on a bad process, and it's just going to make a bad process run really, really fast, right?

Mm-hmm. At the end of the day, we need to help our customers better understand their infrastructure and their processes and put automation in place that's going to support a good process through that remediation and response cycle. I think the real question's going to come down to are organizations focusing on fixing those foundational processes.

Do you have a sense of what the tolerance is for breaking applications? And I ask the question because we are seeing people create patches using AI coding tools, but a significant amount of the time, the patches winds up being worse than the disease, as it were, because the application breaks because the AI coding tool doesn't have any context of the production environment. So, how do you think this is going to work out?

I think we are definitely in the early crawl stage of a crawl, walk, run phase that's absolutely going to be necessary for automated vulnerability remediation. I'll tell you, in talking to a lot of customers, we don't just provide SaaS capabilities and DaaS, but we also provide SCA, and one of the biggest challenges with SCA is creating a patch for a library that could have transitive dependencies that create those breaking fixes you're describing. And so just because I fix one library does not mean I've actually resolved the risk for the customer.

I could've potentially increased it because now I've created a breaking fix that only comes out down the road based on some type of testing. In one of our products, Veracode Fix, that we've specifically built with 20 years' worth of expertise and knowledge around our SaaS product, we're about to release that for our SCA product. And a big part of that technology is looking at those transitive relationships.

So we can't just fix that first library. We need to understand the relationship between the first-party code and the third-party code, and what was the intent with that code. And then based on the fix that will happen in that initial dependency, what are those transitive dependencies that will then be triggered or affected because of that change, and what are additional changes do we have to go make?

And then being able to present that to a developer so that they can go through and understand what are all the changes that would be triggered just by that one issue that's been identified. So bringing this full circle to the marketplace, besides a place where I download and conduct a transaction, does this evolve into some place where these conversations are happening across the community? Because in a lot of instances, folks are on their own, and a lot of times they don't have the benefit of a conversation with maybe more than 10 buddies they know.

But is this going to evolve into something a little bit more of a community? That is the intent. So I'll tell you, Mike, just after forming this first partnership with Dryrun Security, we've gotten really close with these guys.

They've built some really impressive technology, but we've done almost 100 conversations with customers. We are learning a tremendous amount just through that back and forth of being able to demonstrate for them a new capability. But through that process, really digging deeper into what's breaking, where do they have the biggest challenges, and how could we work more closely with them to move forward.

And this is really the final element of the marketplace. The point in the marketplace was to find those capabilities early, bring them into an enterprise conversation, really work with those initial customers as design partners, and understand are there things we're not considering that you're starting to see through your own internal evolution that we need to address as a vendor and be able to bring that forward sooner. I've always worried about the inorganic process can be very slow.

It takes time to acquire organizations. It takes time to integrate those organizations and bring that to a customer. It could be 7 to 12 months, and our customers don't have that kind of time for us to bring these capabilities forward.

So in this community, we can rapidly, within a month or two, start having that dialogue, start identifying those issues, those challenges, and start working that into the integration work that we've already brought forward. I think it's just a matter of speed and capability and bringing the right features forward to our customers and giving them a different way to go engage. So ultimately, what is your best advice to the DevSecOps teams out there that are still undermanned?

And even in the age of AI, I think there's probably 50 to 100 developers for every one of them. How do they approach all this? I think there is going to have to be a bit of a mind shift.

Over the last 20 years, the industry's evolved into this idea of providing deep scans across the entire application portfolio. I think what we've started to see is bringing together both deep scans, but also with pull request scans and being able to run faster with the developer community, but doing that in the context of the broader application. And we do this with our partner, Dryrun, bringing our deterministic scanner with their probabilistic scanner.

It gives our customers a different way to think about it. And I'll leave you this one thing. We have a couple of key customers that they are literally running massive million-line code applications every single evening.

And when you really think through it, there's no real reason to do that if we're not making incremental changes on that code on a daily basis. So instead of doing a deep scan almost daily, and then looking at doing some type of PR scan every single time there's a change, but run that scan in the context of the broader application and what we already know about it through a knowledge graph, right? Really understanding the context.

We can accelerate the testing as code is being created, but do it in a cycle that's more affordable, is more supportable, and it'll actually work for our largest enterprise customers. All right. Folks, you heard it here.

I think we all realize the time has come to circle the wagons. Maybe that the wagons, though, need to be in a marketplace to get started. Anthony, thanks for being on the show.

Thank you, Mike. I really appreciate it. All right, back to you guys in the studio.