In this episode, I sit down with Checkmarx Chief Product Officer Jonathan Rende to discuss where AppSec stands now that AI coding tools are standard in the enterprise. We cover why he argues a model can’t be its own security control and what Checkmarx’s benchmarking shows about combining rules-based and AI-driven scanning.
Jonathan worked in software quality and developer tooling before coming back to security, going back to the Fortify and SPI Dynamics days. He has seen a few platform shifts up close and thinks this one is bigger.
We chatted about:
Why Jonathan sees the first half of 2026 as an inflection point for AI code security
The two waves of enterprise AI adoption, from “run fast” to rethinking program and posture
Functional AI-generated code versus secure AI-generated code
Checkmarx Zero’s benchmarking of deterministic and AI-driven scanning, and how little the findings overlap
Why enterprises still need an independent control plane as frontier models ship stronger guardrails
Shadow AI, AI inventory and the models and MCP servers security teams don’t know about
Where agents take on the rote AppSec work, and why Jonathan says this “isn’t completely the dark factory for AppSec”
What a CISO or AppSec lead should change first when coding agents arrive
Prefer to listen?
Please be sure to leave a rating and review, as it helps the show!
The pendulum is swinging back toward security
Jonathan put AppSec somewhere between eight and twelve on the priority list of most CEOs and boards as of eighteen months ago. Then came the first wave of AI adoption, where CEOs told engineering leaders to get AI coding tools in-house regardless of cost. Everyone else took a back seat. He said Checkmarx did much the same internally and standardized on Claude.
In the last three to four months he has seen a second wave. Customers are asking what a program and posture should look like, and they are poking at vendor marketing claims. That matches what I see in the community. Security seems to be leaning into this shift earlier than we did with cloud and SaaS.
Rules-based and AI scanning find different bugs
Checkmarx’s research team, Checkmarx Zero, ran a hybrid of deterministic and AI-driven scanning against dozens of open source projects. Jonathan described the results as a Venn diagram with very little in the middle. “What we found over and over and over again was the overlap is like less than ten percent consistently.” Each approach surfaces a class of issues the other misses.
That undercuts both camps I saw form earlier this year. One said LLMs are too non-deterministic to trust for code scanning, and the other said rules-based tools are obsolete. Jonathan also pushed on fidelity. His team measures against an F1 score to balance precision and recall, since noise is what created the friction with developers under shift left.
The model generating the code shouldn’t validate it
I asked Jonathan why the model itself can’t be the control, given the frontier labs keep shipping stronger guardrails. He called it a separation of church and state. “You have an independent control plane for security and the model that you’re using for productivity and for generation, there’s a conflict of interest if that’s also doing the validation for security.”
He added an incentive argument. “In our industry, we should hopefully be focused on value and reducing risk, not selling tokens.” He was careful to say the model providers will care about cost effectiveness eventually, and that it isn’t their business model today. This is something I have been harping on as well.
Shadow AI is showing up in the scans
Jonathan sees threat exposure split by how fast an organization moves. Tech and semiconductor customers building models and agents into customer-facing products are hitting new threat vectors first. More regulated shops with stated AI policies are mostly seeing issues at the level of generated code.
Visibility is where he starts. Checkmarx released an AI inventory capability, and he said early access customers ran roughly 50,000 scans. About half turned up AI building blocks such as models and MCP servers “that the security team had no idea even existed.” My advice to the regulated crowd was to learn from the mistakes of the early movers, because many of them share those lessons publicly.
What to change first in your AppSec program
I closed by asking what a CISO or AppSec lead should change first when coding agents arrive. Jonathan said to get clear on metrics up front. He also said to give the vulnerability backlog the same attention as incoming code, because AI makes it easier to chain low priority vulnerabilities into something with much bigger impact. He wants security inside the developer’s existing workflow so nobody has to change how they work.
His last point was about communicating upward. One executive told him, “We used to get called in for a security review once a year. Now it’s monthly.” Risk is changing fast enough that how you report it to the executive team and board has to scale with it.
