After attending and speaking with security and development leaders at OnPoint Ski & Snowboard CyberCon 2026, one theme stood out to me: teams are shipping more code, in more languages, across more projects than ever before. Features that used to take days now take minutes and complex logic can be scaffolded from a single prompt. 

The output is fast, it looks polished, and it runs smoothly. 

And that’s exactly the problem. 

When Confidence Outpaces Security 

As developers rely more on AI tools, something subtle happens: the speed and quality of the output create confidence. The code looks clean, it compiles, it works as expected – so it gets trusted. 

But AI models only predict what is likely to work, they don’t understand your threat model and they aren’t able to assess exploitability in your environment. AI-generated code can function perfectly and still introduce serious vulnerabilities. 

This gap between what works and what’s secure is where risk exponentially builds. 

This isn’t a criticism of developers. AI tools are powerful productivity accelerators, and teams absolutely should use them. But validating functionality is not the same as validating security. And right now, that distinction is getting blurred. 

More Code, Same Security Team

This confidence issue isn’t happening in a vacuum; it’s the byproduct of broader organizational shifts. 

The development lifecycle is shifting to be more agentic, more automated, and moving faster than ever. That means more code written with fewer reviewers, pull requests that are more frequent but also more complex, and an AppSec team expected to keep pace without any additional resources.  

So, the backlog isn’t stabilizing – it’s growing. 

I see this tension in organizations all the time. AppSec teams are expected to keep up with the speed of development while maintaining strong security standards. In practice, they can’t fully do both. Slowing down development usually isn’t an option, so security is expected to adapt. 

Development Is Now Human + AI 

Development is no longer purely human-led – but it isn’t exclusively AI-led either. It is now driven by developers working alongside AI. 

AI is assisting, suggesting, generating, and accelerating, but humans are still making decisions and shipping code. The model has shifted from developers writing everything themselves to developers collaborating with AI systems throughout the process. 

This shift significantly increases output. Teams are producing more features, services, and integrations at a much faster pace. But AI is optimized for speed and plausibility, not security. It can produce functional code, but not inherently secure code. 

The speed AI delivers builds confidence and trust, but it also increases the likelihood of security gaps slipping through unnoticed – especially when developers are shipping code they didn’t write and don’t fully understand. We recently dug more into this trend in our Don’t Trust the Code paper and you can read more about it here.  

But these tools don’t just change how developers work – they also add new components to the software supply chain. Every model integration, MCP connection, and AI-assisted workflow becomes another potential entry point, and the environment is expanding faster than many security teams can track. 

I’ve seen cases where thousands of AI coding assistant licenses were active before the Head of Security even knew they existed. And when organizations don’t know which AI tools are in use or how data is flowing, they can’t properly assess risk – and the attack surface grows, unnoticed. 

Security Has To Evolve 

One of my biggest takeaways is that if AI-driven productivity is the new baseline, security can’t operate the way it did five years ago – it must evolve across these three categories: 

1. How we identify vulnerabilities in code is changing.
2. How we identify vulnerabilities in the tools we are using is changing.
3. How we address vulnerabilities is changing. 

Traditional scanners weren’t built for this environment. They struggle with modern languages and frameworks, generate noise, and can’t keep pace with modern CI/CD pipelines.  

Meanwhile, AI is introducing new threat vectors: 

• Generated logic that hasn’t been deeply reviewed
• New dependencies
• Expanded supply chain components

Organizations still need every line of that code scanned quickly, with findings developers can actually act on. This is why we’re seeing the rise of agentic scanning approaches: hybrid engines that combine deterministic analysis with AI reasoning, LLM-powered workflows, and automated context-aware triage. 

But securing the code is only half of the problem, we also need to secure the AI tools writing it. AI Bills of Materials (AI-BOMs) are emerging to provide visibility into where AI is being used, which models are connected, and how data flows through them. Securing the full AI stack is quickly becoming a core AppSec responsibility. 

From Backlog to Automation 

Detection alone won’t solve the scaling problem. The traditional identify – triage – remediate – verify cycle cannot be managed manually when code is growing exponentially. Without automation, quality declines and backlogs grow. 

Agents become valuable when they’re embedded directly into the development lifecycle, especially in high-volume stages like triage, remediation, and verification. These are areas where automation can absorb the workload security teams can’t handle manually. 

When agents operate within a defined AppSec strategy, they form the foundation for applications that can secure themselves, freeing teams to focus on policy and governance rather than reactive risk management. 

Securing at the Speed of Confidence 

The paradox is clear. AI increases output, which increases risk. At the same time, it increases confidence, and confident developers move faster, question less, and merge code more quickly. 

But beneath that momentum, the gap between perceived security and actual security continues to widen. Since slowing down is not a realistic option, the only path forward is to secure software at the speed AI now sets. 

Checkmarx is built for this shift. It combines deterministic scanning with AI-driven detection to give clear visibility into how AI is being used across development environments, while also automating remediation with tools like Checkmarx Developer Assist.  

The result is security embedded directly into the development process – instead of tacked at the end. 

And the goal isn’t to reduce developer confidence – confidence is a good thing! The goal is to ensure that this confidence is earned, backed by real visibility and security controls that scale with the volume of code being produced. 

At the end of the day, confident developers with guardrails in place move fast and stay secure. Confident developers without them just move fast. 

Not because it replaces traditional application security. 

Not because it suddenly makes AI-generated code safe. 

But because it validates something many security leaders already know: AI coding introduces new risks that require AI-native, agentic application security. 

In an era where code is increasingly written by AI assistants, security cannot remain an afterthought bolted on after commit. If vulnerabilities are discovered only after the AI coding phase, it’s already too late.

Velocity and scale have increased, risk has compounded, and exposure scales faster than remediation. 

Claude’s announcement acknowledges this reality. And that’s a positive step forward. 

A New Way To Think About Detection 

At first glance, Claude Code Security and Checkmarx Developer Assist may look similar. Both live in the IDE, both surface vulnerabilities, and both suggest fixes. 

But the philosophies differ. 

Claude Code Security reasons about code the way a human security researcher might: mapping data flows, understanding component interactions, and identifying logical flaws that don’t match known signatures and predefined security rules. This reasoning-first approach allows it to uncover subtle, context-dependent vulnerabilities that traditional rule-based scanners often miss. 

That’s meaningful progress. However, it is only in early preview and covers a very specific angle across the entire Agentic AppSec lifecycle. 

Checkmarx Developer Assist, part of the broader Checkmarx Assist family and a complete Agentic AppSec platform, takes a complementary but enterprise-proven approach. It provides real-time feedback in the IDEs (Cursor, Windsurf, VSCode, AWS Kiro, JetBrains) across: 

• SAST vulnerabilities
• Open-source and malicious packages (SCA) 
• Secrets exposure
• Infrastructure-as-Code (IaC) misconfigurations
• Container security risks

It is fast, comprehensive, and powered by years of curated security intelligence and proven rule libraries, built to operate at true enterprise scale. 

Unlike Claude Code Security, Checkmarx goes beyond pre-commit issue detection. With Safe Refactor, we validate that security fixes don’t introduce regressions, break dependencies, or disrupt the build, so remediation is secure and production-ready.

In simple terms: 

Claude Code Security is deep and novel. 

Developer Assist is broad, fast, and supply-chain aware. 

Both matter, but they solve different layers of the problem. 

Scope Matters in the AI Era 

Claude Code Security currently focuses on reasoning over the application code itself. But modern risk doesn’t live only in application logic. 

It lives in: 

• AI-generated dependencies 
• LLM models, MCPs, offensive agents, IDE extensions, SDKs, etc.
• Malicious packages
• Container images
• Infrastructure misconfigurations 
• Exposed credentials 
• Policy violations across pipelines
• Runtime environments

AI coding doesn’t just produce insecure code, it accelerates insecure ecosystems. 

And this is where a unified, enterprise-grade platform becomes critical. 

Checkmarx One integrates with Developer Assist for broader capabilities including policy enforcement, compliance reporting, ASPM, and auditability, providing visibility across the entire AI supply chain, not just inside a single file in an IDE. 

In large enterprises, security needs to do more than catch clever bugs. It needs to enforce governance, consistency, and control across thousands of developers and millions of lines of code. 

Remediation: Human-In-The-Loop, but at Scale 

Claude Code Security introduces an interesting concept: attempting to disprove its own findings before surfacing them. This aims to reduce false positives at the source, an important improvement over pushing noise downstream. 

But accuracy in detection is only part of the equation. Even high-confidence findings create friction if remediation is slow or disconnected from the developer workflow. Developer Assist addresses this by using agentic AI remediation, initiating an AI session enriched with contextual intelligence and proprietary databases to generate safe, actionable fixes directly in the IDE. Developers can accept, refine, or interact with the agent to tailor the resolution. 

The difference is operational scale and ecosystem integration.

Enterprise Readiness Is Not an Afterthought 

Claude Code Security is currently in limited research preview. 

Developer Assist, by contrast, is generally available and integrated natively into modern AI-powered IDEs. It is architected with enterprise data handling in mind, minimizing data exposure and ensuring sensitive source code remains protected. 

For regulated industries, large enterprises, and global development organizations, these distinctions matter. 

Innovation is exciting, but operational maturity is essential. 

The Developer Assist agent as stated in this article is one of many agents that Checkmarx Assist offers. It joins the Triage and Remediation Assist agents that operate at the post-commit phase of the agentic development lifecycle (ADLC), offering an agentic-based cleanup solution for any missed or ignored security true positives that can slip into production. That second layer of defense, which is also part of the Checkmarx platform, ensures continuous autonomous AI coding across a large scale of repositories and applications. 

This Isn’t Replacement — It’s Evolution 

Market reactions often jump to “disruption.” But even financial analysts have noted that this is not a direct replacement scenario today. 

The more honest framing is this: 

Claude Code Security highlights a long-term shift in how vulnerabilities will be discovered, toward reasoning-based, AI-native analysis. 

And that shift reinforces the broader truth: AI-generated code requires AI-native AppSec (agentic AppSec). 

But AI reasoning alone does not replace enterprise-grade coverage across the supply chain, runtime, policy enforcement, compliance, and governance. 

The Bigger Opportunity 

Claude’s move validates the future. It acknowledges that traditional static scanning models are not sufficient in an AI-driven development lifecycle. 

What it does not yet deliver is a unified, enterprise-ready Agentic Application Security platform spanning: 

• IDE prevention
• Post-commit triage and remediation 
• AI supply chain visibility 
• Runtime validation 
• Centralized governance and risk assessment 

That broader vision is where the real transformation lies. If you’re attending the RSAC conference, come by the Checkmarx booth to learn more about this platform. 

The future of security isn’t defensive. 

It’s embedded. It’s agentic. It’s platform-driven. 

And, most importantly, it evolves as fast as the AI writing the code. 

The era of AI coding has begun. Now AI-native AppSec must scale with it. 

Every commit now triggers a chain reaction of scans across SAST, SCA, IaC, containers, APIs, secrets, and cloud infrastructure, with each producing its own findings, severity rating, and risk interpretation. And when everything appears critical, developers are left with no guidance on what to fix first. The introduction of AI coding propelled new risks almost overnight speeding everything up. While AI tools help teams ship faster, they also create more code, more components, and more attack surface – leading to more alerts and more noise.

The alert problem that existed before AI? It intensified. And when everything looks urgent, teams lose focus on the vulnerabilities that create business risk.

Developers can’t operate effectively when they’re constantly buried under alerts without prioritization or clarity. Because when they can’t distinguish between theoretical and real threats, critical vulnerabilities slip through unnoticed, exposure windows widen, and business risk increases.

This is exactly the outcome we need to prevent. Detecting vulnerabilities is easy; the real challenge is understanding which ones matter, why they matter, and what to fix first.

The Noise Problem: Volume vs. Actionable Insights 

Noise isn’t just annoying, it’s dangerous. When teams are forced to sift through endless alerts, fatigue sets in and important issues get overlooked.

To make matters worse, these alerts rarely tell a coherent story. Each scanner operates independently, surfacing different symptoms of potentially related problems.

SAST may identify a potential injection risk, SCA may flag a critical CVE in a transitive dependency, and IaC may highlight risks in cloud configuration – all at the same time.

Individually, each issue appears “critical,” but without understanding how the vulnerabilities relate to each other and to real execution paths, AppSec teams are flying blind, leading to:

• Multiple tools reporting versions of the same underlying issue
• High‑severity findings in code paths that cannot execute
• Duplicate tickets routed to different teams
• “Critical” vulnerabilities treated equally, regardless of real impact

The problem isn’t the volume of alerts, but the absence of context. Raw vulnerability data means nothing without the intelligent insights to prioritize them. Because when every vulnerability is “urgent,” nothing actually is.

Contextual Risk Scoring: What It Is, How It Works, and Why It Matters 

When teams understand a vulnerability’s real-world impact, they can stop chasing theoretical risks and instead fix the issues that matter most.

Instead of treating all “critical” tags equally, contextual risk scoring evaluates how a vulnerability behaves in your specific application and if it presents a realistic threat. This allows teams to move from severity‑driven triage to intelligent risk‑driven prioritization.

Contextual risk scoring takes the following into account:

Exploitability: Is there a realistic attack path? Are exploit techniques known or emerging? Is the weakness commonly abused in the wild?

Reachability: Is the vulnerable code path actually executed? Can untrusted input reach it? A flaw in unreachable or dead code may pose minimal risk despite its severity.

Correlation: Do signals from multiple scanners converge on the same root issue? Correlation provides a deeper understanding of location, impact, and propagation across services.

Business impact: How critical is the asset? Does it handle sensitive data? Is it externally exposed? Does it support a revenue‑generating or regulated function?

By combining these factors, contextual risk scoring aligns remediation with real exposure. This is how a “critical” issue in an unused library becomes low urgency, while a “medium” flaw in an internet-facing API becomes top priority. Severity alone can’t make that distinction, but contextual risk scoring can.

Correlation Between Scanners: Full Context Requires Multiple Signals Working Together

We need to get smarter about where we focus. Not every vulnerability is worth dropping everything for, and only teams that filter out the noise and focus on what really matters are able to stay ahead of risk.

Teams today rely on a variety of scanners, but no single engine provides complete risk context.

A dependency vulnerability flagged by SCA is just random data until you know whether your application code calls the affected function. An exposed cloud configuration only becomes urgent when tied to the services and code running on that infrastructure.

Let’s look at an example:

SCA flags a critical CVE in a transitive dependency. On its own, it looks urgent. But SAST scan shows no code path that calls the affected function, and runtime signals confirm the component isn’t loaded in production. Three scanners, three separate alerts – but when correlated, the actual risk is low. Meanwhile, a medium-severity SAST finding in an internet-facing API that handles PII, is reachable, and is exercised in production traffic. That “medium” instantly becomes the top priority.

That’s why correlation matters. It stitches together findings across code, dependencies, infrastructure, containers, and runtime environments – transforming disconnected alerts into a single, unified view of actual risk.

Without it, everything becomes noise.

The correlation of findings across SAST, SCA, IaC, API testing, runtime signals, container scans, and CI/CD metadata helps teams determine:

• When multiple alerts represent the same issue
• Whether vulnerabilities propagate across microservices
• If issues exist in deployed, production-facing assets
• Which components introduce actual operational risk
• True root causes that need to be fixed

Correlation turns noise into intelligent, actionable signals. Instead of dozens of fragmented alerts, teams receive a single, contextualized insight that reflects the complete picture. This unified code‑to‑cloud intelligence closes visibility gaps, eliminates redundant triage, and enables smarter prioritization for faster, more efficient remediation. 

Turning Contextual Insights Into Actionable Remediation 

Insight alone doesn’t reduce risk, action does. Risk reduction requires turning signals into a fast, confident remediation. A vulnerability isn’t neutralized just because it’s been detected. It’s only eliminated when developers understand why it matters, where it originates, and how to fix it without wading through logs or deciphering cryptic scanner output.

This is where contextual risk intelligence stops being just a risk scoring exercise and becomes a practical remediation engine. When you combine exploitability, reachability, and cross‑scanner correlation, you give developers something they rarely get: findings they can trust. Instead of another generic “critical” label, they get true prioritization – and a clear explanation of why the issue is important, the exact code path, and where to remediate. And that clarity transforms how teams work.

Delivering these insights directly in the IDE is what makes them actionable. There’s no tool sprawl or no context switching. Developers don’t need to jump between dashboards or triage queues because the context comes to them, showing them precisely which part of the code needs attention.

Your AppSec stack doesn’t need more scanners or stricter thresholds, it just needs contextual intelligence. Contextual risk scoring cuts through the noise to surface genuine threats to your code. And when that intelligence reaches developers where they work, directly in their workflow, remediation becomes fast, confident, and focused.

The most effective teams aren’t the ones processing every alert, they’re the ones with enough context to confidently deprioritize most of them. When everything is labelled “critical,” protecting against true vulnerabilities requires the ability to actually distinguish real risk from noise.

Large language models (LLMs), coding agents, and AI-native IDEs are generating, completing, and refactoring the code that ships to production. In many organizations, AI sits at the center of software creation, determining what gets built and how quickly it reaches users. 

Most teams see this as a productivity win. But AI-generated code doesn’t just accelerate development. It changes the scale of software creation and with it the scope of application risk. 

Traditional AppSec tools were created with the assumption that humans wrote code and security reviewed it afterward. But when AI generates code continuously and autonomously, at a speed no traditional security process can keep up with, vulnerabilities spread long before a scanner ever runs. Risk is compounding while security struggles to catch up. 

The reality is simple: if you don’t secure AI-generated code at the moment it’s created, you’ve already missed the most effective opportunity to secure it. 

When No One Owns the Code 

For decades, application security depended on a clear chain of ownership: a developer wrote the code, understood its intent, and was responsible for fixing it when issues arose. This model assumed human authorship and accountability at every step. Today, that assumption no longer holds. 

Instead of writing code line by line, developers increasingly prompt models, accept suggestions, and make light edits to AI-generated output. This dramatically accelerates delivery, but at the cost of context. Developers can’t fully explain why a piece of code exists, where it originated, or what assumptions it encodes. 

This shift underpins what many now call “vibe coding”: a workflow optimized for speed, flow, and creativity. But as understanding erodes, so does security – because code that moves fast without clear intent is harder to reason, review, and fix. 

When no human truly understands or owns the code, accountability breaks down. And security programs built around human authorship are incompatible with this new reality. 

Welcome to the Agentic Development Lifecycle (ADLC) 

Modern development is no longer purely human-driven. In the Agentic Development Lifecycle (ADLC), humans and autonomous agents collaborate at machine speed, requiring trust in AI-generated code and guardrails that protect security without slowing delivery. 

For now, humans remain in the loop. But as trust in AI grows, human involvement will naturally decrease, raising a critical question for security teams: what happens when the loop gets smaller? 

As fewer human eyes review code and more decisions are made autonomously, traditional security assumptions break down. The idea that someone will “catch it later” becomes not just unrealistic, but dangerous. 

Compounding this shift is a growing myth that AI produces clean, secure code by default.  

The data tells a very different story. 

Research from BaxBench shows that Claude 4 Sonnet generates insecure code in over 24% of tested scenarios. And Stanford study found that developers using AI assistants wrote significantly less secure code than those without access to AI – but were more likely to believe their code was secure. 

AI doesn’t eliminate risk, it industrializes it. Here’s what that looks like in practice: 

• Hallucinated logic: Code that compiles and passes tests but encodes incorrect assumptions or missing validation. 
• Dependency amplification: AI-suggested packages introduced without awareness of provenance or exploit history. 
• Insecure defaults at scale: AI reproduces insecure patterns faster than teams can review or correct them. 
• Context loss: Generated code that diverges from internal standards because the AI lacks organizational context. 

There’s a clear pattern. As AI usage increases, code is delivered more quickly, but issues are introduced at the same pace. 

The Software Supply Chain You Can’t See 

s AI becomes more embedded in development workflows, the software supply chain expands well beyond source-code and open-source libraries. Today’s applications increasingly depend on foundation models, fine-tuned LLMs, coding agents, IDE extensions, MCP servers, prompts, embeddings, and configuration artifacts. 

Each of these components introduces its own attack surface. Unlike traditional dependencies, many of them operate as black boxes, offering little visibility into how decisions are made or what assumptions are embedded. 

This creates a fundamental challenge for security teams. You can’t protect what you can’t see, and without clear visibility into which AI components are active and how they’re used, organizations are left placing trust in systems they don’t fully understand. 

This isn’t just a larger supply chain. It’s a less transparent one. 

Scanning After the Fact Doesn’t Work 

Despite these changes, many organizations still rely on post-commit scanning and downstream security gates. These approaches were designed for incremental development and human-paced review cycles – assumptions that aren’t relevant in AI-driven development. 

When code is generated continuously and autonomously, security applied post-commit becomes reactive by definition. Findings arrive long after decisions were made, forcing developers to context-switch, rework AI-generated code they did not write, and interpret results that no longer reflect original intent. 

At AI speed, reactive security quickly loses effectiveness. 

In an AI-driven development model, the only reliable point of control is the moment code is created. Once AI-generated code is accepted and committed, risk has already propagated across repositories, pipelines, and services. 

This requires a fundamental shift in how application security operates. Instead of scanning code after the fact, security must study code, intent, and context in real time, operating at the same AI speed generating the code. 

In this model, prevention replaces detection as the primary objective. 

The IDE Is the New Perimeter 

As AI-native IDEs take on more work – writing code, choosing dependencies, making architectural decisions – they become the place where software decisions are made. This is where trust is built or broken. Every AI-assisted action can introduce risk, but security tools that run outside the IDE typically catch problems too late to matter. 

Building security directly into the IDE allows teams to catch problems the moment code is written. Security becomes part of everyday development, not a separate step at the end. 

That shift has a measurable impact. When security issues are prevented in real time and pre-commit, risky code is stopped before it ever exists. In fact, embedding security directly into the IDE eliminates 90% of security rework. Most issues never enter the backlog, never fail CI, and never become production risks. 

This isn’t about fixing problems faster, it’s about eliminating entire categories of work that only exist when vulnerabilities are discovered after the fact. Once issues slip past commit, developers are pulled into a familiar cycle: 

• Context switching and rebuilding mental models 
• Debugging root causes in unfamiliar or AI-generated code 
• Fixing and refactoring under delivery pressure 
• Rerunning builds and waiting on CI pipelines 
• Back-and-forth PR comments and security reviews

Catching issues early in the IDE removes that downstream work entirely. Problems are surfaced inline, explained in developer-friendly terms, and resolved while the code and context are still fresh. 

Organizations that succeed will not be those that blindly trust AI-generated code, but those that recognize a harder truth: AI-generated code moves fast only when security moves with it. 

Agentic AppSec in Practice 

Checkmarx Developer Assist was built for this exact shift. It embeds agentic application security directly inside the IDE, operating alongside AI-coding tools to detect risk and prevent vulnerabilities from the moment code is created. 

By catching and fixing issues pre-commit, Checkmarx Developer Assist helps teams eliminate rework, reduce noise, and move at AI speed without sacrificing security. 

If your security strategy still acts like your code is written by humans, it’s time to rethink your stack. 

You can try Checkmarx Developer Assist for free and see what real-time, IDE-native AppSec looks like in practice. 

The SDLC assumed that code was written primarily by humans, progressed through recognizable phases, and paused naturally at points where review made sense.  

Security controls were layered onto those pauses – during pull requests, before releases, or after builds – because that’s where time existed to apply them. 

Those assumptions are becoming obsolete.  

The SDLC Mental Model Is Breaking 

AI has changed how code comes into existence. An increasing number of modern codebases are now generated, modified, and refactored continuously, often without a clear distinction between “writing,” “fixing,” and “improving.” 

The lifecycle no longer advances in steps or clear breaks. It loops. 

Once that happens, many of the places where AppSec traditionally operated, like stage gates, handoffs, centralized review queues, lose their effectiveness. They weren’t designed for continuous change, and they weren’t designed for machine-paced production. 

What ADLC Actually Describes 

The Agentic Development Lifecycle (ADLC) is a new methodology that is shaping a new reality. 

In an ADLC environment, humans and AI systems work together to produce and evolve software continuously. Developers guide intent and direction, while AI systems generate, transform, and extend code at a rate that no longer maps cleanly to phases or milestones. 

This changes the unit of work AppSec has to reason about: Instead of releases or pull requests, security has to contend with a constant stream of small, fast-moving changes. 

Why Existing AppSec Models Struggle 

Most AppSec programs were built around interruption: stop here, scan there, review later. That approach assumes development can afford to wait. 

In ADLC, waiting becomes part of the risk. 

Centralized security teams cannot manually review the volume of code produced by AI-assisted workflows, and stage-based tooling struggles to stay relevant when code is rewritten multiple times before it ever reaches a traditional checkpoint. 

There’s also a growing false sense of safety around AI-assisted development.  

Because AI-generated code often looks clean, idiomatic, and well-structured, it’s easy to assume it is safer than hand-written code.  

In practice, it frequently reproduces insecure patterns, makes inconsistent trust assumptions, and introduces vulnerabilities that are harder to spot precisely because they appear reasonable. 

The impact is felt on both sides of the organization: Security teams lose timely visibility and effective control as AI accelerates code creation beyond traditional review models.  

At the same time, developers experience security as an after-the-fact interruption, flagging issues in code that has already changed.  

ADLC exposes a fundamental mismatch: tools designed for sequential development cannot keep pace with AI-driven workflows without compromising either security or speed. 

What AppSec Has to Become 

If development is continuous, security has to operate continuously as well. 

That means security systems need to evaluate code as it is created and modified, not after the fact. They need to understand context – how a piece of code fits into a broader system – and they need to act without relying on human intervention for every decision. 

This is where agentic AI becomes necessary rather than aspirational. Security systems need the ability to reason about changes, apply organizational policies automatically, and persist alongside development rather than responding to snapshots. 

In practical terms, this pushes AppSec closer to where development decisions are made: inside the IDE and before changes are committed. It’s where developers’ convenience and necessity intersect, because that’s where intent is expressed and where correction is still cheap. 

The Developer Workflow Is Changing 

As AI takes on more of the mechanical aspects of coding, developers spend more time directing, validating, and integrating output. Security decisions increasingly happen implicitly, through what developers accept, reject, or modify. 

Independent research such as the BaxBench benchmark, which measures how well large language models generate backend applications that are both functionally correct and secure, shows a stark reality:  

Even flagship models frequently produce code that may or may not work but still contain security vulnerabilities. In the BaxBench evaluation, many generated programs that passed functional tests still failed security checks when exposed to expert-designed exploits, indicating that correctness and security don’t automatically coincide in AI-generated outputs. 

AppSec has to align with that reality. Guidance that arrives late or requires developers to context-switch will be ignored, regardless of policy. Guidance that arrives in-line, with enough context to be actionable, has a chance to influence outcomes at scale. 

This doesn’t eliminate governance. Organizational standards, risk tolerances, and compliance requirements still matter. What changes is how they are enforced: automatically and continuously, rather than episodically and manually. 

Organizational Consequences 

In many organizations, this shift is already reshaping responsibility boundaries. AppSec capabilities are beginning to intersect more closely with platform engineering and emerging AI engineering teams, reflecting the fact that security, developer experience, and AI systems are now tightly coupled. 

Security becomes less about approval and more about enablement, providing guardrails that operate at the same speed as development rather than trying to slow it down. 

Closing 

ADLC doesn’t leave much room for AppSec to catch up later. Code is produced continuously, changes compound quickly, and delayed feedback becomes indistinguishable from no feedback at all. 

That reality forces a simple conclusion: security has to operate inside the development loop itself, aligned to how software is actually produced in an AI-driven lifecycle. 

Checkmarx.dev offers a view on what ADLC-oriented security looks like in practice, with Checkmarx Developer Assist – an agentic security linter that operates directly inside supported IDEs to evaluate risk as code is written – before commits, pipelines, or handoffs exist.  

Developers and AI engineers can try it hands-on through a free trial in IDEs like VS Code, Cursor, Windsurf, and AWS Kiro. 

If SDLC framed how AppSec worked for the last decade, ADLC will define what works next. 

Learn more and get your free trial at https://checkmarx.dev 

This article was originally published on Checkmarx’s LinkedIn Newsletter, “The Monthly Checkup”.

But then things changed, like the moment Will Byers disappeared and Hawkins realized something was very wrong. The stack changed from being a simple concept that could be sketched on a whiteboard into a sprawling ecosystem of interconnected services and unpredictable components. Applications pulled in open-source dependencies with their own release calendars. Temporary workarounds quietly hardened into permanent architecture.  
 
Today’s network applications can be like the “Upside Down,” sprawling, unpredictable, and capable of chaos if left unchecked. For developers and AppSec professionals, this complexity is a force multiplier for risk.  
 
Checkmarx may not be a hoodie-wearing, Eggo-waffle loving, telekinetic superhero like 11  (brilliantly portrayed by actor Millie Bobby Brown). But it does deliver something close to a sixth sense for software: a unified, scalable security platform that spots hidden issues early and stops vulnerabilities from ever crossing into production. 

Welcome to the Secure Side of the Upside Down  

The boundary between “shipping software” and “securing software” is now mostly imaginary, like the line between “front end” and “back end” in a microservices repo with 47 folders named “shared.” Developers aren’t being dragged into security like the Demogorgon that got Barb. They are choosing it.  

In Stack Overflow’s 2025 Developer Survey, when developers were asked what would turn them off or cause them to reject a technology, the #1 deal-breaker was “security or privacy concerns.” It outranked pricing, usability, and even the availability of better alternatives.  

That’s not a minor preference. It’s P-0 level ticket hitting the Jira workflow like a global outage. Security is no longer optional. It is the ultimate deal-breaker. 

The New Hawkins Heroes: Developers as Defenders

A transformational shift is happening in software development: those who write the code are becoming responsible for defending it. Developers are the new defenders. 
 
Developers sit at the epicenter of risk, seeing firsthand how vulnerabilities creep in through everyday actions: IDEs, pull requests, CI/CD pipelines, and production deploys. Like performance and reliability, security is a critical component that can make or break a product. 

With at least 41% of code being generated by AI (and climbing) that shift doesn’t just accelerate velocity. It multiplies complexity. More components, more integrations, more code paths, and more chances for something small to become something serious. Every new link in the chain is a potential point of failure. 

The good news? Developers are stepping up. 

In GitLab’s 2024 Global DevSecOps Report, 58% of respondents agreed to some degree that they are primarily responsible for application security. A 2025 survey of 200 global CISOs sponsored by Checkmarx found that “well over half… (56%) said most of their development teams are fully integrated into application security programs, with 41% soliciting feedback from developers to improve security processes.” 

Two important takeaways hide in this research. 

First, developers aren’t “taking on security” as a philosophical statement. They’re doing it as a practical necessity because that’s where the leverage is. Security that arrives late arrives expensive.  

Second, the shift doesn’t mean security teams fade into history like Steve Harrington’s big hair and high-waisted jeans. It means the operating model changes. 
 
AppSec teams still own standards, governance, and threat expertise, but more of the day-to-day prevention happens now happens upstream in the developers’ workflow, where agentic AI for application security empowers them to code fast and keep shipping without compromise.  
 
Of course, this doesn’t mean security teams have less to do. Prevention is now critical in early in the development life cycle, but security teams still face a constant stream of threats and issues to keep them busy. This evolution frees them up to think more strategically and focus on challenges like organizational risk, governance, and compliance. (By the way, Checkmarx research found that only 18% of organizations have AI governance policies in place. That’s data for another episode, er, blog .) 

Vecna-Proof Your Releases 

So, if you want developers to be more in-step with security, the question isn’t “how do we convince them?” 

The question is: how do we make secure behavior the easiest behavior? 

We’re entering an era where intelligent agents assist developers in real time, catching risks as code is written, offering context-aware fixes, and reducing remediation times from hours to seconds. The agentic future of Application Security is our top priority at Checkmarx, focusing on developers-first application security with a  family of agents who bring real-time, context-aware prevention. 
 
The stack is complicated but our mission is simple: secure code as it’s created, so teams move fast without adding risk. It’s the same instinct that kept the Stranger Things crew alive: don’t wander into the dark without a plan, and don’t ignore the weird noise just because you’re in a hurry. 
 
Spoiler alert: in the Stranger Things finale, Joyce Byers (the amazing Winona Ryder) delivers well-earned justice with an axe to eliminate the evil Vecna, ruler of the Upside Down. In today’s software world, developers are the defenders—and Checkmarx is the protection they can wield to eliminate vulnerabilities before they turn your stack upside down. 
Learn more about the future of Application Security.

Today, developers don’t just use AI to write code, they’re relying on AI coding assistants like GitHub Copilot, Cursor, and Windsurf to generate entire functions, suggest architecture patterns, and accelerate feature development.  

To support this shift, the security industry must evolve – and Checkmarx is leading the way with new AI capabilities like Checkmarx One Assist and Checkmarx Developer Assist. These tools autonomously prevent and remediate vulnerabilities across the SDLC, catching issues pre-commit and enforcing security policies throughout pipelines. 

While agentic AI can automate much of application security, there’s still a critical piece of security that teams need: the ability to customize SAST detection to the unique patterns, frameworks, and business logic of their applications. 

That’s why AI Query Builder for SAST, now generally available, is more important than ever. 

Why SAST Customization Matters More in 2026 

When developers use AI assistants to build applications, they end up creating highly diverse implementations across custom frameworks, internal libraries, and organization-specific patterns that standard security rules often miss. 

Out-of-the-box SAST queries are built to detect common vulnerabilities in standard code patterns  – they’re excellent at finding SQL injections in typical database calls or XSS in well-known frameworks. But your organization doesn’t just use standard patterns anymore. You have: 

Custom security frameworks that sanitize inputs in ways traditional SAST doesn’t recognize, leading to false positives that waste developer time 

Internal libraries that introduce organization-specific vulnerabilities that standard queries miss, creating coverage gaps

Business-critical logic with unique security requirements that need tailored detection such as industry-specific handling of PII patterns When SAST tools aren’t tuned to reality, two things happen: 

• False positives erode trust. Developers get flagged for using approved sanitizer because SAST doesn’t know it exists. Too many false positives cause developers to ignore security findings. 
• Coverage gaps leave vulnerabilities. Your team built a custom authentication system, but your SAST can’t detect flaws in it, so vulnerabilities slip through to production. 

The traditional solution to these problems was to hire SAST experts who understood query languages and security patterns and then wait for them to manually write custom detection rules. This solution doesn’t scale – especially when AI is accelerating development velocity and security teams are already stretched thin.

Something needed to change.

The Value: Making Security Expertise Scalable 

AI Query Builder removes the expertise barrier that has long limited SAST customization. 

For security teams, this means you can respond to threats at the speed your organization moves. When developers adopt a new internal framework, you don’t need to wait weeks for a query expert to write new detection rules. You describe what you want to detect and AI generates the CxQL query in minutes. Want to iterate on it or test against your codebase? No problem – and you’ll still be able to deploy it the same day. 

For developers, this means fewer false positives and more relevant security guidance. When your security team can quickly finetune SAST to understand your code patterns (sanitzers, frameworks, security controls), you stop getting flagged false positive. And, the findings you do get are more likely to be real issues that need your attention. 

For AppSec managers, this means you can scale security coverage without scaling headcount. Your team doesn’t need deep CxQL expertise to create custom queries, enabling more people to contribute to security tuning and make your program more responsive and comprehensive. 

Checkmarx’s AI Journey Since 2023 

When we launched early access to AI Query Builder in 2023, we already saw how rapidly AI would transform security tooling – and since then, we’ve continued to push that AI innovation forward across our platform.  

We introduced AI-powered remediation that automatically suggests fixes for vulnerabilities across SAST, SCA, secrets, and IaC. Our agentic AI capabilities, Checkmarx One and Checkmarx Developer Assist,  autonomously prevent and remediate security issues, from real-time protection in the IDE to continuous policy enforcement across CI/CD pipelines. AI Query Builder was ahead of its time. Today, in a world where AI touches every part of the development and security lifecycle, it’s exactly the right capability at exactly the right time. 

While AI agents automate prevention and remediation, AI Query Builder lets security teams customize the intelligence behind that detection itself. It ensures that your SAST scans –  whether triggered manually, in CI/CD, or as part of broader security workflows – understand your unique code patterns and security requirements. 

Because AI in security isn’t just about automation, it’s about democratizing expertise. Making it possible for more people on your team to do work that previously required specialized knowledge, enabling security to scale with development velocity instead of being perpetually behind. 

How AI Query Builder Works 

AI Query Builder is built for SAST query creation. 

The Basic Workflow 

1. Describe the security concern in natural language 

Instead of writing CxQL syntax, you describe what you want to detect. For example: 

• “Detect SQL injection vulnerabilities in our custom DatabaseWrapper class when user input flows into the executeQuery method” 
• “Find authentication bypass risks when JWT tokens are validated using our internal TokenValidator library”
• “Identify command injection when shell commands are constructed using string concatenation in our deployment scripts” 

2. AI generates the CxQL query 

The system translates your description into proper query syntax, understanding: 

• Data flow analysis (how user input moves through your code)
• Sanitization patterns (what makes input safe or unsafe)
• Framework-specific APIs (your custom classes and methods)
• Security patterns (what makes something a vulnerability) 

You can then adapt or customize as needed. 

3. Test against your codebase 

The generated query runs immediately against your actual code, so you see real results, not theoretical examples. This helps you ascertain that the query catches what you want and isn’t flagging false positives. 

4. Refine and iterate 

If the query isn’t quite right, you can: 

• Adjust your natural language description and regenerate
• Manually edit the CxQL for finetuned control
• Test different variations to find the best balance of coverage and precision 

5. Deploy to your scanning presets 

Once validated, the custom query becomes part of your SAST scanning configuration, and every subsequent scan can use this customized detection logic. 

What Makes This Different? 

Most “AI for code” tools are general-purpose language models trying to generate any kind of code. But AI Query Builder is specialized: 

Domain-specific intelligence: Trained specifically on security patterns and CxQL syntax, not general-purpose coding 

Context-aware: Understands the relationship between sources (user input), sanitizers (validation), and sinks (dangerous operations) 

Framework-flexible: Can adapt to your custom frameworks and libraries, not just public ones 

Integration-native: Works directly in Checkmarx One. No export/import workflows, no separate tools to learn

For example, when you say “SQL injection in our custom database wrapper,” the system know that it needs to: 

1. Identify where user input enters your application 
2. Trace data flow through your specific DatabaseWrapper class 
3. Check if input passes through sanitization before reaching the database call 
4. Generate a query that catches this specific pattern without flagging safe uses 

This level of specialization is what makes AI Query Builder reliable for production security work. 

Example: Tuning for False Positive Reduction 

Picture this scenario: Your organization uses an in-house sanitization library, called SecureValidator, that properly prevents XSS attacks. However, your SAST doesn’t know about this library, so it flags every use as a potential vulnerability. 

Without AI Query Builder, you’d need to: 

1. Find a query expert who understands CxQL 
2. Locate the existing XSS detection query 
3. Manually add your SecureValidator methods to the sanitizer list 
4. Test the modified query 
5. Deploy it 

This would take hours – even or days, assuming you actually have someone with the expertise available. 

With AI Query Builder, you: 

1. Describe: “Update the XSS query to recognize SecureValidator.sanitizeHtml() as a valid sanitization method”
2. Generate the modified query 
3. Test it immediately 
4. Deploy 

This takes minutes. Your developers See immediate impact and security findings become more trustworthy. 

Example: Expanding Coverage for Custom Code 

And here’s another example: Your team built a custom authentication system with a method called AuthManager.validateSession(). You want to detect when session tokens are used without proper validation. 

Without AI Query Builder, you’d either: 

1. Accept that SAST won’t catch this vulnerability pattern, or 
2. Hire a consultant to write a custom query, or 
3. Wait for your internal query expert to have bandwidth (probably weeks) 

With AI Query Builder, you: 

1. Describe: “Create a query to detect when session tokens are used without calling
2. AuthManager.validateSession() first” 
3. Generate and test the query 
4. Deploy it to production scanning 

Your coverage expands to include organization-specific security patterns that no standard tool would catch. 

The Bigger Picture: Security Adapting to AI-Accelerated Development 

When developers use AI to code faster, security also needs AI to adapt faster. AI Query Builder ensures your SAST detection evolves just as quickly as your applications do. 

The same way AI coding assistants have made developers more productive, AI security tools make security teams more responsive, comprehensive, and effective. 

AI-powered remediation helps fix vulnerabilities faster and AI-powered prioritization helps team focus on what matters. AI-powered query building is the final piece of properly leveraging AI by detecting the right things in the first place. All together, these AI capabilities enable security programs to scale alongside modern development practices instead of being left behind. 

Getting Started 

AI Query Builder is available now to all Checkmarx One customers with SAST. 

To start using it: 

1. Navigate to your SAST workspace in Checkmarx One
2. Access the Query Builder interface 
3. Describe a security concern you want to detect 
4. Generate, test, and refine your query 
5. Deploy it to your scanning presets

Full documentation available here 

For teams just getting started with SAST customization, we recommend beginning with false positive reduction. Identify the most common false positives your developers encounter and use AI Query Builder to tune queries to recognize your security controls. This immediate impact on developer experience builds trust and demonstrates value quickly. 

For teams already doing query customization, AI Query Builder accelerates your existing workflow. You can prototype queries faster, test more variations, and expand coverage to more frameworks and patterns than was previously feasible. 

The future of application security is AI-assisted at every level. With AI Query Builder, your SAST detection becomes as adaptive and intelligent as the development teams you’re protecting. 

Once these AI assets land in your repositories or container images, they become part of your software supply chain. The next Log4J doesn’t have to be a package; it can just as easily be a model, an MCP, or an AI asset you didn’t even know you shipped. 

AI Supply Chain risks include any risks introduced by AI assets that become part of your software supply chain, ranging from poisoned data, malicious or over-privileged MCPs/agents and unknown provenance.   

And yet, despite this rapid adoption, organizations can’t answer a simple question:  

What AI components are we using in our software development, and where?  

Without visibility, AI-related risk compounds: AI assets spread across codebases without security review, inventory, or policy controls, creating new blind spots or widening existing ones across your software supply chain.  

Why Most Organizations Lack Visibility into Their Devs’ AI Usage 

AI adoption is rapidly growing across organizations. In fact, our recent Future of AppSec report found that one in three respondents said over 60% of their organization’s code is written by AI.  Yet only 18% have any sort of AI governance in place. 

This combination of rapid growth in AI usage (especially among developers), combined with a lack of oversight, has created a visibility gap fuelled by fragmentation and tooling that was never built to address AI‑specific risks. 

Here are the main reasons:  

• Emergence of new AI-focused protocols and technologies. Example: MCP  (Model Context Protocol) was introduced only in November 2024. 

• AI fragmentation (Copilot, Claude, Microsoft, OpenAI, etc.). Multiple providers, teams picking different tools, no standardization. Lots of tools with different security approaches. 

• Code security and Supply Chain Security require different approaches. AppSec tools are evolving to detect AI-related code vulnerabilities—identifying prompt injections, tracking sensitive data flows to LLMs, and flagging improper output handling. This addresses how developers write and use AI in their code. But a separate challenge remains: gaining visibility into what AI assets exist across your software supply chain. Traditional scanners analyze data flows and patterns but AI supply chain security requires comprehensive asset inventory, provenance tracking, and governance. 

What is the AI Inventory Gap? 

The AI Inventory Gap refers to all the AI-related components embedded in your applications that your organization hasn’t tracked, reviewed, or governed, yet still ships as part of your software supply chain. 

It typically includes: 

• Models & weights: Pre-trained or fine-tuned LLMs, CV models, embeddings 

• Agent frameworks: A software toolkit and structure for building, managing, and orchestrating autonomous AI agents 

• MCP servers: Program that enables AI models, particularly large language models (LLMs), to access external data, tools, and workflows, acting as a bridge for AI agents to interact with the real world. 

• Datasets: Training and evaluation data, sometimes with sensitive or licensed content 

• Prompts: Operational logic dispersed across code and configuration 

• AI libraries & integrations: SDKs, connectors, and wrappers that pull AI into runtime 

The Risks of the AI Inventory Gap 

When AI components operate without control, the consequences are serious: From hidden attack surfaces, operational surprises, compliance failures, to reputational damage, often discovered only after an incident or audit begins. 

Key risks include:  

• Model poisoning: Silently introduces backdoors, blind spots, or biased behavior that attackers exploit without detection 

• Unverified or malicious weights: Sourced from unknown origins without integrity checks. Unverified or malicious weights are like running untrusted binaries, they  can expose you to remote code execution, contain hidden payloads or logic or create backdoors for data exfiltration or resource abuse. 

• Dataset exposure: Sensitive or licensed data leaked via training, prompts, or logs 

• Unsafe agents & tools: Autonomous agents that can access files, networks, or services without guardrails 

• Unpinned versions: Silent updates to models or libraries change behavior and risk posture overnight. Unpinned versions can allow unexpected or malicious updates to be introduced automatically, leading to supply-chain attacks, breaking changes, or non-reproducible and insecure builds. 

• Compliance gaps: Missing documentation, provenance, and audit trails lead to penalties and delays 

AI Governance: Can You Trace Every Model, Dataset, and Dependency? 

AI adoption is following a pattern similar to what we see with open-source software: developers move fast while governance lags behind.  

The expectation from a compliance point of view is that reporting and keeping an inventory of AI components is no longer optional 

But the reality is messy: 

• Regulatory Expectations Are Rising: frameworks and regulations (e.g., EU AI-related requirements, AI governance standards) demand accountability and evidence, teams lack the tooling to inventory, assess, and report on AI usage across the enterprise. Compliance becomes reactive and costly.  

• Developer-Led AI Adoption Outpaces Governance: Developers integrate models, datasets, and frameworks to solve real problems fast. If governance processes are slow or unclear, people ship and promise to “clean it up later.” Those quick wins become permanent dependencies, often without reviews, version pinning, or provenance checks. 

• Fragmented Work Processes Makes Inventory Hard: AI usage spans multiple teams and repos: data science, platform engineering, mobile, web, back-end, cloud functions. Without a central AI inventory, leadership cannot answer basic questions about what AI assets are being used, deployed, and what risks are attached. This leads to reactive security, and the risk of having to deal with vulnerabilities after it’s too late.  

• No Clear Ownership of AI Governance: Developers are focused on shipping features. They experiment with models, libraries, MCPs, and agent frameworks to solve problems quickly—not to define governance boundaries or maintain inventories. 

Application security teams, meanwhile, are often left to document and report on AI usage after the fact. They’re suddenly asked to answer questions about models, datasets, and agents embedded across the software supply chain, without the visibility or tooling needed to do so. 

At the leadership level, responsibility is also often fragmented. CTOs drive adoption and velocity, CISOs are accountable for risk and compliance, and no single function clearly owns end-to-end governance of AI assets. The result is predictable: AI moves fast, ownership stays unclear, and Shadow AI fills the gap. 

What can Organizations do about it? 

AI inventory isn’t a problem you solve with a single control. It requires ownership, visibility, and governance embedded into how software is built. 

This is a relatively new challenge, and while tooling is evolving, organizations can take concrete steps today to regain control: 

• Decide on a clear owner of AI inventory, with defined responsibilities and authority, to whom other teams report. 

• Baseline your AI usage: Run deterministic discovery across prioritized repos and services to build an initial inventory. 

• Classify & assess risks: Tag assets by type (model, agent, dataset, prompt, library) and apply AI-specific risk checks. 

• Generate AI‑BOMs: Produce standards-aligned BOMs with provenance, licensing, dependencies, and risk metadata. 

• Define your policies: Blacklist/whitelist of assets, acceptable risk thresholds, block build for specific type of risks, etc. 

• Embed governance where work happens:  

• Add PR checks, CI/CD gates, and dashboards to enforce policies and track trends. 

• Measure & iterate: Monitor coverage, findings, MTTR, and compliance posture. Expand to more teams, apps, and environments. 

Final Thoughts  

AI has moved beyond the experiment phase. It is now part of the day-to-day reality of modern development teams, already deeply embedded into modern software stacks. But without visibility, every untracked model, dataset, or agent becomes a potential vulnerability.  

The bottom line? If you can’t see the AI in your software, you can’t control the risk.  

LLMs now accelerate how code is written, refactored, and merged. Traditional “scan-and-fix later” workflows can’t keep up with that pace; they push findings downstream, inflate rework, and slow releases. The financial impact shows up as extra PR rewrites, pipeline reruns, context switching, and escalations.  

The fix is to move AppSec to the point of creation, inside the IDE, so issues are prevented or remediated while the developer’s mental stack is fresh. 

Agentic AppSec is autonomous, context-aware assistance that validates and remediates during coding, not after the commit. Gartner frames this category as AI Code Security Assistance (ACSA); Checkmarx One Assist operationalizes it through Developer Assist. 

A Practical ROI Model You Can Take to Your CFO 

For all the talk about developer productivity and AI acceleration, most AppSec leaders still struggle to express value in the language of finance. Your CFO doesn’t want “shift left” jargon and vulnerability counts, they want a structured model that translates engineering efficiency into measurable return. 

When we analyze ROI for Checkmarx One Developer Assist, we focus on five value buckets that both finance and engineering already recognize. Each ties directly to operational metrics your leadership team tracks, making it easy to build a defensible business case for Agentic AppSec: 

1. Mean Time to Remediate (MTTR) 

Inline findings and explainable fixes inside the IDE compress triage and remediation from hours to minutes. Since developers resolve vulnerabilities in context, fewer issues escape to late-stage testing or production, where every fix costs exponentially more. The result is measurable improvement in DORA MTTR and a more predictable release cadence. 

2. Throughput (Features per Period) and Lead Time for Changes 

Every context switch, jumping from IDE to portal, waiting on a review, or rerunning a build, creates friction that slows throughput. When developers fix in-place, PR churn decreases and pipelines stabilize. That efficiency shows up directly as more completed work per sprint and a measurable reduction in Lead Time for Changes, one of the most visible metrics to executives tracking delivery velocity. 

3. False-Positive Drag

Noise has a cost. Each false positive wastes time erodes trust in tools, and slows adoption. By combining high-fidelity detection with explainable remediation, Developer Assist reduces alert fatigue across the SDLC. A Checkmarx case study found that Best Buy reduced false positive by 80%, illustrating the real economic drag of noisy security and the ROI of precision. 

4. Rework and Failure Cost  

Rework is one of the most underestimated drains on engineering productivity. Every post-merge defect triggers retesting, re-review, and sometimes a full CI/CD rerun. By catching vulnerabilities inside the IDE, Developer Assist prevents this expensive cycle before it begins. The result is fewer failed builds, lower operational overhead, and more stable release plans, which are benefits that directly translate into reduced operational expenses (OpEx) and improved predictability. 

5. Developer Experience (Retention and Flow) 

Security tools succeed or fail on adoption. If they slow engineers down, they’re disabled or ignored. Developer Assist meets developers where they work, offering AI-powered help that feels like collaboration, not interruption. Tools that improve flow and reduce cognitive friction boost both sentiment and retention, gains that compound over time into sustainable throughput and morale. 

A CFO’s Takeaway 

When you put it all together, these five metrics – TTR, throughput, false-positive drag, rework cost, and developer experience – form a complete Agentic AppSec ROI model. It ties productivity, quality, and cost together in one narrative that resonates from the engineering floor to the boardroom. Agentic AppSec is a measurable accelerator of business outcomes. The data is already in your DevOps pipeline, and the only question is whether you’re ready to quantify it. 

Mechanics, Not Magic, Make Value 

Every second counts when prevention happens in the IDE. By embedding detection, validation, and remediation directly where developers work, the result is measurable productivity and stronger security posture at the same time. 

Detect earlier, fix faster (MTTR and failure avoidance) 

Developer Assist analyzes source, manifests, IaC, and container descriptors as you type, surfacing explainable findings and one-click “Fix with Assist” flows right in the editor. Early detection reduces “late discovery” work and lowers the chance of broken builds. 

Explainable AI remediation (trust drives adoption) 

Structured prompts plus verified remediation data mean developers see why a change is needed, not just a diff. That “explain then apply” pattern speeds reviews and keeps security aligned to developer intent: critical for sustained adoption. 

Integrated coverage (fewer tools, fewer gaps) 

Because Developer Assist is powered by the Checkmarx platform, teams benefit from proven detection across SAST, SCA, IaC, secrets and container risks delivered in a consistent, IDE-first workflow. Reducing tool switches and consolidating signals also simplifies reporting upstream. 

When AppSec becomes an active participant in development, not a passive gate at the end of it, security scales with the speed of code creation. Developer Assist bridges that gap, merging developer efficiency with enterprise-grade validation. The impact is cumulative: fewer missed vulnerabilities, faster clean builds, and quantifiable time savings that turn secure coding into a measurable business advantage. 

Estimate Your ROI in Two Steps 

Step 1: Time saved per issue 

• Without IDE-level remediation: assume ~1–3 hours per issue (triage, rework, rebuilds).
• With Developer Assist: much of that time collapses into minutes because context is fresh and changes are applied inline. 

Step 2: Multiply by avoided rework 

• Count how many security-related build failures/reruns you had last quarter.
• Apply your blended engineering hourly rate to the time you didn’t spend reworking those PRs.

Want a walkthrough? Our team can map DORA metrics to pre- vs post-Assist performance using your pipeline data. Let’s talk. 

What Makes a Tool Actually Agentic? And Does It Matter for ROI? 

Gartner’s AI Code Security Assistance (ACSA) lens emphasizes pre-commit, intent-aware control vs reactive scanning. In practice, this means fewer defects make it to late stages (where each fix is 3–10x more expensive than in development) and the ones that do arrive are already annotated with context. That’s why agentic beats “scan later” in cost curves. 

Developer Assist pays for itself by eliminating rework at the source. When security happens in the IDE, you fix faster, ship faster, and report outcomes that resonate from dev teams to the board. 

Read More: The Executive’s Guide to Quantifying Agentic AppSec ROI, From IDE Metrics to Board-Ready Numbers. 

Download: The Agentic AI Buyer’s Guide 

By embedding explainable, real-time remediation directly into the IDE, Developer Assist helps enterprises measure impact in terms that matter to both engineering and finance: time saved, quality improved, and cost avoided.  

Here’s how to make that case with metrics your business already trusts. 

Start With Metrics Your Business Already Trusts 

The first rule of security ROI: your CFO doesn’t buy “scan accuracy”. They buy measurable outcomes that improve throughput, reduce cost, or accelerate delivery. 

That’s why the most credible ROI models for Agentic AppSec align with the DORA metrics engineering leaders already track, and extend them with quality and cost indicators. 

Lead Time for Changes (Cycle Time) 

Inline, IDE-level guidance shortens the time between code commit and deployment. 

By surfacing vulnerabilities and fixes as developers code, teams spend less time revisiting PRs or waiting on security reviews. Fewer bottlenecks mean faster feature delivery and shorter feedback loops. 

Change Failure Rate 

Agentic AppSec catches misconfigurations, insecure dependencies, and code smells before a commit, not after a build breaks. Fewer failed builds and hot-fixes translate directly to higher release stability and lower unplanned work, which impacts both velocity and engineering morale. 

Mean Time to Remediate (MTTR) 

Traditional tools force developers to context-switch between security reports and code. Developer Assist embeds explainable remediation right inside the IDE. 

Developers understand why a fix matters and can resolve it immediately, reducing MTTR across sprints and improving compliance reporting accuracy. 

False-Positive Rate 

Precision isn’t just a technical metric, it’s an economic one. Every false positive consumes developer time. Best Buy, a Checkmarx customer, reduced false positives by 80% with Checkmarx One, reclaiming hundreds of developer hours per quarter. That reclaimed time is a quantifiable efficiency gain. 

Translate Engineering Signals into Dollars 

Once you’ve anchored your metrics, it’s time to connect them to financial impact. The key is reframing engineering efficiency as cost avoidance and productivity gain. Here’s how to quantify each dimension:

Rework Avoided 

Rework is the silent tax on software delivery. Every time a vulnerability is caught post-merge, the fix requires retesting, redeploying, and re-reviewing. 

To calculate the value of avoiding that rework: 

1. Gather last quarter’s data on security-related build failures or reruns. 
2. Estimate the average time spent on each (triage + fix + retest). 
3. Multiply that time by your blended engineering hourly rate. 
4. Attribute the reduction in failures after Developer Assist adoption as the savings delta.

What you’ll find is that even a modest 10% reduction in rework yields measurable ROI: because rework compounds across builds, QA cycles, and deployment delays. 

Time-To-Value Acceleration 

Time is revenue. Faster, cleaner releases mean features reach customers sooner, accelerating the revenue recognition timeline. Developer Assist’s inline guidance prevents bottlenecks that block PRs or delay merges. Tie your improvement in Lead Time for Changes directly to your product roadmap milestones. Finance already understands the concept of time-to-market; now they’ll see how in-IDE AppSec directly impacts it. 

Alert Fatigue Reduction 

Noise doesn’t just frustrate developers, it drains resources. Every false positive triggers a triage cycle that adds no business value. By reducing false positives through explainable AI and high-fidelity scanning, Developer Assist saves real hours. Use the Best Buy 80% reduction benchmark as a directional proxy in your initial model, and replace it with your own metrics after a 30-day pilot. 

What “Agentic” Changes in the Cost Model 

Executives are hearing the term Agentic AI more often, but what it really means for ROI is straightforward: it shifts AppSec from a reactive process to an autonomous, context-aware assistant. As Gartner’s framing of AI Code Security Assistance (ACSA) describes, these systems assist developers with policy-aware validation in real time, closing the gap between development and security. 

That shift has two major financial effects: 

1. Defect prevention instead of post-factum correction. 
   Fewer defects reach production, and those that do carry richer metadata for faster triage. 

2. Cost compression. 
   The cost of fixing a defect late in the lifecycle is 3–10x higher than fixing it during development. By detecting and resolving issues at the creation point, Developer Assist drives a direct cost avoidance multiple. 

In essence, agentic AppSec redefines security from a cost center into a throughput engine, one that pays dividends in efficiency, developer satisfaction, and customer trust. 

From Metrics to Board-Ready Outcomes 

Agentic AI AppSec doesn’t just change how developers work; it changes how executives justify security investment. By reframing technical metrics into measurable outcomes like reduced rework, accelerated delivery, fewer false positives, and higher developer efficiency, Developer Assist gives both CISOs and CFOs a clear ROI narrative supported by real data. Security isn’t slowing you down anymore. It’s making every release faster, safer, and smarter. 

How Checkmarx One Developer Assist Implements Agentic for ROI 

Inline Prevention and Explainable Fixes

The combination of IDE-native detection and explainable remediation shortens MTTR and reduces Change Failure Rate, two Google DORA metrics with direct Operating Expenses impact. 

Fewer Tools to Juggle, Clearer Reporting Up the Stack 

Because Developer Assist is powered by the Checkmarx platform, you get consistent detection across SAST/SCA/IaC/Secrets/Containers with in-IDE guidance, and unified reporting for execs. That reduces swivel-chair time and makes trend reporting credible. 

Adoption That Sticks 

If developers don’t trust a tool, it won’t move metrics. Checkmarx content emphasizes just-in-time, in-flow assistance that teaches while fixing, which is critical for sustained adoption and compounding ROI. 

Your 30-Day Proof Plan (Feel Free to Copy/Paste) 

Week 1 – Baseline 

• Extract last-quarter DORA metrics (Lead Time, Change Failure Rate, MTTR). 
• Pull counts for security-related build failures and average time per failure. 

Week 2 – Pilot

• Enable Developer Assist for 1–2 active teams in VS Code/Cursor/Windsurf. 
• Track: inline fixes applied, PRs with fewer revisions, build failures avoided. 

Week 3 – Compare

• Contrast pilot teams vs. control on DORA metrics + failure counts. 
• Capture anecdotal feedback on explainability and dev flow. 

Week 4 – Roll-up 

• Convert time deltas into dollar savings. 
• Exec slide: “From IDE events → DORA improvement → cost avoided.” 

FAQs Execs Will Ask (and Concise Answers) 

Is this just SCA in the editor? 

 No. Developer Assist brings in-IDE guidance backed by the Checkmarx platform across code, dependencies, IaC, secrets, and container descriptors with explainable remediation, not just alerts. 

How is this different from reactive scanning? 

 It prevents issues before they hit the repo/CI and annotates fixes with context developers understand, improving both MTTR and adoption.  

Is there analyst alignment for this approach?  

Yes! Gartner’s AI Coding Security Assistant (ACSA) concept describes exactly this: policy-aware assistants validating code at creation. 

Close the Loop Between the IDE and the Boardroom 

Agentic AppSec isn’t a cost center; it’s a throughput engine. With Developer Assist, leaders see cleaner sprints, fewer reruns, faster releases, and measurable MTTR gains, all traceable to in-IDE prevention and explainable remediation. 

Download: The Agentic AI Buyer’s Guide 

Read: The ROI of Agentic AI AppSec