Checkmarx Warns AI Coding Raises AppSec Risk

Hey guys, thanks for that. We're here with Jonathan Rendy, who's the chief product officer for Checkmarx, and we're having a little conversation about the survey that they just came out with, which I looked at it, and it was a little bit disheartening, but let's see what Jonathan has to say about that. But, Jonathan, application security, give us the highlights, and are we making any progress?

Well, Mike, first, thanks for having me here. Really appreciate it. It's a pleasure to be here and sharing with your audience that we're at such an interesting point in tech, in the industry, given the major disruption of AI and so much information is being shared all the time, with blogs and people are acting on that.

So we felt the survey was important to ground a lot of our customers, our prospects, our partners with what we're seeing and what we believe is really important going forward. So yeah, kind of surprising some of the results and in some ways, not surprising. Well, some of the things that leapt out at me were that developers still quite aren't prioritizing fixes, and they're still shipping a lot of code with known vulnerabilities into it.

Is that going to continue in this post-MITOS age that we've seen? Is there some fundamental changes about to come to a head, do you think? Yeah, I think the promise is that security has never, ever been, in 20, 30 years, security's never been the number one item on the mind of developers.

No developer goes in to that profession, as a former developer myself many years ago, no one goes into it because they want to solve security vulnerabilities. They go into it because they want to innovate and create. And the new frontier models provide such an opportunity, if used properly, to accelerate all that.

And we're seeing that in our data. We're seeing the increase in pull requests. We're seeing the increase in lines of code being created.

The role of the developer clearly is changing. But with that, and with that generation, there's this assumption by the development teams that, hey, well, it's being generated for me, and I don't focus on security first and foremost. That should be somebody else's responsibility, or something else's responsibility, if you're thinking of agentic.

So they're going to keep focusing on innovation and delivery, and I think it's the role of security to be seamless as a part of that. And that generated code is not secure today. It's not.

So whether it's knowingly or unknowingly, that two to three X of code that's being created now is going out insecure. And that's something we have to address as an industry. Is that code actually making it into production environments that you're seeing, or are humans getting in front of that and stopping it somewhere along that DevOps pipeline because they have scanners and somebody can see this stuff?

It is. That 70% increase to 100% increase in code, many organizations know, they willingly know, and that was part of the survey, that there is insecure code going into production. I was in a set of CISO conversations just two days ago, up in the Pacific Northwest, where we had a roundtable of CISOs.

And this topic came up, and it was interesting, the reactions of the different flavors of CISOs in the room. Some of them, they all agreed that it's happening, number one, to the 75% of respondents knowingly statistic in the report. But how they want to address it, that's where the variations came in.

Some were saying, "Oh, this is just a production issue we need to address," which is building a fence, building a barrier kind of an approach. Others were like, "No, we need to go upstream. " So there wasn't disagreement on the result.

There was disagreement on the how to address. One of the more troubling things in the survey was nearly all the CISOs, at least, said that they had felt some pressure to maybe not report as aggressively as they perhaps want to. Is that just the natural state of things because organizations are hesitant to incur some fine capability?

But also, I can't help but wondering sometimes if the cover-up is worse than the crime. Yeah. Security and the insurance industry has always lived in a world where until something happens, it can be swept under the carpet.

I think what we're finding now is no one is immune to attacks and the speed of those attacks and how they're happening and how they're mounting at less than a day at this point, and it will be down in the next year or so to just under an hour, a few minutes. How attacks can be mounted against not only code, but also the supply chain elements. That's a very real, it's a new reality for organizations.

So I just think, going back to what's important and what's critical for organizations, I think Right now, there's a race to get innovation out the door, so development is running. Unless there is a strong hygiene in the organization, yes, they're making decisions kind of unchecked. The checks and balances are weak right now in most organizations, is what we're seeing.

To give a nod to Ralph Nader, are we unsafe at any speed here, because do we need to slow down, or is there some way to balance this out? I think there is a balancing point, and it's by getting ahead of the issue up front. And again, I've heard the term it's an arms race.

AI affords attackers a new ability, but it affords the teams internally an ability. And so going back to that roundtable discussion I was having with the CISOs, both are true. There needs to be a many-layered approach here, and it needs to be implemented now.

And the good news is that the tooling, the AI-driven tooling, does exist today. So it's not because there's a lack of resources or approaches. They're there.

It's just a willingness to do the right thing. I also hear it's getting more challenging in the sense that the exploits are showing up before the patches, and a lot of that has to do with the fact that the bad guys are using AI and understanding those vulnerabilities. So has the dynamics of this whole vulnerability discover, disclosure, patch management process kind of been broken?

Some of it has been broken with the speed at which the automation, I think, everything is moving at machine speed now. So attacks are moving at machine speed. Defense is moving at machine speed.

Both have to go hand-in-hand. When the bar is raised, both sides need to adapt and adapt quickly. It's those organizations that are not adapting, are the ones that are at most risk.

So I think the short answer is, to your question, we just need to act fast. We need to act with urgency, and we need to look forward to what needs to be done versus relying on past approaches. Do we need to also maybe change the culture of the conversation surrounding all of this?

Because to your earlier point, I feel like we're trying to blame people, and yet everybody's got the same problem. " Or is that just too optimistic a thought? Yeah, I actually think that too often security is viewed as a technical decision.

When people are making the decision, I think it's a cultural decision in an organization that when innovation and the need and the speed for innovation is so important, it's not mutually exclusive with security. Both have to go hand-in-hand. So I think the change is more of a mindset, a cultural set that, yeah, we do want to move faster.

Yeah, we will move faster, but it needs to be done in a balanced way with security built in to this. And so to me, it's not just a technical decision. This is a business decision to have the right balance.

Where does this function belong? And I'm asking the question because we all talked about shift left for years, and it doesn't seem to really resonate with developers who, for one reason or another, have too many things on their brains to maybe sort all that. But we can put it in the DevOps workflows, or we can put run times maybe in place in the production environments.

But what is the right way to approach this whole thing? Yeah. To your point, shift left has been around for as long as I can remember, and the whole idea is, hey, we need to, quote unquote, "educate developers" and get developers attuned and a part of the security program.

And I think that's where, again, you're fighting human nature, that developers didn't go into development to become security experts. And so, again, with the glass half full, what AI really provides is an ability to build this into development, but to do so in an autonomous way, in a seamless way. So when we talk, Mike, about workflows, it's one thing to put it in a workflow, but then ask somebody to do something in that workflow.

It's quite another to put something in a workflow but make it so that they don't have to do anything different than what they do today. And that's the promise of how security-related, a plane, a set of agents, orchestration, can help as a part of the delivery process that is seamless, that doesn't require or create friction with the innovation and the development effort, and that 100% is possible. So you mentioned that all this is happening at machine speed, and the code is clearly being created by AI.

Are we going to need some sort of AI-driven security framework to kind of secure all that code as it's moving through the pipelines? And it would seem to me anyway, that it may not be a good idea to ask the AI agent that created the code to figure out how to secure it because, well, if it knew what it was doing, it would have validated it in the first place. Yeah.

It's 100%. So there's a couple fundamentals that we believe at Checkmarx are critical. The first is that there's a separation of church and state, and that a proper security program has those checks and balances.

If you think of any industry out there, you think of the finance industry. Every organization has a finance department, but every organization also has an auditor that comes in and checks everything, and it's no different here. You have your Delivery and development and innovation processes, but you do, and you must have some level of separation of validation, and it can't be from the same development capabilities and innovation that created the code itself.

It needs to be separate from that to have that view, that objective view from the outside. So that's one element. But the other major parts of any security program, we look at it as kind of a three-layer approach, and at the foundation, first and foremost, it's all about how do I identify the comprehensive set of issues and do so with the highest fidelity?

Having high fidelity that are measurable with benchmarks, engines that look at both the AI as well as the rules-based, that's at the core. You cannot fix what you don't know about, so you have to have the complete fix. That's the foundation.

The next layer is I need that single view. I need that single view of risk, business risk to my organization. Many people refer to it as an ASPM, a single view across all the systems, all the applications, all the services with the proper prioritization of zero-day and end-day vulnerabilities.

So that's layer two. But layer three then is what I refer to as an orchestration layer. This is where agents play such an important role that they can be embedded at different parts of the life cycle.

And yeah, there can be a human assist part of them, a hand on the wheel for really critical decisions, and there should be. But much of what they do can and should be fully autonomous, working in the background, making fixes, suggesting as code is being generated. So not a shift left where I need to review, but a shift left that is more of the nature of the code being generated behind the scenes is already being cleansed before it's presented from that separation of church and state.

Are we waiting for some sort of catastrophic event before we get serious about all this? Or is this going to be another instance where somebody says, "Well, this was a wake-up call," and then everybody rolls over and hits the snooze button one more time? Yeah, no, I think it's already happening.

Like, the events are already happening, and they're growing. We see the number of malicious packages, which is a service, a capability that we provide in the Checkmarx One platform, as it's growing exponentially. The same with supply chain attacks are growing exponentially, and I think that's because these have traditionally and historically been the weakest parts of the delivery process, and it's all about gathering and obtaining credentials by a lot of these nefarious groups.

And so those are some of the areas that need to be secured more than ever. And it's been interesting. We've done some analysis.

I know much has been made of the Mythos announcement and Project Glasswing and the different partners that are engaging in that, and much has been made in those same set of announcements about how a whole new set of zero-day vulnerabilities have been identified, and that's true, but some of those zero-day vulnerabilities were not zero-day. We've already done the research on that. They were known already.

They were in the backlog. They were lower priority. So it's more important than ever to, again, go back to that foundation I talked about before, know the comprehensive set and address both your incoming and your backlog, and do it in an automated way that's seamless, that doesn't create friction.

Do you think more organizations are going to go back and fix their existing applications that they already deployed that have these known vulnerabilities? Or will they just decide, well, maybe we should rewrite that app altogether and just do it right from the get-go the first time? Yeah.

I think that's always the $64,000 question. Do you just keep limping along and enhancing, somewhat kicking the can down the road on your existing systems, or do you bite the bullet and rebuild, which is always an expensive proposition or a cost proposition to weigh against? I think with AI, again, it raises the bar on both.

It raises the opportunity on both. That, one, now that backlog can be addressed more effectively and more efficiently than it ever could be before with humans. I also think building a new app can be addressed better than it could have been done without AI in the past at a more cost-effective approach.

I do think there'll probably be a shift in some ways, shifting towards what can we do in the future, not just for cost of building something new versus working on the old, but because I think user experience usually demands some of those new innovations, and that, many times, trumps an existing system, especially when it's driving top-line revenue for a company. Do you think that as we get more serious about security, will the cost of application development increase, or can we do this in a way that maybe contains those costs? Yeah, if done poorly, yeah, it can increase.

It's always more expensive to fix something after the fact than it is to do it right the first time. That's been proven over and over again. But overall, to your question, I do think that the cost of development is dropping.

That's why we're seeing, I feel for new hires, new grads in CS programs coming out of university these days. A lot of firms are not hiring right now because they're expecting more out of their existing teams. So the amount of growth, the amount of hiring that's been out there, has clearly leveled off.

And that's because productivity is going up. So there'll always be a difference between a great developer and an okay developer, but I think that margin just widened if that great developer can apply AI to what they do. Ultimately, do you think that maybe we will go through a certain amount of pain in the short term, but is it possible that, as a result of all this, we might actually wind up with more secure software at the end of the day?

It's just that we're having a little bit of indigestion because a lot of technical debt that we've been hiding for years has suddenly come and due overnight. I'm an optimist by nature, and I actually do believe we'll have more secure software than we've had in the past. And I think it's because the market, the world, businesses will demand it.

With the volume of attacks that are happening and where those attacks are happening in the supply chain, it is forcing organizations and businesses to take security way more seriously, not just for the code, but for the supply chain that they're dealing with. And I think as I'll bring it back to the conversation I had with those CISOs, it's interesting. It cannot be just a SOC, it can't be just a production solution to this.

It has to be managed upstream. And I think the hardening of that upstream and those processes, it's going to happen. And now the ability there is for that to be hardened in a seamless, automated way with AI.

So I'm optimistic. And folks, you're hearing it here. " Well, this is one of those moments.

Jonathan, thanks for being on the show. Thank you, Mike. Appreciate it.

Thanks, everyone. All right. And back to you guys in the studio.