The Old Playbook No Longer Works 

For years, security teams operated on a pragmatic assumption: not every vulnerability is equal. Prioritize critical and high-severity findings. Let medium and low age in the backlog. There was logic to this approach — resources are finite, and triaging CVSS score felt like rational risk management.

That logic is now obsolete. 

The arrival of advanced large language models has detonated the foundation beneath severity-based triage. These models do not read CVE databases the way humans do — they reason through code, identify attack vectors, and generate working exploits autonomously. The result is a threat environment where the old categories of “critical” versus “low” risk are becoming meaningless distinctions.

Consider the trajectory: in 2018, it took an attacker an average of 840 days to exploit a disclosed vulnerability. By 2026, that number has collapsed to 1.6 days. Security researchers project it will reach one minute by 2028. Meanwhile, the cost of generating a working exploit has dropped to approximately $1, achievable in 10 to 15 minutes using commodity AI tools.

The most alarming proof point arrived in April 2026 with Claude Mythos, Anthropic’s most capable model. In independent testing, Mythos achieved a 72.4% exploit success rate against known vulnerabilities — compared to 14.4% for Opus 4.6 and 4.4% for Sonnet 4.6. For context, the model designed for reasoning and safety is now among the most capable offensive security tools ever tested. 

The implication is stark: a vulnerability your team rated “low severity” and deprioritized two years ago can now be weaponized by an adversary using an AI model, in minutes, for less than the cost of a cup of coffee. The backlog is not a sorted list of future work. It is a list of open attack surfaces — every item on it, regardless of its original severity score. 

The industry is already feeling this in practice. Bug bounty programs – long structured around 30-to-60-day disclosure and remediation cycles, are collapsing under the weight of AI-speed weaponization. What once gave organizations a reasonable window to assess, triage, and patch is now measured in hours, not weeks. Security leaders who have spoken to Checkmarx’s have been consistent in their reaction: this is happening, and it is happening at a scale larger than anyone anticipated. 

The pressure extends to release cycles themselves. As new AI models emerge with increasingly sophisticated reasoning capabilities, they surface new attack vectors against existing code, meaning a vulnerability that was practically unexploitable last quarter may become a live risk the moment the next frontier model ships. Release cadences will need to become far more dynamic, with security gates that respond to the threat environment in real time rather than on a fixed calendar. 

Front One: Get the Backlog to Zero 

The first strategic imperative is a mindset shift: the remediation backlog is not a queue to be managed. It is a liability to be eliminated. Every unresolved vulnerability, regardless of its original severity rating, represents a door that a capable AI adversary can now open. 

Why Severity Scoring Has Lost Its Primacy 

Traditional CVSS scoring was designed for a world where exploiting a vulnerability required genuine expertise, time, and effort. A “low” score reflected the realistic difficulty of weaponization. That friction no longer exists. 

Advanced LLMs can reason through code the way a skilled human security researcher would — but at machine speed, at near-zero cost, and without fatigue. A vulnerability that was previously difficult to exploit because it required understanding complex application logic, chaining multiple conditions, or crafting a precise payload is now within reach of any adversary with API access to a frontier model. 

This does not mean severity scores are worthless for ordering work. It means they can no longer be used to justify inaction. A “low” vulnerability left unresolved is not a calculated risk — it is an invitation. 

The Agentic Remediation Imperative 

Getting to zero is not achievable through human effort alone. The math does not work. Security teams are already buried: 81% of companies knowingly ship vulnerable code because backlogs are growing faster than teams can manually remediate. AI-generated code compounds this further — every AI coding session produces approximately 1.7x more issues than human-written code, and roughly 45% of AI model solutions are insecure. 

The response must be agentic. Security teams need AI-powered remediation pipelines that do not just surface findings but close them — automatically, at the pull request level, prioritized by what is actually exploitable in the production environment. The goal is not faster triage. The goal is autonomous closure at scale. 

This is where attackability-based prioritization becomes essential. Not all of those 22,500 raw findings across a typical enterprise codebase represent equal danger. The critical filter is not severity — it is reachability and exploitability in the specific production context. A confirmed exploitable vulnerability in a code path that handles authentication for a production system is categorically different from a theoretical flaw in a dead code branch. Checkmarx’s fidelity funnel reduces that 22,500 raw findings to 500 actionable risks — then agentic remediation closes 7 out of 9 confirmed findings automatically. 

The proof point: mean time to remediation drops from six hours to 1.8 minutes. That is not an incremental improvement. That is a different operational model entirely. 

Remediation at Zero: What It Requires 

Getting the backlog to zero at enterprise scale requires three capabilities working in concert: 

• Attackability scoring: Confirming reachability and exploitability in the production environment, not just in the abstract. This is the step that separates signal from noise at scale. 

• Agentic fix generation: AI-generated patches applied at the PR level, validated before merge, and executed without developer interruption for the majority of findings. 

• Continuous scheduled coverage: AppSec must operate as a continuous practice, not a quarterly audit. Scheduled scan cadences normalize remediation as an ongoing operational rhythm — not a reactive fire drill. 

Front Two: Prevent at the Point of Creation 

Eliminating the existing backlog is necessary. It is not sufficient. If the prevention layer does not move left — all the way to the moment code is generated with AI — remediation teams will be permanently fighting upstream production. 

The economics of AI-generated code have created a structural problem: LLMs give developers unprecedented velocity, but they simultaneously introduce vulnerabilities at scale. Approximately one in three lines of code written today is AI-generated. Nearly half of AI model solutions contain security flaws. Old vulnerability classes that legacy SAST tools were trained to catch are being reintroduced at speed — not by inexperienced developers, but by models that do not natively reason about application security context. 

The response is not to slow AI adoption. It is to make security native to the AI development workflow. 

Security at the Prompt Level 

The earliest possible intervention is at the prompt — before insecure code is even generated. When a developer interacts with an AI coding assistant inside an IDE like Cursor, Windsurf, VS Code, AWS Kiro, or Claude Code, that is the moment to apply security guardrails. Real-time scanning engines running alongside the AI assistant can catch insecure patterns as they emerge, before they are committed, before they enter a PR, before they compound the backlog. 

This is not a suggestion to make developers slow down. Early-stage interception is faster and cheaper than downstream remediation. Fixing a vulnerability at the IDE takes seconds. Fixing it after it reaches production — or after it is exploited — takes days, or worse. Checkmarx Developer Assist users report a 50% boost in productivity precisely because security feedback arrives in context, in real time, without breaking flow. 

Security Inside the AI Pipeline 

Prevention cannot stop at the developer’s keyboard. Modern software is built not just by humans using AI, but by AI agents executing autonomous coding workflows — writing code, making commits, opening PRs, and triggering deployments with minimal human review in the loop. 

Every stage of this pipeline is a potential insertion point for security vulnerabilities: the IDE, the pull request, the CI/CD pipeline, and the AI supply chain itself. Security coverage must span the entire application development lifecycle (ADLC), not just the code repository. 

This means securing: 

• The IDE layer: real-time SAST, SCA, secrets detection, and IaC scanning as code is written. 

• The PR layer: automated scanning and agentic fix generation triggered on every pull request before merge. 

• The pipeline layer: continuous scanning integrated into CI/CD, enforcing security gates without slowing release velocity. 

• The AI supply chain: scanning MCP servers, AI agents, and AI models for embedded risks, malicious packages, and supply chain tampering — a category of risk that has no coverage in any LLM-native AppSec tool today. 

The AI Supply Chain Risk No One Is Talking About 

There is a third dimension of AI-era risk that most security programs have not yet addressed: the AI supply chain. When development teams adopt AI coding assistants, MCP (Model Context Protocol) servers, and autonomous AI agents as part of their workflow, they introduce new vectors for supply chain compromise that traditional AppSec tools were never designed to detect. 

A malicious MCP server can exfiltrate credentials or inject malicious code into an agent’s output. An AI model with embedded bias or a compromised training provenance can systematically introduce vulnerabilities, representing a scale of attacks that no human review process can match. 

Prevention at the point of inception means covering this layer too: an AI Bill of Materials (AI-BOM) that provides deterministic discovery of every AI component in the development workflow, mapped to compliance frameworks including NIST AI RMF, the EU AI Act, ISO 42001, and OWASP LLM Top 10. 

Why General-Purpose LLMs Cannot Solve This Problem 

There is a seductive narrative circulating in the market: the same AI models creating the security problem can also solve it. This is not supported by the evidence. 

In independent benchmarking, the best general-purpose LLMs detect approximately 25 to 28% of known vulnerabilities in real codebases. That means 72 to 75% of vulnerabilities remain undetected — while false positive rates run between 36 and 52%, generating exactly the kind of analyst noise that buries security teams. Claude Opus 4.6, even with strong prompting and tool access, detects only 28.5% of vulnerabilities. An AI cannot effectively self-police the code it generates. 

The structural limitations are not model-specific. LLMs lack taint tracking and data flow analysis required for true SAST. They cannot confirm reachability — Anthropic’s own documentation explicitly states that reviewing code “cannot confirm whether that code is reachable in production.” They cannot perform runtime testing (DAST). They produce non-deterministic outputs that fail enterprise audit requirements. And they have no native capability for AI Supply Chain coverage. 

The asymmetry is alarming: LLM offense improved approximately 100x between 2024 and 2026 (from near-zero autonomous exploit capability to 72.4% with Mythos), while LLM defense improved only 2x (from 12.9% to 28.5% detection rate). General-purpose models are not closing this gap. They are widening it. 

Purpose-built AppSec infrastructure — combining deterministic scanning engines, AI-augmented triage, attackability confirmation, DAST, and agentic remediation — is the only architecture designed to operate at the speed and scale this threat environment demands. 

The Two-Front Mandate 

Security leaders face a simultaneous mandate that cannot be sequenced. You cannot clear the backlog first and then shift left. By the time the backlog is cleared, the prevention gap will have refilled it. Both fronts must advance in parallel. 

Front One: Remediation-led, backlog-to-zero 

Treat every item in the vulnerability backlog as an active risk, regardless of its original severity rating. Deploy attackability scoring to confirm exploitability in the production context. Apply agentic remediation to close findings automatically at scale. Establish continuous scheduled scanning to normalize AppSec as an operational practice, not a point-in-time audit. 

Front Two: Prevention at inception 

Bring security into the AI coding workflow — at the prompt, in the IDE, inside the CI/CD pipeline, and across the AI supply chain. Security must be native to the development experience, not a gate at the end of it. When developers receive real-time, high-confidence security feedback in context, they fix issues immediately rather than generating backlog for the next cycle. 

Organizations that execute on both fronts simultaneously will emerge from the AI era with security programs that can match the pace of innovation. Those that treat remediation and prevention as sequential will find themselves perpetually behind a threat environment that operates at machine speed. 

Where Innovation and Security Move as One 

The AI era has not made application security harder. It has made the consequences of failing at it more immediate, more costly, and more visible. Adversaries now have access to the same generative AI capabilities that are powering the development productivity boom — and they are using those capabilities to compress the window between vulnerability disclosure and active exploitation to near zero. 

The organizations that will thrive are those that refuse to treat security as a trade-off against velocity. The Prevent → Resolve → Govern model — catching vulnerabilities at inception, resolving them agentically at scale, and governing continuous coverage as an operational discipline — is the architecture of that future. 

Two fronts. One risk. No vulnerabilities left behind. 

The architecture that closes both fronts is the same: a security control plane that sits outside the AI systems it governs. Checkmarx’s whitepaper on LLM Application Security breaks down exactly how — from the four critical ADLC control points to the hybrid deterministic-plus-AI framework built for the speed this threat environment demands.

Read it here.

RSA Conference 2026 has just wrapped in San Francisco. 

If you’ve been to enough of these events, you know that while they’re valuable for innovation, connection, and hearing where the industry is headed, they tend to blend into the collective memory of past events after a couple months, with little to distinguish them. 

But then there’s the 1%. 

The rare moment you recognize immediately when something shifts. 
Not a gradual step forward, but a leap. When what felt experimental or theoretical suddenly becomes real. 

RSAC 2026 felt like one of those moments. 

What set this year apart was the emergence of Agentic AppSec, not as an idea or an experiment, but rather an operational reality already being adopted and executed, as part of the growing recognition that AI-driven development is fundamentally reshaping the software lifecycle – into Agentic Development Lifecycle (ADLC) –  and security models that must evolve to support it. 

What Defined This Turning Point in RSAC 2026 

To understand why RSAC 2026 felt so unique, it helps to take a closer look at the themes that consistently emerged across the event. 

From Assistive AI → Autonomous (Agentic) Security 

The biggest shift: Agents have grown to be more than ‘assistants’. Security is no longer just assisted by AI – AI agents increasingly execute it. 

Agents are moving from copilots to decision-makers who can investigate, triage, and act. The industry is transitioning from human-paced workflows to machine-speed security operations. 

“Security for AI” and “Security by AI” Converge 

A major theme across sessions: 

Organizations must secure AI systems (LLMs, agents, MCPs), while simultaneously using AI to secure software and pipelines. 

AppSec is now responsible for both sides of the equation: 

• Protecting AI-generated code and AI components  

• Using agents to secure the SDLC, and increasingly, the ADLC 

The Rise of the Agentic Development Lifecycle (ADLC) 

AI is reshaping how software is written, reviewed, and deployed. Security must adapt to a lifecycle where agents generate, modify, and ship code. 

AppSec implication: 

• Security shifts from left → everywhere  

• From reactive → embedded into autonomous workflows  

Explosion of AI Supply Chain Risk 

RSAC highlighted growing concern around the security risks introduced by new supply chain components and dependencies, such as LLMs, agents, MCP servers, plugins, and AI SDKs. 

There is a clear need for visibility (AI-BOM), provenance, and trust in AI components. 

AppSec implication: 

• SBOM is evolving into AI-BOM  

• You now secure not just code dependencies, but AI dependencies  

AI-Native Security Vendors vs. Legacy Players 

There’s a clear market shift: 

The rise of AI-native security companies is challenging traditional vendors. Winning platforms are being rebuilt from the ground up as AI-first, not AI-enhanced. 

AppSec implication: 

• Expect consolidation around platforms that embed agents deeply  

• Not bolt-on AI features  

Trust, Governance, and Identity Become Foundational 

As agents act autonomously, the question becomes: 

Who authorized the agent? What can it do? 

Identity and governance are now core security primitives, not add-ons. 

AppSec implication: 

Security must enforce: 

• Agent identity  

• Policy boundaries  

• Auditability of decisions  

Taken together, these themes highlight a clear gap: traditional AppSec approaches were not designed for an agentic development lifecycle. 

That gap — and how to close it — was a central focus of what we introduced, as it raised the question: how do you secure an ecosystem that is agent-driven as much, if not more, than human-driven?  

At RSAC 2026, we introduced our new capabilities designed to address exactly that. 

Securing the Agentic Development Lifecycle 

At RSA this year, Checkmarx unveiled a new set of innovations designed to secure the ADLC: 

Expansion of the Checkmarx Assist family of agents 

Building on Checkmarx Developer Assist, we introduced two new agents: Triage Assist and Remediation Assist, designed to secure the critical post-commit phase. These agents help teams quickly prioritize real risks and fix them efficiently within pull requests (PR), reducing noise and accelerating secure code delivery. 

Introducing Checkmarx AI Supply Chain Security 

As organizations increasingly build with AI components, an entirely new layer is introduced into the supply chain, requiring dedicated security to address its unique challenges and risks. 

Checkmarx AI Supply Chain Security provides full visibility and risk assessment across the AI stack. With a centralized inventory and AI-BOM covering MCP servers, LLMs, AI agents, SDKs, and more, teams can move fast with AI, without losing control over security. 

SAST AI and DAST for AI  

Checkmarx enhanced its two core security engines to support AI-powered SAST scanning across virtually any programming language, helping organizations future-proof their technology adoption. In parallel, we strengthened our DAST engine to deliver runtime protection aligned with the realities of AI-driven and “vibe coding” development. 

Risk Orchestration within ASPM 

Checkmarx also announced a new and enhanced risk management and visibility solution across applications, projects, and repositories to improve decision-making, reduce noise, and highlight critical vulnerabilities. 

Agent identity 

• Policy boundaries 

• Auditability of decisions 

the tooling landscape must evolve to keep pace with the speed of AI-driven development. The shift is no longer about “AI in AppSec,” but about AppSec itself becoming an entirely different paradigm – agentic, autonomous, and continuous by design. 

Closing Notes 

The idea that “AppSec is becoming agentic” goes beyond a shift in tooling — it reflects a fundamentally different way of working with and understanding application security. 

AppSec is changing its DNA. 

That is why, compared to 2025, this year’s event was overwhelmingly focused on AI and Agentic Application Security, with a clear emphasis on how 

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. 

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. 

“AI Is an Amplifier—Proactive AppSec Is Business Imperative”

History has a rhythm—moments when technology doesn’t just evolve, it leaps. The telegraph overtook the Pony Express. The internet rewrote the rules of knowledge. Today, AI is redefining how we work, innovate, and build the future. 

Recent research from the inaugural DORA State of AI-Assisted Software Development Report (Checkmarx is a proud sponsor) reveals that 90% of technologists now use AI at work, with most relying on it regularly and reporting measurable gains in productivity and code quality. These findings are echoed in a recent Forbes interview with our CEO, Sandeep Johri, where senior contributor Tony Bradley spotlighted how seamlessly embedded AI agents are now working alongside developers instead of chasing vulnerabilities after the fact. 
 
Together, the DORA report and the Forbes feature paint a clear picture: AI is now pervasive in competitive organizations, reshaping not just development and operations, but also decision-making and security practices across the business landscape. 

This is good for productivity and organizational velocity, but it comes with new risks. As AI-generated code becomes more common, so do vulnerabilities. Auto-generated code can be two to three times more susceptible to security flaws compared to traditionally written code—creating new openings for hackers and bad actors. 

Using Security to Speed up Development

Explore how modern AppSec practices, powered by intelligent automation and AI, can reduce friction in the development lifecycle, minimize change failures, and cut down resolution times.

Watch Now

With 99% of development teams using AI for code generation, company systems must be ready to manage AI-driven risk. This is the moment AppSec has become proactive. Security is no longer just a gate. It is a vigilant sentry, embedded, continuous, and developer-focused, guiding and protecting them as the software landscape transforms. 
 
That is exactly why we built Checkmarx One: a unified, cloud‑native AppSec platform that correlates risk across SAST, SCA, IaC, API, containers, and more – so teams go from found to fixed faster, with prioritized, actionable remediation. We flag and fix vulnerabilities at the best time: before they happen, directly in the Integrated Development Environment. And with AI Query Builders and AI‑Guided Remediation, we put secure‑by‑design into the IDE, letting developers generate custom security scans and fix issues instantly with smart, contextual guidance. 

DORA’s message is clear, and Sandeep’s observations reinforce it: organizations must invest in the systems, platforms, data, and practices that not only amplify AI’s benefits but also safeguard against its risks. Proactive AppSec is central to that shift, and we are committed to helping every developer driving innovation move at AI speed, safely and efficiently.  

2025 DORA State of AI-assisted Software Development Report

Download the report to benchmark your organization’s AI strategy, understand your team’s profile, and identify the key capabilities needed for growth.

Read the DORA Report

That’s why we are thrilled to announce a strategic partnership between DevGrid and Checkmarx, aimed at bringing security to the forefront of engineering operations.

This partnership is grounded in a shared belief: security should be a seamless part of the software development lifecycle, not an afterthought. Our collaboration brings together Checkmarx’s best-in-class SAST and SCA capabilities with DevGrid‘s intelligent orchestration and observability across engineering systems.

What the Integration Enables

With this integration, the security scanning lifecycle and remediation become core components of EngOps. Here’s what you can expect:

• Checkmarx scans your code, integrated directly into build and CI/CD pipelines.
• Vulnerabilities are contextually linked in DevGrid to the exact project, service, and repository where they were found.
• Severity & SLA-based prioritization to focus on the issues that matter most, when they matter, no more waiting for a spreadsheet from the infosec team.
• Real-time visibility at the developer, team, and portfolio levels for Engineering Teams.

Bridging the Gap Between Development and Security

One of the biggest challenges organizations face today is the disconnect between development and security teams. Security often happens in isolation, producing results that are difficult for engineers to act on due to lack of context.

The DevGrid + Checkmarx integration solves this by providing shared context, aggregation, and collaborative reporting:

• Security findings are surfaced right where engineers manage their work.
• Developers have a single place to find issues, even if there are multiple tools.
• Security and Engineering leadership can report against the existing portfolios and teams without have to reconstruct that context in security tools.
• SLA adherence and avg time to remediate can both be metrics that go into the Engineering Maturity Journey scoring DevGrid provides.
  
  

Supporting Engineering, Platform, and Security Teams

This integration isn’t just for developers:

• Executives and stakeholders can track security performance and trends across portfolios
• Platform teams can enforce scan coverage and remediation SLAs
• Security teams gain centralized visibility and control without disrupting workflows

Organizational Impact

This integration is more than a technical improvement—it represents a cultural shift. By empowering developers to own security from day one, organizations can:

• Reduce time-to-remediation by up to 70%
• Eliminate handoff delays between security and engineering
• Boost delivery confidence by ensuring code is production-ready and secure

Getting Started

The Checkmarx integration is available to all DevGrid customers starting today. Setup is simple:

1. Navigate to the Integrations tab in your DevGrid workspace.
2. Select Checkmarx and provide your API credentials.
3. Choose which projects and services to connect.

Once configured, your next scan results will begin flowing directly into the DevGrid ecosystem.

Looking Ahead

Security is no longer an afterthought—it’s an essential component of the modern software delivery lifecycle. This partnership represents our shared vision to make secure engineering the default, not the exception.

Stay tuned for more enhancements.

Together, DevGrid and Checkmarx are redefining what secure software delivery looks like.

AI-powered coding tools like GitHub Copilot and Cursor are transforming software development, enabling developers to generate code at unprecedented speeds. But they’re also generating code with exactly those vulnerability rates, and whether you like it or not, they’re part of your team.

Recent research underscores significant security risks in AI-generated code. The most recent academic research, Georgetown University Center for Security and Emerging Technology (CSET) report (November 2024), found that 48% of AI-generated code snippets from five major large language models contained vulnerabilities flagged by the ESBMC verification tool, highlighting the potential for malicious exploitation.

Similarly, IBM’s 2025 Cost of a Data Breach Report found that 97% of organizations reported an AI-related security incident.

Checkmarx’s own Future of AppSec in the Age of AI report corroborates these findings, with a direct correlation between AI-generated code, and a rise in almost all risk-related metrics:

• 34% of organizations report that over 60% of their codebase is AI-generated, increasing exposure to vulnerabilities.
• 81% knowingly ship vulnerable code to meet deadlines.
• Only 18% enforce governance policies for AI tool usage.
• 20% detect unapproved AI tool use, constituting true Shadow AI.
• 98% experienced at least one security breach in the past year.

Even before AI entered the picture, security was already struggling to keep pace with accelerating development cycles. Now, with the volume and velocity of AI-generated code, today’s AppSec structures aren’t just lagging. They’re fundamentally unprepared.

With unvetted AI-generated code flooding production environments, dev leaders face a critical choice: continue the perilous trade-off between velocity and security, or take decisive action.

The AI Trifecta: The Three Forces Derailing Security in AI-Generated Development

As Heads of Development face mounting pressure to ship faster using AI-generated code, they’re also expected to maintain security, stability, and compliance. But three structural challenges are quietly undermining their ability to do both.

These challenges—velocity without security alignment, lack of AI governance, and under-integrated AppSec tooling—form what we call the AI Trifecta: a convergence of forces that puts organizations on a collision course with risk. Addressing just one isn’t enough. To create a sustainable balance between speed and security, all three must be tackled in parallel.

Speed-First Culture Breeds Structural Risk

The vulnerability rates in AI-generated code would be concerning enough on their own. But as Checkmarx’s report finds, they’re combined with an increasingly alarming reality: organizations aren’t just accidentally shipping vulnerable code—they’re doing it knowingly, systematically, and at accelerating rates.

As mentioned above, 81% of organizations knowingly ship vulnerable code. Not because they want to, but because external pressures make it feel necessary, while developers’ optimism bias leads teams to underestimate the real risk:

• 38% of organizations deploy vulnerable code to meet feature deadlines.
• 33% of developers admit to hoping vulnerabilities “won’t be discovered”—a sharp rise from 15% in 2024.

This reveals a systemic underlying problem. KPIs that prioritize feature delivery over security, compressed review timelines, and unrestricted AI tool access all incentivize dangerous shortcuts. When AI can generate code faster than security teams can review it, the pressure to “ship now, fix later” becomes overwhelming—and eventually leads to “ship now, fix never, get breached eventually.”

The result is mounting security debt: increased breach exposure, operational drag from emergency patches, and eroded customer trust. IBM’s 2025 Report mentioned above puts the average breach cost at $4.4 million, with vulnerabilities in custom code being a significant contributor.

The AI Governance Crisis: Development Without Guardrails

Checkmarx’s report also reveals a staggering governance gap that should alarm every development leader:

• Only 18% of organizations have established approved AI tool lists
• 20% detect unapproved AI tool use—constituting true Shadow AI
• Only 18% enforce governance policies for AI tool usage
• 82% lack comprehensive oversight of AI development tools

IBM’s report paints a slightly optimistic, yet still concerning picture, where “only” 63% of organizations lacked AI governance policies to manage AI or prevent the proliferation of shadow AI.

This represents a fundamental breakdown in risk management. The majority of organizations have essentially handed over significant portions of their codebase to ungoverned AI systems, creating massive blind spots in security oversight.

AppSec Tools Lag Behind Developer Velocity

Despite years of talk around DevSecOps, the reality on the ground tells a different story: most security tooling still isn’t keeping pace with the way modern development teams work.

Key security practices—like Dynamic Application Security Testing (DAST), Infrastructure-as-Code (IaC) scanning, and container security—are adopted by fewer than 50% of organizations. And even when in use, they’re often bolted on after the fact, rather than embedded into the daily development workflow.

The result? Security becomes an external gate, not an integrated part of the build process. Tools that aren’t wired into IDEs, pull requests, or CI/CD pipelines are easily ignored or deprioritized under delivery pressure.

To secure AI-accelerated development, AppSec needs to live where the code lives—in the hands of developers, in real time, as part of the flow. Without that, every “shift-left” promise is just a theory.

Five High-Impact Actions for Heads of Development

To navigate the AI-Gen Trifecta, Heads of Development must drive strategic change, align cross-functional teams, and overcome organizational resistance.

The following five actions provide actionable, evidence-backed strategies to balance AI-driven productivity with robust security, tailored to the leadership challenges of managing teams, budgets, and stakeholders.

1.      Redefine Success Metrics to Counter Speed-First Culture

Shift KPIs to prioritize security alongside velocity, addressing the speed-first culture’s risks. Implement metrics like:

• Fix rate by vulnerability severity: Ensure 90% resolution of high-severity issues pre-release, using CVSS for code vulnerabilities.
• AI-specific risk scores (AIVSS): Adopt the OWASP AIVSS framework to quantify agentic AI risks (e.g., prompt injection, context poisoning), targeting a <10% rate of high-risk AI behaviors in production code.
• Mean Time to Remediate (MTTR): Aim for under 48 hours for critical vulnerabilities, per NIST guidelines (NIST, 2024).
• Releases with unresolved vulnerabilities: Target <5% to minimize risk exposure.

2.       Enforce AI Tool Governance to Close the Governance Gap

To close the governance gap, Heads of Development must collaborate with AppSec teams and CISOs to design policies that secure AI usage without disrupting developer workflows. Implement:

• Approved AI tool lists: Restrict usage to vetted platforms, ensuring integration with enterprise security policies (e.g., SSO, encryption). Conduct a 90-day audit to identify and phase out unapproved tools, reducing shadow AI risks.
• Prompt transparency and audit trails: log AI-generated code and prompts, incorporating OWASP AIVSS scores to assess behavioral risks (e.g., autonomy, tool misuse).
• Commit-time scanning: Deploy real-time vulnerability scanning in CI/CD pipelines to catch AI-specific issues like prompt injection, with AIVSS-guided prioritization.
  Collaboration Process:
• Form a Governance Task Force: Create a cross-functional team with AppSec, CISOs, developers, and legal to define policies and address both technical and behavioral AI risks.
• Align on DORA Metrics: Work with CISOs to balance security with velocity and eliminate friction using DORA metrics as a mutual guide.
• Invest in ongoing developer education around AI-assisted coding and emerging AppSec risks. Ensure your teams understand how AI-generated code can introduce new threat vectors, and provide training on secure usage practices, threat modeling, and mitigation techniques.
• Pilot and Iterate: Start with a pilot in a high-risk business unit, using AIVSS to score AI tool risks and refine policies. Scale after 90 days, incorporating developer feedback to minimize friction.

3.      Drive Adoption of Unified, Developer-Native AppSec Platforms

Heads of Development must champion the adoption of a unified AppSec platform that lives in developers’ IDEs, covers diverse risks (code, AI, infrastructure), and prioritizes alerts based on exploitability to avoid overwhelming teams:

1. Advocate for a Unified Platform: Push for unified platforms like that integrate SAST, SCA, DAST, and IaC scanning into IDEs and CI/CD pipelines. These platforms correlate findings across code, open-source libraries, APIs, and cloud environments, making it easier to bridge the gap between dev and application security.
2. Prioritize Exploitability-Based Alerts: Ensure the platform prioritizes high-impact vulnerabilities, based on contextualized exploitability.
3. Collaborate with AppSec and CISOs: Form a cross-functional council with AppSec, CISOs, and developers to select a platform that aligns with organizational needs.
4. Pilot and Scale: Start with a 60-day pilot in a high-velocity team, testing IDE-integrated tools and measuring DORA metrics improvements (e.g., 2x Deployment Frequency). Scale to other teams after validating developer adoption. Address developer resistance by involving them in tool selection, customizing alerts to their workflows.

4.       Champion Application Security Posture Management (ASPM) for Strategic Oversight

ASPM tools provide unified visibility across custom code, open-source libraries, APIs, cloud environments, and AI-driven systems, addressing all three AI-Gen Trifecta risks (speed, governance, tooling).

Heads of Development must champion ASPM adoption to reduce risk exposure, align security with business goals, and support developer velocity, leaving technical implementation to AppSec teams:

• Advocate for ASPM Adoption: Push for ASPM platforms that integrate with IDEs (e.g., VS Code) and CI/CD pipelines, correlating CVSS and AIVSS scores to prioritize exploitable vulnerabilities (e.g., AI agent autonomy, code-based SQL injection).
• Ensure Developer-Friendly Integration: Mandate that ASPM tools deliver real-time, actionable alerts within developer workflows, minimizing context switching and supporting DORA metrics like Lead Time for Changes.
• Lead Cross-Functional Alignment: Form a governance council with AppSec, CISOs, developers, and business leaders to define ASPM requirements, ensuring alignment with NIST AI RMF and organizational priorities.
• Pilot and Scale Strategically: Launch a 90-day ASPM pilot in a critical business unit, measuring reductions in breach risk and DORA metric improvements (e.g., 40% lower Change Failure Rate). Scale enterprise-wide after validating ROI.

5.      Leverage Agentic AI for Scalable Security

According to a recent IDC report,in response to the risks of Ai-gen code there is a growing shift toward Appsec use of agentic: autonomous, role-specific agents that operate within the tools developers and AppSec teams already use.

These agents are designed not to scan after the fact, but to prevent vulnerabilities in real time—from code creation to policy enforcement to executive visibility.

Agentic AI security tools dedicated to being integrated into the developer’s workflow, like Checkmarx One Developer Assist, automated real-time detection, remediation, and policy enforcement at commit time.

Agentic AI helps your developers maintain velocity while mitigating the associated risk of AI-generated code, by:

1. Embedding Real-Time Vulnerability Detection in IDEs: The Developer Assist Agent integrates into IDEs to scan AI-generated code as it’s written, identifying vulnerabilities like SQL injection or prompt injection within seconds without disrupting developer workflows.
2. Providing Guided Remediation with Actionable Code Fixes: The agent uses generative AI to suggest tailored code snippets for fixing vulnerabilities directly in the IDE, with confidence scores (0–100) indicating exploitability.
3. Enabling Efficient, Customized Security Queries: AI Query Builders allows developers to create tailored security queries using natural language, scanning AI-generated code and open-source libraries for malicious packages and vulnerabilities.
4. Enhancing Governance with Real-Time Code Validation: Agentic AI can ensure compliance with secure coding policies, thereby mitigating the governance gap and shadow AI risks, helping alignment with NIST AI RMF.

Speed Without Safety Is Unsustainable

Every data point in this report points to the same inflection point: AI-generated development isn’t just outpacing security. It’s running circles around it.

 Heads of Development are no longer just responsible for delivering fast—they’re also responsible for delivering safely at scale. That means rethinking how and where security fits into their developers’ workflow.

AI velocity comes attached with a bill. And it’s up to development leaders to ensure that the bill isn’t paid with breaches and erosion of trust.

In an industry long accustomed to rapid change, 2025 may be remembered as the year the ground truly shifted.  

According to The Future of Application Security Report, a global research study conducted by Censuswide on behalf of Checkmarx and published today, application development has entered a new phase—one in which AI now writes much, if not most, of the code. Yet security practices remain anchored in outdated assumptions, allowing unchecked AI-generated code to reach production at an unprecedented pace. 

Download the report.

A Moment of Reckoning: What the Data Tells Us 

The report, based on insights from more than 1,500 security leaders, AppSec managers, and developers across nine countries, reveals a landscape defined not by lack of awareness, but by mounting structural and cultural lag: 

• AI-generated code is becoming standard practice. 
  One in three respondents say over 60% of their organization’s code is now written by AI. Yet only 18% have formal policies or governance in place to manage this shift. 

• Vulnerabilities are knowingly shipped. 
  A full 81% of respondents report their organizations deploy code with known security flaws: Sometimes by necessity, often by design. 

• Security tooling remains underutilized. 
  Less than half of organizations are actively using foundational tools such as DAST, IaC scanning, or container security. 

• Breach frequency continues to climb. 
  98% of organizations experienced at least one breach related to vulnerable in-house code in the past 12 months, a concerning continuation of an upward trend. 
  
  

An Industry Caught Between Two Ages 

This is not a call to panic, but rather a call to pause and reflect. For decades, the security community has advocated for secure-by-design principles, tighter developer collaboration, and earlier intervention in the SDLC.  

Yet the accelerating adoption of AI, coupled with relentless business pressure, has exposed fault lines in even the most well-intentioned security programs. 

The Checkmarx report finds that many organizations now treat security debt as a tolerable cost of business, relying on patch-later practices that assume, implicitly or otherwise, that exploitable vulnerabilities won’t be discovered or acted upon in the interim. 

Meanwhile, developers – many of whom are now responsible for remediation – are navigating new complexities, including shadow AI usage, insufficient guardrails, and growing expectations without sufficient guidance, education or support. 

Rebalancing the Equation: Where We Go From Here 

The Future of Application Security Report does not simply chronicle a shift; it offers a framework for addressing it. Among its key recommendations: 

• Govern AI proactively. Establish clear usage policies, approved toolsets, and code provenance controls before usage becomes unmanageable. 

• Operationalize your tooling. Ensure AppSec tools are not only purchased but embedded directly in developer environments, pipelines, and workflows. 

• Move from awareness to action. Translate high-level security posture into specific, enforceable controls and developer-level feedback. 

• Adopt code-to-cloud strategies. Visibility and protection must extend from first commit to live deployment and beyond. 

• Support developers with clarity. Invest in real-time remediation support, incentivized secure coding, and aligned metrics that recognize both speed and safety. 

• Adopt agentic AI in AppSec. As AI-generated code scales beyond human oversight, organizations must begin adopting agentic AI: autonomous security agents capable of analyzing, enforcing, and remediating risk in real time. The only viable response to AI-scale development may be AI-powered defense. 

The Path Forward 

The picture painted in this report is neither pessimistic, nor complacent. Rather, it is a candid assessment of an industry in transition.  
 
AI is not merely influencing the development process. It is redefining it. And while the pace of change is formidable, the principles that underpin sound security – visibility, accountability, shared responsibility – remain more relevant than ever. 

If there’s a central takeaway from this year’s findings, it’s this: turning a blind eye to insecure practices is no longer a viable strategy.  

In an industry where 81% of organizations knowingly ship vulnerable code, AI now writes the majority of application code, and 98% report breaches, the trajectory is unsustainable. 

 Without a deliberate course-correction in governance, cultural change, and the operationalization of modern AppSec practices, development velocity will continue to outpace security’s ability to protect it. The collision point is not theoretical. It’s imminent. 

But so can be the prospect of a new equilibrium: one where security is embedded, AI is governed, and development teams are empowered to deliver safely at speed. The opportunity is clear. What remains is execution. 

For a comprehensive view of the findings and their implications, download the full report.

The Future of AppSec in the Era of AI: 2026 Industry outlook

Read the Report

What Is LLM Poisoning? 

LLM poisoning is an emerging cybersecurity threat in which adversaries intentionally introduce malicious or misleading data into the training datasets of large language models. This can also include exploiting weaknesses in model fine-tuning or prompt-handling mechanisms to manipulate outputs. The consequences of such manipulation are severe: poisoned LLMs can generate insecure code, embed hidden backdoors, or include malicious logic in otherwise seemingly legitimate code suggestions. 

The danger is particularly acute in AI-powered development environments where developers rely on LLMs to generate boilerplate code or solve complex algorithmic challenges. A single poisoned suggestion that goes unnoticed can propagate vulnerabilities across multiple systems, leading to compromised software and security breaches. 

The Implications for Software Security 

The infiltration of malicious logic via LLM poisoning is not just a technical nuisance. It introduces far-reaching implications for application security, regulatory compliance, and brand reputation. Organizations that unwittingly deploy software containing code generated by compromised LLMs face the possibility of: 

• Systemic vulnerabilities that can be exploited at scale. 

• Intellectual property theft or data leakage is a huge problem. 

• Violations of regulatory requirements such as GDPR, HIPAA, and PCI DSS. 

• Loss of customer trust due to security incidents. 

Traditional AppSec approaches, which rely heavily on post-development scanning or manual code reviews, are not equipped to handle this type of attack. These methods detect vulnerabilities too late in the development process, often after the damage has already been done. 

How does Checkmarx One Assist – Agentic AI AppSec Platform Help? 

Checkmarx addresses this critical gap with our innovative Agentic AI Application Security (AppSec) Platform, a next-generation security solution purpose-built to safeguard modern, AI-assisted software development. 

The Agentic AI platform integrates seamlessly into the entire software development lifecycle (SDLC), from initial coding in the IDE (VSCode, Cursor, Windsurft, etc.) to final deployment. It continuously scans and monitors code, offering proactive identification and remediation of vulnerabilities in real time. This includes identifying code anomalies, dependencies on malicious packages, secrets, and potentially poisoned suggestions that stem from compromised LLM interactions. 

With the rise of these OWASP also created and continuously maintains the Top 10 LLM https://owasp.org/www-project-top-10-for-large-language-model-applications/  

Among the threats that are being covered in the OWASP LLM Top 10 (LLM 01-LLM 10) nowadays are: 

1. Prompt Injections 

Malicious users manipulate inputs to override or alter the LLM’s intended behavior, leading to unexpected or unsafe outputs. 

2. Sensitive Information Disclosure 

The model unintentionally reveals confidential data, such as credentials, internal logic, or personal information. 

3. Supply Chain LLM Risks 

Using outdated, unvetted, or deprecated models can introduce vulnerabilities inherited from third-party sources. 

4. Data and Model Poisoning 

Attackers corrupt training data or fine-tuning inputs to insert backdoors, bias outputs, or degrade security. 

5. Improper Output Handling 

Failure to validate or sanitize LLM responses can lead to unsafe actions, injection attacks, or misinformation propagation. 

6. Excessive Agency 

LLMs with too much autonomy or access (e.g., to file systems or APIs) can take actions beyond their intended scope, introducing serious risks. 

7. System Prompt Leakage 

System-level instructions meant to govern the LLM’s behavior become visible to users, enabling manipulation or bypassing safeguards. 

8. Vector and Embedding Weaknesses 

Flaws on how inputs are converted to embeddings (for similarity search or retrieval) can be exploited for poisoning or inference attacks. 

9. Misinformation 

LLMs may confidently generate false or misleading information, which can be especially damaging in regulated or high-stakes domains. 

10. Unbounded Consumption 

LLMs can overuse system resources (e.g., compute, memory, API calls), leading to denial of service or cost overruns when limits are not enforced. 

For this reason, The OWASP AIVSS project created a framework to quantify these new risks, called AIVSS. It’s not a replacement for CVSS, but a critical extension that allows security teams to measure the full risk profile of Agentic AI systems.  

You can read more about AIVSS in this article by OWASP member, Ken Huang.

Real-Time Defense at the Code Level 

A standout capability of the Checkmarx Agentic AI platform is its ability to flag and fix security vulnerabilities as code is written, which is a critical feature when dealing with the rapid outputs of LLMs. Developers using AI-enhanced IDEs like Cursor or CoPilot, can benefit from instant feedback and remediation suggestions that are context-aware and security-focused. 

This real-time defense mechanism drastically reduces the window of exposure. Rather than relying on security audits or penetration tests at the tail end of development, Agentic AI embeds security controls at the source—where LLM-generated code is created and integrated. 

Each time a security threat is remediated, the Checkmarx Developer Assist agent automatically refactors the affected code to ensure it remains functional and compiles cleanly – seamlessly preserving the integrity of the CI/CD pipeline. 

Behavior-Driven Threat Detection 

Beyond traditional static and dynamic analysis across the Checkmarx One AppSec engines (SCA, Malicious Packages, Secrets, Containers, and more), Checkmarx’s Agentic AI leverages behavior-driven AI models that monitor usage patterns and execution behaviors to detect anomalies indicative of poisoning attempts. These capabilities include: 

• Anomaly detection in code patterns that deviate from normal development behavior. 

• Exploitability assessments to determine how vulnerable a particular code segment is in a runtime context. 

• Reachability analysis to identify if an introduced vulnerability is exploitable. 

This allows the platform to not only identify known threats but also anticipate and mitigate novel attack vectors that exploit the very nature of generative AI systems. 

Empowering Developers Without Slowing Them Down 

A key advantage of Agentic AI is its developer-first design. Security is often seen as a blocker to innovation, but Checkmarx aims to make it a silent enabler. By integrating with IDEs and CI/CD pipelines, the platform ensures that security checks and fixes occur naturally within the developers workflow. There is no need for disruptive context switching or cumbersome security gates that slow delivery. 

Instead, developers are empowered with: 

• Inline code suggestions that are secure by design. 

• Alerts for suspicious behavior in third-party packages or dependencies. 

• Automated remediation options for discovered issues. 

This reduces the burden on AppSec teams while giving developers the confidence to move fast without compromising security. 

Future-Proofing Software in the Age of AI 

As AI continues to advance and LLMs become more deeply integrated into everyday development workflows, the risks of LLM poisoning and other AI-based threats will only increase. The future of secure software hinges on our ability to not only detect but also prevent such risks at machine speed. 

Checkmarx One Assist Agentic AI AppSec platform offers enterprises the tools they need to stay ahead of the curve. By combining deep security expertise with innovative AI capabilities, it provides comprehensive coverage across the evolving threat landscape. 

As teams adopt cloud-native architectures, microservices, rely more on vibe-coding and AI generated code techniques, Agentic AI supports the process by helping review and secure both human and machine-generated code. 

Conclusion 

The rise of LLMs has unlocked tremendous potential for innovation in software development. But with this power comes new vulnerabilities that traditional security approaches cannot address alone. LLM poisoning is a prime example of how attackers are evolving alongside the tools developers use. 

To stay protected, organizations must embrace a new breed of security platforms, ones that are proactive, intelligent, and seamlessly integrated into the developer experience.  

In F1, performance isn’t just about the engine – it’s about control. Brakes, while intuitively associated with slowing down, are actually critical to going faster. They’re what let drivers push harder, with confidence. When braking is misaligned, even the fastest driver loses time. 

It’s the same with software delivery. AppSec might not be the first thing you think of when optimizing DORA metrics – but it’s part of the machine. If it’s fragmented and out of tune, it creates drag. But if your AppSec is integrated and aligned with the flow, it unlocks performance. 

The DORA metrics, developed by Google’s DevOps Research and Assessment team, are widely recognized as benchmarks of software delivery performance: Deployment Frequency, Lead Time for Changes, Change Failure Rate, and Mean Time to Recovery (MTTR). 

Here lies a real opportunity to shift the dial on these metrics, by spotting where AppSec adds friction and tuning it out of the system. 

So, let’s grab the monkey wrench and get back under the chassis. 

Tuning AppSec to Improve Your DORA Metrics 

Let’s take a closer look at each DORA metric separately to see where AppSec tends to create friction and how we can align it better and turn it into forward motion. 

Deployment Frequency 

What it measures 

How often code changes are deployed to production. Higher frequency typically reflects a more agile and responsive engineering process. 

How AppSec impacts Deployment Frequency 

AppSec influences deployment frequency in multiple ways, some seem obvious, others more subtle: Manual reviews and siloed security teams often delay merges and releases, especially when issues are discovered late in the cycle. This creates bottlenecks that throttle throughput. 

In contrast, when AppSec is integrated early and tightly into the developer workflow, it eliminates delays before they form. Automated scans in the IDE, SCM, and CI/CD pipeline catch issues before they snowball. Real-time feedback and clear remediation guidance reduce context-switching, enabling developers to stay in flow and deliver faster. 

Even psychologically, embedded AppSec builds trust: developers and platform teams feel more confident deploying frequently when they know risk is being managed continuously—not inspected as an afterthought. 

Actionable steps to improve Deployment frequency through AppSec 

• Shift security, not just left, but everywhere. Bring AppSec earlier into the development lifecycle—closer to where code is written, not just reviewed—so issues are caught before they become blockers. Early detection prevents slowdowns and rework. But don’t stop there. Extend security coverage across the SDLC with tools for SAST, SCA, IaC, and container scanning to ensure issues are caught and resolved wherever they arise. 

• Integrate into developer tools. Embedding security directly into IDEs, source control systems, and CI/CD pipelines enables seamless developer workflows. It minimizes context switching and removes the need for separate review steps. 

• Automate wherever possible. Automating scans, policy enforcement, and remediation ensure consistency and reduces bottlenecks. The less manual intervention required, the faster teams can ship. 

• Provide contextual feedback. Fast, actionable security guidance helps developers fix problems without breaking flow. Vague or delayed feedback leads to friction and slows delivery. 

• Build trust in the pipeline. When developers know the system supports fast, secure iteration, they deploy more confidently and more often. 
  

By how much can you improve Deployment Frequency?  

With well-integrated AppSec practices, deployment frequency can increase by up to 2× without sacrificing safety or control.  

Lead Time for Changes 

What it measures 

The time it takes for a code change to make it into production. A shorter lead time reflects a more efficient and responsive development process. 

How AppSec impacts Lead Time for Changes 

AppSec often introduces delays when vulnerabilities are discovered late in the pipeline, after code has already been written, tested, or even staged for deployment. At that point, remediating issues means context-switching, rework, and coordination across teams. 

Conversely, when AppSec is embedded early and seamlessly, it accelerates this metric. Inline scanning, real-time feedback, and IDE-level insights allow developers to fix vulnerabilities in the moment, while the code is still fresh in their mind. Early detection also reduces the likelihood of rework or escalations later in the process. 

Actionable steps to improve Lead Time for Changes through AppSec 

• Embed security feedback early. The earlier vulnerabilities are caught, the cheaper and faster they are to fix. 

• Integrate with the developer’s daily tools. Scanning should happen where code is written—not as a separate process. 

• Provide precise remediation guidance. Developers need more than alerts. They need clear and actionable suggestions to act fast and efficiently. 

• Automate triage and prioritization. Sorting signal from noise ensures attention goes to what matters most, reducing delay. 

• Treat AppSec as part of velocity. When developers view security as a support system, not a blocker, they’ll move faster with more confidence. 
  
  
  
  

By how much can you improve Lead Time for Changes? 

Integrating AppSec into the early stages of development can reduce lead time for changes by up to 50%. By eliminating late-stage surprises, minimizing rework, and enabling faster, in-flow fixes.  

Change Failure Rate

What it measures 

The percentage of deployments that result in a failure in production—typically requiring hotfixes, rollbacks, or emergency patches. Lower is better. 

How AppSec impacts Change Failure Rate 

When security issues make it to production, they often trigger emergency fixes that disrupt workflows and shake confidence. This tends to happen when vulnerabilities are missed during code review, testing, or integration. 

AppSec that’s embedded throughout the SDLC prevents this. With guardrails like pre-merge checks, IaC scanning, and container security policies, risky code is flagged before it’s deployed. This dramatically reduces the chances of introducing vulnerabilities into production. 

Actionable steps to improve Change Failure Rate through AppSec 

• Establish clear security gates. Block merges or builds that fail security checks instead of discovering issues post-deployment. 

• Scan beyond the code. Analyze infrastructure, containers, and third-party dependencies, not just application logic. 

• Define policy as code. Codify your security standards so they can be enforced consistently across all pipelines. 

• Prioritize critical risks. Focus on vulnerabilities that are actually exploitable in your environment, not just everything the scanner finds. This helps you direct attention and resources toward issues that genuinely affect Change Failure Rate, while also minimizing disruption to Lead Time for Changes and MTTR. 

• Normalize pre-prod security checks. Make security testing routine and automated before every deployment. 
  
  

By how much can you reduce Change Failure Rate? 

Teams that consistently enforce automated security checks and pre-merge policies can see up to a 40% reduction in change failure rate, with clear guardrails and pre-merge checks that reduce production failures by catching issues before they ship. 

Mean Time to Recovery (MTTR) 

What it measures 

How long it takes to restore normal service after a failure or incident—especially security-related. Lower MTTR means faster, more resilient teams. 

How AppSec impacts MTTR 

Fast recovery requires both agility and clarity. When a security vulnerability leads to an outage or regression, teams need actionable context to resolve it quickly. Without it, root cause analysis drags on, and the recovery clock keeps ticking. 

AppSec practices that prioritize visibility, context, and integrated remediation tooling make all the difference. When vulnerabilities are surfaced with their severity, location, and potential exploitability, developers can respond decisively. 

Actionable steps to improve MTTR through AppSec 

• Surface the right context. When incidents occur, teams need more than just an alert: They need details like fix location, attack vector, and exploitability to understand root cause quickly and respond decisively. 

• Unify security findings. During a security-related outage, context switching across multiple tools wastes time. A unified view across code, containers, open-source, and IaC shortens the path to resolution. 

• Automate remediation support. Delivering fix suggestions and best fix locations directly in the developer’s workflow enables faster recovery with less friction. 

• Correlate by business impact. Prioritizing vulnerabilities that pose the highest operational or reputational risk ensures teams focus on what matters most during recovery. 

• Integrate alerts into incident workflows. Ensure that security alerts flow into the same systems that teams already use to triage and resolve incidents. 

• Unify security findings. Consolidate insights from code, containers, open-source, and IaC into a single view. 

• Automate remediation support. Offer fix suggestions directly in the developer’s environment. 
  
  

By how much can you improve MTTR? 

With strong AppSec observability and remediation tooling, teams can reduce MTTR by up to 60%, minimizing the blast radius of security-related failures. Speed of recovery depends on clarity. When vulnerabilities are surfaced with context – severity, exploitability, fix location – teams can respond faster and smarter. 

From Insight to Action: How Checkmarx One Improves DORA Metrics 

AppSec doesn’t just shape DORA metrics in theory. It helps drive measurable improvements when implemented well. This is where Checkmarx One comes in. 

Checkmarx One offers a unified AppSec platform built for how modern Dev and AppSec teams work: It’s embedded in the developer environment, automated in the pipeline, and scalable across the SDLC. It’s not just about finding vulnerabilities; it’s about removing friction, guiding developers to fast, effective fixes, and giving AppSec leaders real confidence in their coverage. 

Throughout this article, we’ve outlined how AppSec influences each DORA metric. Below is a summary of how Checkmarx delivers specific value across all four metrics—along with the measurable performance lift you can expect to see when you apply these practices at scale. 

Here’s how Checkmarx supports each DORA metric: 

Final Thoughts 

As this article has explored, application security plays a bigger role in improving DORA metrics than many development and engineering leaders realize: When AppSec is tightly aligned with development workflows and DevOps practices, it becomes a performance multiplier: reducing rework, improving reliability, and accelerating recovery. 

For organizations looking to scale software delivery without compromising on security, the opportunity is clear: treat AppSec not as a checkpoint, but as a strategic enabler. 

Holistic AppSec solutions like Checkmarx One help put that mindset into action, embedding security into the flow and turning AppSec into a measurable driver of engineering performance. 

Learn more about Checkmarx One here.