AI is accelerating software development faster than many security teams can validate, leaving CISOs and AppSec leaders stuck between shipping software and defending the risk decisions behind it.
AI is giving software teams a speed boost, but that speed comes with an uncomfortable trade-off: more code, more findings, more pressure to ship and a weaker record of who approved what before release.
That is the AppSec Catch-22 described by Darren Meyer, security research advocate at Checkmarx. If security leaders slow releases to prioritize vulnerability remediation, they risk falling behind customers, competitors and product deadlines. If they accept too much risk to keep the business moving, they may lose the ability to prove which vulnerabilities were known, which were waived and who owned the decision.
The issue is not just insecure AI-generated code. It is the growing gap between code creation and security accountability.
Meyer argues that AppSec is no longer fundamentally a tooling problem. Tools matter, but organizations also need the process, governance and trust to use them well. That becomes harder as AI tools write code, review code and increasingly sit inside developer workflows.
[See Related: AI Code Is Moving Faster Than AppSec’s Audit Trail]
Checkmarx’s Future of Application Security research found that 75% of organizations knowingly deploy vulnerable code at least some of the time. Meyer says the more important question is whether those decisions are deliberate, documented and defensible.
What follows is a lightly edited transcript.
SPB: Darren, thank you for joining Security Point Break. Please introduce yourself and give us the 10,000-foot overview of what Checkmarx is seeing in the future of AppSec.
Darren Meyer: Thanks, Tom. I’m Darren Meyer. I’m a security research advocate with Checkmarx. I’m responsible for understanding the Checkmarx Zero research that we do across the security industry and helping different audiences understand it. I have a wide background in AppSec, so I get a chance to talk to different kinds of people and help them understand the security research world.
The big theme across all of this is that software development is getting faster and faster, and application security teams are finding it harder and harder to keep up. AI is certainly a big part of that puzzle, but it’s also changes to the industry and the accelerating rate of business.
First to market continues to be a driver. It has been like this for a while, and it is just getting faster. Many security teams have been struggling to keep up with the pace for a while. AI gets introduced and accelerates that curve even more. Now some people are really struggling, and everyone is looking for ways to stay ahead of the increased pace of software delivery.
The audience of who is a software developer has also changed. People who are less trained and less familiar with security topics are doing more software development than ever before. That is a big challenge for teams.
At Checkmarx, having been an application security company for quite a while, we care about this a lot. We want developers to be empowered. We want organizations to take a smart and defensive posture without slowing them down.
The two latest ways we are doing that are improvements to our static testing, using the power of AI while avoiding its downsides as a security tool. We are taking a hybrid approach by looking at what traditional SAST tools do well and augmenting that with what AI tools do well. They work together to make each other better.
We are also helping people get visibility into what their organizations are adopting from an AI standpoint. Adoption is moving so fast that it is hard to know what people have, what people are adopting and what developers are using. Our AI inventory and AI Bill of Materials, or AI-BOM, help people get a handle on what is being adopted so they can place governance and awareness around it.
SPB: Checkmarx has talked about a Catch-22 companies face as AI helps developers write more code faster. What does that mean for AppSec teams trying to manage this from a security perspective?
Darren Meyer: It comes down to the fact that there is no right decision for security leadership to make.
If you talk to a CISO who says, “I want to prioritize vulnerability remediation because I know 75% of my apps are going out the door with vulnerabilities in them, and I’m not comfortable with that,” they then look at the tools and processes available in the organization and say, “If I do that, we suddenly can’t keep up with the market.”
That can become a potentially existential threat to the organization, especially if you are a software company. But everybody is kind of a software company now. It is becoming a bigger deal if you cannot ship fast, fix bugs live or release new features at the pace your competitors do.
But if you back off and say, “We have to accept a certain amount of risk because of this new reality,” your job as a CISO is still to manage risk. How can you manage it if the organization’s position is that shipping fast is the only thing that matters?
Whatever point along that continuum you hit, there is no clear right balance. It is going to be specific to a given organization, and whatever you decide as a security leader is going to be a little bit wrong. That is a really difficult position for security teams and leaders to be put in.
SPB: One of the data points from the Future of AppSec report is that 75% of organizations knowingly deploy vulnerable code. What is going on there? Why are organizations still knowingly shipping vulnerable code?
Darren Meyer: It varies from organization to organization, but this has kind of always been true. The pressure to release pushes that out.
To a certain extent, this is OK. There seems to be a growing sense in organizations that zero risk is not achievable, which is exciting to me personally because I’ve been banging that drum for 20 years.
Organizations are pushing things out where they say, “I know there is a weakness. I know there is a vulnerability. But I’m looking at my environment, I’m looking at the risk I’m actually taking on, and I’m saying I don’t have the resources, or it is not worth spending the money to fix it. I’m just going to accept the risk.”
The bigger concern is not that they are doing it. It is what is behind that data. The concern is, “I’m being forced to make this decision rather than looking at it from a risk management standpoint and saying this is the level of acceptable risk for the organization.”
They may not even have time to make that decision in a sensible way because things are moving so fast. There is a lot of fear about the unknown unknowns of security.
SPB: Where is that pressure coming from? Is it the CISO, the board, customers? What is driving pressure to delay or suppress compliance-related security issues, and what is driving the push to ship code?
Darren Meyer: It is coming from a couple of places. There are two aspects to it. There is the pressure to ship, and then there is the pressure around what to tell people if you know there is a security incident or a vulnerability. Who do you tell, and when? Those are related but different pressures.
The pressure to ship is largely coming from the product organization, but ultimately from investors, board members and customers. Customers want new capabilities and new features. If your competitor ships a bunch of new things before you do, the customer may buy from your competitor.
There is a legitimate fear from the product and revenue side that the company needs to keep up with competitors. If security slows things down too much, you are balancing a potential security risk against the real, articulable risk of losing a customer. That is hard for a CISO to argue against: “We should slow down and accept a definite business risk to avoid a security incident that might happen.”
When it comes to disclosure, you have compliance drivers pushing people to disclose. You have CISOs who see value in transparency and informing customers. No customer likes to find out from the news that there was an incident.
But you also have a culture of fear at the board and C-level. Anything disclosed that makes the company look bad from a security standpoint could affect stock price or become a major PR problem. That fear is not completely illegitimate. Those things do happen and they cause problems for companies.
On balance, disclosure tends to benefit companies over the long term. But there is still fear that this will be the one time it goes badly and has a big impact on the things leaders are scored on, like stock price.
SPB: How has AI affected how code is written and brought to production? Has AI disrupted the development food chain?
Darren Meyer: Absolutely. There are a couple of ways it does that.
One is that we now have some companies shipping production code that was written by somebody who is not a software engineer. AI is good enough that they can write something and submit a pull request without really understanding what they are doing.
Those things are not necessarily getting adequate review because everybody has time pressure. All the mechanisms around peer review, reviewing pull requests and submitting things for security review are happening under very compressed timescales.
The result is that people are often using AI tools to conduct those review processes. That means code can go from idea to production without anyone ever evaluating it properly and asking, “Is this actually what we want to ship?”
It is being tested only from the outside and not really examined. Sometimes that works out. It works often enough that leadership sees value in delivering quickly, and it is not biting people often enough yet.
From past accelerator technologies, what we have seen is that when you compress review and rely more on tools, the penalty comes later down the pipeline. Right now, leadership’s perspective, just looking at their data, is that this is almost all upside.
The downside is going to come six months or a year later. Maybe the people who made those decisions are not even going to be there anymore. It will be somebody else’s problem, and the organization may not be able to connect it back to compressed timelines, missing tool chains, missing people or not knowing when to slow down versus accelerate.
That will be harder to diagnose because in many organizations the people who made those decisions have moved on, and the organization has lost that domain knowledge.
SPB: CISA and others have long pushed the idea of building security in from the foundation. This feels like the opposite of that.
Darren Meyer: It very much is the opposite of that.
Speed and the ability to turn a profit are always primary concerns of business. It is not that they do not care about security. It is that they are balancing it against other things that have real, articulable risk or value.
Security is harder to measure, so it gets shuffled to the bottom. Everybody is secure until the moment they are not. It is a perception problem.
People are also expecting AI tools to be better at security than they actually are. There are some pretty good things on the market. We are using AI as a component of our hybrid SAST now because we see real value there.
But AI tends to have high precision. What it finds tends to be fairly accurate. If it tells you there is a security issue, there probably is. But it also has fairly low recall. It misses a lot of things.
As a security organization, we are very concerned about the industry belief that AI will solve all of this. You are going to miss a lot of coverage, and you are going to ship things you do not know are problematic. You are not making risk decisions.
That is why we have become an advocate for a hybrid approach. The traditional model of tools, established over almost 30 years of research, is still highly valuable and does things nothing else can do. It has to be combined with what AI is good at, and it has to be put into processes, cultures and organizations that understand how to operate tools effectively, respond to what they produce and make effective risk decisions supported by improved tools.
SPB: That leads directly to hybrid SAST. What is the hybrid SAST approach, and why is it necessary now?
Darren Meyer: The idea behind hybrid SAST is that using AI to do security work has some problems. AI tends to be very good at certain things, but it is not very predictable and it tends to miss a lot.
Using it alone, organizations are finding that it is not accurate enough overall. What it reports is valuable, and what it reports tends to be fairly correct, but it misses so many things that using it alone adds too much risk.
More well-established SAST approaches have the opposite problem. They surface a lot of things, but a lot of it is noisy. They cover a lot and bring a lot of things up, but their awareness is not there. They do not reason about code the way AI can.
If you combine those two things, you get an AI that can supervise a more traditional SAST tool and give you the best of both worlds: reducing noise, validating findings and making sure you still have enough coverage and are not missing things.
SPB: What is missing inside the developer toolbox? Where do developers need better support or better tooling?
Darren Meyer: Developers need two things.
First, they need tools that work when they are working on code. They are working hand in hand with AI code assistants to author code. They need security tools that supervise that process and warn them when code they are authoring, or code their AI is authoring, starts to head down a bad path.
That would be tools like our AI Dev Assist, which helps supervise the AI already in the IDE and warn people almost at a keystroke level: “You are going down a bad path. You could be introducing vulnerabilities. Come back.” That needs to happen close to when they are making the decisions.
No developer wants to find out a week later that they have to relearn the code because there is a security bug.
Second, security teams need better tools in the pipeline and in other systems so they get high-value results. When I come to a developer and say, “I found a security flaw,” I better be right. I better be right a large percentage of the time if that developer is going to trust me and listen to what I have to say.
If product managers and project managers are going to allocate resources to fix these issues, they better be hearing from developers that the findings are correct, valuable and make sense.
So it is both sides. You need good detection later in the pipeline, but you also need support as developers are using AI to author code day to day.
SPB: AI seems to be both the problem and the solution. It is creating the problem, but it is also being offered as the way to fix the problem. What is your take on the exuberance around AI right now?
Darren Meyer: There is definitely a hype aspect to AI, where people are buying a vision that we are not entirely confident will pan out.
A lot of people are making very big bets in their organizations, thinking, “I see the problems the current generation of AI has, but it is going to get better and solve them before I have to bear the risk or cost.”
That is not guaranteed by a long shot. It is a very big bet to make. Maybe they will turn out to be right. But from a research standpoint, I do not see a particularly good reason to think there will be massive improvements in the near future.
You cannot always predict a breakthrough. That can happen. But things are in incremental mode right now. They are getting incrementally better over time. The user experience is getting better. Things are improving. But I am not seeing a trend toward improving fast enough to solve the problems that poorly thought-out AI implementations are introducing.
In the not-too-distant future, and we are already starting to see cracks, people who have over-adopted AI are going to start experiencing some of the downsides they have so far avoided. Token costs are going to go up. People are going to experience the real costs of these systems and some of the risks that have been pushed off under the hope that AI will fix them.
They will adopt some AI and hybrid tools to address and lower those risks. But we are going to find out which organizations overinvested in AI, which ones underinvested and who got it right. There is a lot of “if” coming off people’s plans, and that is going to be very expensive for somebody. Somebody is going to be left holding the bag.
SPB: What is the takeaway you want people to have?
Darren Meyer: The main takeaway is that doing security at scale, at the increasing pace of development, is genuinely hard and it is getting harder.
Many organizations have seen this coming slowly over the past decade or so and, for budgetary reasons or other reasons, have kicked the can down the road.
AI means we are running out of road extremely quickly.
People need to figure out their organizational strategy to get the visibility, low noise and accuracy they need from their tools and processes. Otherwise, they are eventually going to find their risk completely unmanageable.
SPB: Darren, thank you so much for your time.
Darren Meyer: Good talking to you, Tom. Thanks for having me.
