Before you can fix anything, you need answers: Is this code actually reachable? Can an attacker exploit it? Is it exposed to a real application path? Are there controls already in place? Is this worth interrupting sprint work right now?

Most alerts don’t answer any of those questions. They tell you a vulnerability exists – not if it matters. That’s largely a scanning problem: one practitioner calls static scanning an “alert factory that nobody uses.” When 80–90% of findings are irrelevant, the result is a cycle no team wants. AppSec has to justify urgency, developers must reconstruct missing context, and everyone loses time that could have gone toward fixing the issues that matter.

The bigger problem is not that security findings exist. It is that many findings arrive without the evidence developers need to make a confident engineering decision. Traditional scanners can identify patterns that may be risky, but they rarely answer the questions that determine whether a fix should interrupt current work.

A function may be reachable but protected by authentication, input validation, network controls, or other safeguards. Another issue may look less severe on paper but become urgent because it sits in a public-facing workflow or touches sensitive data. A low-severity finding in a public-facing workflow can be far more dangerous than a critical bug buried in an internal module.

Without context, reachability alone is not enough. Modern risk is compositional, shaped by deployment, exposure, identity, and data, not by code patterns.

Without that context, the work falls to whoever picked up the ticket. Someone must trace the path, check exposure, review controls, assess impact, and determine whether the issue is exploitable in this application, not just theoretically possible in code.

Smarter Triage: Context-Driven, Data-Driven Decisions 

A better triage process should answer the obvious engineering questions before a finding reaches the backlog. Instead of asking developers to investigate every possible issue from scratch, modern triage tools use AI and execution context to validate which findings are actually exploitable in the application.

In practice, a smart triage layer correlates scan results with runtime data, permissions, architecture, and policies. The output is not just another severity label. It’s evidence: the relevant path through the code, the attacker-controlled input, the potential impact, and whether existing controls prevent exploitation.

Checkmarx’s Attackability analysis is designed to provide evidence by tracing attacker-controlled inputs from real ingress points through the code to potential impact, then verifying which security controls are in place. The result is a verdict of demonstrated exploitability or not, with code-level evidence attached.

That shifts the conversation from “maybe it’s exploitable” to a clear yes or no question. By validating findings with facts, teams stop arguing in the abstract. The report shows precisely how an issue is or isn’t reachable and exploitable, so you can align with security on facts, not time-consuming assumptions. With Attackability data, AppSec can confidently say “this vulnerability is exploitable under these conditions, and here’s the proof” (or alternatively, “we can mark this issue low risk, because x, y, z controls make exploitation infeasible”).

Analysts put it plainly that “a finding without context is a tax,” because it forces a human to ask the only question that matters: “Is this exploitable here and now? If not, why bother fix it at this point?” Front-loading that context and verification means only high-fidelity, relevant alerts reach the backlog.

Automated Remediation: Turning Decisions Into Fixes

Triage helps teams agree on what matters. But you still need a practical path from validated risk to working code. Too often, even agreed-upon issues stall in handoffs or ticket threads. The fix is to automate “closing of the loop.”

Enter remediation assistants that live in your developer workflow. These tools generate context-aware, merge-ready fixes for validated findings, usually as pull requests. For example, Checkmarx’s Remediation Assist uses safe-refactoring principles to produce minimally invasive patches right where you already work. You can review the diff, run tests, inspect the logic, adjust the code if needed, and merge when it meets your standards.

When remediation shows up as a pull request, you do not have to stop what you are doing to interpret a vague ticket, chase down context, or debate whether the finding is worth fixing. You can review the diff like any other code change, run your tests, adjust the code if needed, and merge when it meets your standards.

Decisions become code almost instantly without any lag.

That matters because the old model of manually reviewing, debating, assigning, fixing, and rechecking vulnerabilities isn’t keeping up with the speed of exploitation. A 2026 Qualys Threat Research analysis of more than one billion CISA KEV remediation records across 10,000 organizations found that manual remediation processes failed to keep pace with attackers 88% of the time across the most critical actively weaponized vulnerabilities studied. Organizations that performed better had operationalized remediation pipelines, giving their teams a faster way to move from validated risk to completed fix.

The cost in developer time is just as significant. Checkmarx’s DevSecOps Evolution 2025 research found that 72% of devs spend more than 17 hours each week on security-related tasks, and one in four spends more than 25 hours. Automated triage and remediation reduces that burden by turning validated security decisions into reviewable code changes, so teams stay focused on building while still moving real risk to resolution.

Results: Fewer Arguments, Faster Fixes

The outcome of this triage-and-remediation workflow is clear: fewer debates and far more fixes. With objective analysis in hand, security and engineering reach consensus faster. With remediation automation in place, vulnerabilities are closed before they linger.

Teams that add automated remediation report mean-time-to-remediate shrinking from weeks to hours. Instead of arguing over false positives, teams ask “how do we fix this fastest?” Workflow-integrated triage eliminates the guesswork in risk evaluation and, paired with agentic remediation, it ensures that decision leads to a patch. The result is fewer vague tickets, clearer priorities, and more vulnerabilities resolved instead of debated.

The same story keeps coming up. Teams are being asked by customers, auditors, legal, and leadership to document how they used AI in their products. What models are running? Where did they come from? Who approved them? What risks have been assessed? What licenses apply? The uncomfortable truth is that nobody knows, and they have no idea how to produce that documentation. This isn’t a program failure – the tools these teams rely on simply weren’t built to provide that kind of audit trail.

There’s also uncertainty about scope. What even counts as an AI component and how do you decide which need to be tracked? Only LLMs? What about MCP servers, agents, prompts, or datasets? There are no clear guidelines, and that ambiguity make this problem harder to resolve.

Why the SBOM Is Not Enough

When I tell AppSec teams that AI components need to be documented for compliance, their first instinct is almost always the same: point to the SBOM. It’s the supply chain inventory artifact most teams have already invested in, it feeds compliance workflows, and it’s supposed to tell you what’ is in your software. It’s a capability we include in Checkmarx’s supply chain security solution for exactly that reason.

But that’s the problem. The SBOM was built for a world of packages declared in manifests, versioned discretely, with vulnerability histories tracked in maintained databases. That model holds up well for open-source libraries, but it doesn’t hold up for AI components.

Here’s why: an LLM integration doesn’t declare itself in a requirements.txt or package.json. It shows up in source code as an API call, with a provider name and model identifier buried in a configuration string. The SBOM captures the SDK; it says nothing about which model is behind it, whether that model is version-pinned, where it originated, or what risks it carries. An agent framework appears in the dependency graph as a single package entry, the framework version, nothing more. What tools the agent can invoke, how broadly it can act, and whether anyone with security responsibility has reviewed that scope are nowhere in the manifest. An MCP server, and these are now common in production codebases, may exist entirely in a runtime configuration file that no scanner currently treats as a security artifact.

Then there is the risk taxonomy problem. CVEs cover code-level vulnerabilities in versioned packages, but the risks that matter most for AI components don’t fit neatly into that model. Model weights tampered with during training, datasets poisoned at the source, floating version references that silently change application behavior when a provider pushes an update, licensing obligations buried in dataset terms that no license scanner was designed to evaluate: none of these exist within the vulnerability intelligence infrastructure that makes the SBOM actionable.

That’s the gap an AI-BOM (AI Bill of Materials) is designed to fill. From my perspective, this feels like the same moment the industry went through with the SBOM about five years ago. The requirement is taking shape, the standards are emerging, and the teams that start now will be ready when compliance becomes unavoidable.

This Is a Global Compliance Problem, Not a European One

I recently co-presented a session with Carsten Huth, our Global Director of AppSec Advisory, on supply chain security and regulatory compliance. He made a compelling point: AppSec is becoming the technical implementation layer for CRA compliance. Security is no longer optional – it’s mandatory and it’s regulated.

The EU Cyber Resilience Act (CRA) and the EU AI Act get the most attention because their timelines are defined and their penalties are significant. But they’re just a part of a broader, global shift in how governments and enterprises need to be thinking about AI accountability.

In the United States, NIST AI Risk Management Framework (RMF) has evolved from optional guidance into a reference framework embedded not only in federal procurement, but increasingly in enterprise vendor assessments across regulated industries. In the UK, the AI Safety Institute is developing frameworks that mirror many of the EU’s documentation and transparency expectations. ISO 42001, the international standard for AI management systems, is becoming a global procurement requirement as enterprises extend their vendor risk programs to cover AI-enabled software.

At the same time, regulators in sectors like financial services, healthcare, and critical infrastructure are incorporating AI governance directly into existing compliance frameworks. In practical terms, this means that AppSec teams globally shipping software aren’t just managing a European compliance problem. They’re operating within a broader expectation for AI governance – one that’s formalized differently across jurisdictions, but ultimately converges on the same core requirement: you need to be able to demonstrate, with clear and documented evidence, that you know where AI exists in your products and that you are actively managing it.

What I Hear From AppSec Teams Around the World

In our session, Carsten shared something I’ve been hearing over and over again in customer conversations across regions: while regulatory frameworks differ, the security requirements they impose are similar. Whether a team is preparing for CRA, aligning with NIST AI RMF, or responding an enterprise ISO 42001 vendor questionnaire, they’re being asked to do the same thing – know your AI components, assess their risks, document governance process, and produce evidence.

The challenge isn’t lack of awareness; most AppSec leads understand what’s required. The real issue is in having the tooling and processes that meet those expectations. And that gap showed up clearly when we surveyed over a hundred AppSec and development professionals: Shadow AI is already the reality. 43% have no formal governance over which AI components their developers are permitted to use. At the same time, 70% expect AI components in production by the end of 2026, with 24% already there today.

Production codebases most commonly surface three categories of AI assets: LLMs, AI libraries, and AI agents – with the most frequently detected providers ranking as #1 OpenAI, #2 Google, and #3 Linux Foundation. These aren’t experimental integrations; they are core dependencies that influence application behavior, data handling, and decision-making. But in most organizations, security teams don’t have a structural inventory or record of them.

What we asked customers what they need most, their priorities were clear: first, enforcement in CI/CD and PR, then compliance and audit reporting. That ranking says a lot. Teams closest to this problem already understand that enforcement and documentation need to go hand in hand. You can’t produce credible compliance evidence for AI components if their use was never controlled in the first place. The audit trail has to start at integration – not be reconstructed when an audit request arrives.

Why AI-BOM Is the Right Artifact

I want to be clear about what an AI-BOM is, because I think there’s still genuine confusion in the market about what compliance frameworks are asking for.

An AI-BOM is a structured, machine-readable inventory of the AI components embedded in or consumed by a software application. Where a traditional SBOM tracks packages, an AI-BOM tracks the things that define how AI behaves in your product:

• Models: provider, version, provenance, and fine-tuning lineage
• Datasets: origin and licensing terms
• Agent frameworks and SDKs: the libraries that power AI behavior in code
• Agents: what tools they can invoke and what constraints govern their execution
• MCP servers and clients: external connection configuration
• System prompts: the instructions that shape model behavior in ways that are compliance-relevant even when they never appear in a package manifest

This broader scope reflects the reality of what’s running in production AI-enabled applications, which goes beyond than what most programs currently track. And just as important as the content is the format. The CycloneDX specification has extended its schema to support AI and machine learning components, providing a standard way to make AI-BOMs interoperable with existing compliance infrastructure.

At the same time, the OWASP AI Exchange has been doing important work defining what a complete AI-BOM should include. Aligning with these standards ensures the output plugs into existing workflows instead of requiring entirely new ones.

Regulators and enterprise customers are looking for documentation that can answer specific questions about specific components, with enough detail to support meaningful assessment. That’s exactly what a well-structured AI-BOM provides – and what an SBOM alone can’t deliver.

What We Built at Checkmarx and Why

When we designed Checkmarx AI Supply Chain Security, we made several decisions that shaped the product. The most important was this: detection had to be deterministic. We made a deliberate choice not to use AI to detect AI components.

The reason is straightforward. If a finding in an AI-BOM cannot be traced back to a specific location in source code or configuration, it won’t hold up as audit evidence. When an auditor asks where a component reference comes from, they need something concrete – a file name and a line number – not a confidence score. Deterministic detection, based on imports, API call patterns, configuration files, and string constants produces findings that developers can act on and auditors can trust.

The second decision was to build AI-BOM generation directly into Checkmarx One, rather than offering it as a standalone product. The rationale is similar to why teams adopted SCA inside an AppSec platform: governance works best when it embedded into existing workflows, not running alongside them as a separate process.

Checkmarx One generates the AI-BOM in CycloneDX format, aligned with the schema extensions for AI and machine learning components. When a customer or auditor requests a bill of materials, the AI layer is already included.

Policy enforcement works through the same mechanisms teams already use for open-source governance. Provider allowlists and blocklists are enforced in pull requests and CI/CD pipelines, floating model references get flagged before they introduce undocumented changes, and agent scope constraints surface alongside SAST and SCA findings in the same security gate. The discipline is familiar; the coverage now just extends to AI.

For teams navigating multiple compliance frameworks simultaneously – which, given the global regulatory landscape, is most enterprise teams – Checkmarx One also provides compliance posture reporting that maps AI-BOM output to the documentation requirements of CRA, the EU AI Act, NIST AI RMF, ISO 42001, and others. When an assessment arrives, the documentation does not need to be assembled from scratch; it’s already versioned per release, traceable to specific code, and structured to answer the questions auditors are asking.

As Carsten put it: “The SBOM with AI-BOM as structured documentation, providing tooling output for audit-ready security evidence.” That is exactly what we set out to build.

Timing Is Everything in AI Era

The question I hear most often from AppSec leads is simple: how urgently do we need to move on this?

My honest answer is that the urgency is already here, even if it doesn’t feel that way yet. For teams shipping into European markets, the CRA timeline is fixed: reporting obligations in 2025, CE marking in 2026, and full compliance by December 2027. In the U.S., alignment with the NIST AI RMF is already showing up in vendor assessments. In sectors like financial services and healthcare, regulators are extending existing compliance frameworks to cover AI. And across the board, enterprise procurement teams are starting to ask for AI-BOM documentation in security questionnaires, driven by their own compliance requirements.

At the same time, building the ability to produce a compliance-ready AI-BOM takes longer than most teams expect. Achieving meaningful detection coverage across applications, integrating into CI/CD pipelines, defining policies, and validating outputs against regulatory expectations aren’t quick wins; they require deliberate investment and take time.

But beyond timelines and deadlines, there’s a more immediate reality: AI components are already in production. They’re influencing product behavior in ways that carry real risk, and that risk is invisible in a traditional SBOM. Governing those AI components properly isn’t about preparing for future compliance obligations – it’s about closing a security gap that exists right now.

The problem is that as development speed increases, so does risk. AI doesn’t just write features; it writes vulnerabilities just as easily.

This is the AI coding paradox. The same technology accelerating development is also accelerating exposure, because code coming out faster doesn’t mean it’s coming out cleaner. Even advanced AI models introduce security vulnerabilities while generating functionally correct code – and it’s because code that works and code that’s secure are not the same thing. At the scale and speed that AI operates today, the gap between “works” and “secure” is growing faster than any security team can manually manage.

Eventually, the hangover sets in: the vulnerability backlog grows, rework starts slowing teams down, and security debt accumulates under all that increased productivity. According to Checkmarx’s Future of Application Security report, 81% of organizations knowingly ship vulnerable code, driven by overwhelming noise, uncontextualized backlogs, and limited resources. AI alone didn’t create that behavior, it just dramatically accelerated the consequences.

Gartner highlight this trend in their latest report¹, noting that as AI-generated code enters the codebase “without governance of its presence, the risks of security incidents and breaches from software products are exponentially increasing.”

But slowing down AI adoption isn’t a practical option at this point; it’s too deeply entrenched in development workflows to slow down, and business expectations have already shifted to match.

AppSec Infrastructure Is Broken

The only path forward is ensuring security infrastructure evolves at the same pace as development. The latest Gartner research maps exactly where organizations are falling short, identifies three specific gaps driving the problem:

The first is accountability. Gartner posits that “agentic coding tools are inherently incapable of taking accountability; you and your engineers are.” Without clear governance structures, responsibility diffuses and nothing gets caught until it’s complex and expensive to fix. Gartner recommends that organizations designate AI software leads: individuals explicitly accountable for the security and quality of AI-generated code, so there’s always someone looking for vulnerabilities.

The second is policy. Most teams have no formal allow and deny lists for AI coding tools, no structured training on data privacy risks, and no centralized visibility into what’s being produced. Gartner’s position it that internal governance for AI tool use needs to be built into strategic goals, performance reviews, and the secure software development methodology – not treated as an afterthought.

The third is automation. Running a single security scan at the end of a sprint isn’t enough when AI is generating code continuously throughout it. Gartner calls for a layered approach, combining tools that catch different vulnerability types across different stages of the pipeline, noting that organizations need to “layer multiple tools to provide defense-in-depth to security review AI-generated code at scale and with greater efficiency.” The goal is coverage that’s as continuous as the code being produced.

None of these gaps can be closed independently, and that’s what makes them difficult to address. Good tooling doesn’t help much if no one is accountable for acting on what it finds. Strong policy doesn’t do much if there’s no automation to actually enforce it. All three need to be in place for any of them to work properly.

How Checkmarx Closes All Three

Checkmarx One is designed to address these gaps directly through a single, integrated platform rather than a patchwork of point solutions.

For accountability, its ASPM layer creates a unified risk profile across code, dependencies, AI models, and runtime environments. Centralized audit logs, usage analytics, and AI output acceptance rates give teams clear visibility into what is being produced and deployed. When issues arise, there is already a complete record in place, making ownership and traceability straightforward.

For policy, Checkmarx enforces security rules consistently across the entire AI toolchain, not just the code it generates. Every model, dependency, MCP server, and AI tool is evaluated against organizational policies and tracked within a centralized AI-BOM. This gives security leaders a complete, enforceable inventory and turns governance from an abstract goal into an operational reality.

For automation, Checkmarx uses a hybrid approach that combines deterministic, rules-based engines with AI-powered contextual reasoning – because neither works as well alone. The deterministic layer reliably identifies known vulnerability patterns, while AI-driven analysis detects the novel issues introduced by agentic coding tools. Together, they reduce noise and deliver higher-confidence findings, allowing teams to focus on real risk instead of spending time validating false positives.

Addressing these gaps is not just about better tooling; it’s about keeping security aligned with the speed of modern development. That is where agentic AppSec comes in. Instead of relying on scans at the end of a sprint, Checkmarx Assist agents operate directly within the development workflow. Developer Assist flags vulnerabilities in the IDE before code is committed, Triage Assist prioritizes what truly represents risk, and Remediation Assist provides ready-to-merge fixes within pull requests.

This creates a continuous loop where risks are identified, understood, and resolved as code is written, rather than after the fact. Gartner calls autoremediation “a stand-out use case for AI in application security programs,” and this is exactly the role Checkmarx’s agentic agents are built to fulfill, with human oversight remaining firmly in control.

What Happens When You Don’t Act

he cost of ignoring these gaps shows up quickly. Checkmarx research shows that up to 45% of AI-generated code may be insecure, and large language models produce inconsistent results across tools and environments, meaning the problem is not isolated to a single model or team. Without accountability structures, policy enforcement, and automated scanning in place, there is no reliable way to catch what AI is quietly introducing into the codebase.

In practice, the way this debt accumulates follows a familiar pattern. Code ships quickly, tests pass, and everything appears fine until a security scan weeks later flags a vulnerability buried in an AI-generated dependency chain. By then the developer has moved on, the original context is gone, and what could have been a quick fix in the IDE turns into hours of rework, reproduction, and validation. When this plays out across hundreds of developers and projects simultaneously, security debt stops looking like a backlog and starts becoming structural drag on the entire organization.

The progression is predictable: fixes caught early are inexpensive, fixes after commit are costly, and fixes after a breach are far more severe. The three gaps Gartner identifies aren’t just operational inconveniences; they are the conditions that make the expensive version of this problem inevitable. Closing them is what keeps the cost manageable.

Hangovers Don’t Fix Themselves 

Gartner’s argument is not that teams should slow down AI adoption. It is that security infrastructure must keep pace with development, and most organizations have not caught up.

The vibe coding hangover is real, and it gets worse the longer it goes untreated. Every week of unscanned AI-generated code is another week of debt accumulating quietly underneath the productivity gains.

Checkmarx One is built for this reality, closing the accountability, policy, and automation gaps directly inside the developer workflow so security scales with development instead of falling behind it. The hangover remedy isn’t slowing down; it’s building the infrastructure that makes the speed sustainable.

Access Gartner’s Best Practices to Mitigate Security Risks With Agentic Coding Tools report here and learn more about Checkmarx’s agentic application security here.

¹Gartner, Best Practices to Mitigate Security Risks With Agentic Coding Tools, Aaron Lord, Manjunath Bhat, 24 March 2026 

GARTNER is a trademark of Gartner, Inc. and/or its affiliates. 

Now imagine handing that novel to a meticulous editor whose only job is to find every flaw. You’re in trouble.

That’s the analogy Checkmarx CEO Sandeep Johri used in his recent conversation with the New York Stock Exchange (NYSE), and it captures what’s happening to modern codebases. AI is accelerating software creation at a staggering pace, but it’s also introducing inconsistencies, blind spots, and unintended behavior just as quickly. And unlike a novel, your code doesn’t get a friendly editor; it gets attackers actively searching for those gaps.

According to Johri, the volume of AI-generated code is growing faster than the security programs designed to protect it. The result is that developers are no longer just building software, they’re also responsible for securing a much larger and more complex codebase.

And the stakes are rising.

With systems like Anthropic’s Claude Mythos reportedly capable of autonomously discovering and exploiting vulnerabilities at unprecedented speed and scale, the imbalance is only getting worse.

The question isn’t whether your code has gaps; it’s whether your security can keep up with how fast they’re being created and how quickly someone else can find them.

More Code, More Risk 

Johri’s core point is straightforward: AI coding agents are producing more code – and more vulnerabilities. In fact, AI-generated code can contain two to three times the density of vulnerabilities compared to code written solely by humans, and the overall volume is growing fast.

Before AI, developers had a deep understanding of the code they wrote. Now, a single prompt can generate hundreds of lines instantly. The code works, but the context behind it – the decisions, trade-offs, and potential risks – is often missing.

Open source adds another layer. Roughly 70% of a typical enterprise application is made up of open-source components. Developers rely on it to move quickly, trusting that the code has been properly maintained and secured upstream. Sometimes that trust is well placed, but other times vulnerabilities or malicious code slip through.

The result is a growing backlog of risk. According to Checkmarx’s Future of Application Security report, 81% of organizations knowingly ship software with vulnerabilities they’ve already identified. These aren’t unknown threats or zero-days, they’re known issues that get deprioritized in favor of speed.

Developers Are in the Crosshairs

Developers are at the center of this problem because that’s where code begins. But most developers aren’t security experts – and they shouldn’t have to be. Their job and discipline is to build the functionality the business needs, and to build it fast. Security has historically been a separate discipline, applied after the fact, by a completely different team. But in the age of AI, later is really just too late.

What’s changed is the level of exposure. Because now developers aren’t just introducing risk, they’re being directly targeted. Attackers go after their package registries, plant malicious open-source dependencies, and compromise their credentials to gain access to codebases. The developer’s entire workflow – the IDE, the coding assistant, the dependencies – has become the attack surface.

Anthropic’s Claude Mythos makes this shift even harder to ignore. When Mythos found a 27-year-old bug in OpenBSD and catalogued vulnerabilities across major open-source dependencies, it wasn’t finding anything new. Those vulnerabilities were already there, sitting in production systems that developers had built on top of for years. What Mythos demonstrated is that finding and exploiting them is now fast, automatic, and cheap – roughly $1 per exploit in 10 to 15 minutes with no specialized expertise required.

And these vulnerabilities that developers unknowingly ship won’t sit idle anymore. With AI, the window between disclosure and active exploitation has shrunk, from roughly 840 days in 2018 to about 1.6 days today.

AI Is Also Creating New Threats

AI development isn’t just introducing more vulnerabilities, but it’s also introducing entirely new kinds of risk.

Coding assistants can hallucinate package names that don’t exist, and attackers are already registering those names to turn a simple mistake into a malicious dependency. Applications that pass user input into LLMs are now exposed to prompt injection, an entirely new attack vector with no real equivalent in traditional software. And as development becomes more agent-driven, with AI systems taking actions through MCP servers, the attack surface is expanding beyond what conventional security tools were designed to handle.

Some coding tools are starting to layer in security features, but as Johri points out, they don’t do it as exhaustively or with the full enterprise context of purpose-built AppSec platforms – and that includes Claude Code Security.

As AI-driven development accelerates, closing this gap will require security tools built specifically for how software is being created today, not how it was built before in the pre-AI era.

Security Has To Become Agentic Too

Johri’s conclusion is simple: application security needs to become agentic. The human-in-the-loop model that’s worked until now can’t keep pace with the velocity of AI-generated code. Agents generating code need security tools that can be called automatically, integrated into the pipeline, and capable of acting on what they find rather than just flagging it for someone to review later.

That urgency is reinforced by developments like Anthropic’s Project Glasswing, a coalition of 40+ technology organizations built around using Mythos defensively. It’s a clear signal that the industry sees what’s coming – but a coalition isn’t the same thing as a security program.

What’s really needed in this new age is a hybrid approach that combines AI’s speed and scale with deterministic analysis that doesn’t hallucinate. On its own, AI scanning produces findings that erode trust: it will flag an exception already caught upstream, describing a race condition in single-threaded code. Without a rules-based SAST, SCA, and IaC layer to validate what the AI finds, you’re just generating noise at scale.

And timing is just as important. Security has to begin at the moment code is created, while context still exists. In AI-driven development, even a short delay means that context is gone. And when vulnerabilities are found later, developers have to revisit code they’ve already moved past and no longer have the context for – and that retrace slows everything down and increases the chance risk will slip through.

Keeping Up With the Code

The takeaway here is that AI is accelerating how code is written, but security isn’t keeping up. More code, less context, and faster exploitation are all converging at once – and with the recent Mythos announcement, that gap is widening.

The good news is that slowing down development isn’t the answer. The path forward is bringing security into the same flow as development for a more seamless experience: integrated, automated, and able to keep pace with how code is created.

That’s where agentic application security comes in. It needs to move beyond detection to help developers understand, prioritize, and remediate issues in real time, without adding friction or noise.

Watch the full interview here, or learn more about how Checkmarx One is tackling this with Developer Assist, Triage Assist, and Remediation Assist.

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.

But there is a tradeoff.

The faster code is created, the faster security issues can enter the codebase too.

AI-generated code can introduce vulnerable packages, insecure coding patterns, exposed secrets, and risky infrastructure configurations just as easily as it can generate productivity gains. And when teams are moving at AI speed, traditional AppSec processes often cannot keep up.

Security reviews that happen during a pull request, in CI/CD, or after code is merged come too late. By then, the developer has already moved on, forgotten the original context behind the code, or shipped the issue downstream.

That is why security has to move earlier in the process, closer to the moment code is created.

Traditional AppSec Was Not Built for AI-Native Development

Most AppSec programs still rely on a familiar model: developers write code, scanners run later, and security teams review the results afterward.

That model already struggled to keep up with modern development, and in an AI-native workflow, it breaks completely.

When developers are using AI to generate code, update dependencies, create infrastructure-as-code (IaC) templates, or accelerate repetitive tasks, the volume of changes increases dramatically. Teams are no longer reviewing a handful of manual changes at a time. They are reviewing far more generated code, and often with less scrutiny because the pace of work is so much faster.

That creates a growing execution gap between how fast code is produced and how fast security can respond.

Bringing Security Directly Into Windsurf

Developer Assist brings AppSec directly into Windsurf, so developers can identify and fix issues while they are still coding.

Instead of waiting for a pull request review or a pipeline scan, developers get immediate feedback directly in the editor. Vulnerabilities, risky dependencies, secrets, infrastructure misconfigurations, and malicious packages can all be surfaced in real time as code is written or modified.

That matters even more in an AI-native editor like Windsurf, where code is not just being typed manually. Files may be generated, updated, or rewritten by AI assistants in seconds.

Developer Assist helps ensure those changes are reviewed with security in mind before they move downstream.

What Developer Assist Catches in Real Time

• Vulnerabilities in custom code
• Risky open source dependencies
• Exposed secrets and credentials
• IaC misconfigurations
• Malicious or suspicious packages
• Insecure AI-generated code patterns

Scans happen automatically as developers work, including when files are edited, saved, opened, or updated by AI. That means developers can catch issues while they are still in the context of writing the code, when fixes are faster, easier, and far less disruptive.

This is especially important for open source packages and AI-generated code. It’s easy for an AI assistant to recommend an outdated package version, insecure configuration, or code snippet that looks correct but in reality introduces risk.

Developer Assist gives developers a way to validate those changes before they make it into the codebase.

Security Without Breaking Developer Flow

The biggest challenge with traditional AppSec is not just that it happens too late. It is that it interrupts developers at the worst possible moment.

No developer wants to stop what they are doing, switch tools, wait for a scanner to finish, or debug a security finding days after they wrote the code.

The best security tools are the ones developers barely notice because they fit naturally into the workflow.

That is what makes Developer Assist a strong fit for Windsurf. Developers can stay in the editor, keep moving quickly, and still get the security guidance they need when it matters most.

See Developer Assist in Windsurf

Checkmarx is partnering with Windsurf through Agentic Labs to give developers hands-on experience with Developer Assist in an AI-native coding environment.

These labs allow developers to explore how real-time vulnerability detection, dependency analysis, secret detection, and inline remediation work directly inside Windsurf. Instead of reading about secure AI-assisted development, developers can experience what it looks like in practice.

As AI-native development becomes more common, security teams will need to shift from scan-and-fix-later to secure-as-you-generate.

Because in an editor like Windsurf, code is moving too fast for anything else.

In tools like Cursor, developers are increasingly prompting, reviewing, editing, and accepting work produced by AI. Entire functions, files, fixes, and dependency updates can be generated in seconds.

That shift is changing the role of the developer.

Instead just authoring code, developers are becoming reviewers and orchestrators of AI-generated work. They are evaluating suggestions, validating changes across multiple files, deciding which fixes to accept, and making sure generated code is ready for production.

That can dramatically improve productivity. But it also introduces a new challenge: developers are now responsible for reviewing far more code than they ever actually wrote.

Cursor Is Changing How Developers Build

One of the biggest advantages of Cursor is its ability to take on larger coding tasks.

Developers can ask Cursor to generate new functions, refactor existing code, update dependencies, make changes across multiple files, or suggest fixes for bugs. Instead of spending time on repetitive implementation work, developers can focus more on direction, validation, and refinement.

That changes the development workflow in an important way.

Developers are no longer reviewing only a handful of lines they wrote manually. At any time they may be reviewing dozens or hundreds of lines of AI-generated code, often spanning multiple files, packages, or services.

When that happens, security issues can spread just as quickly as productivity gains.

AI Can Introduce Risk at Machine Speed

AI-generated code is not automatically secure.

An AI assistant can recommend outdated dependencies, insecure coding patterns, weak authentication logic, vulnerable package versions, exposed secrets, or infrastructure configurations that create unnecessary risk.

And because Cursor can generate changes so quickly, those issues can make their way into the codebase faster than traditional AppSec tools can catch them.

Security reviews that happen in pull requests, CI/CD pipelines, or after code is merged are often too late. By then, the developer has already accepted the code, moved on to another task, or lost the context behind why the change was made.

The faster AI-generated code moves, the more important it becomes to validate that code before it is accepted.

Bringing Security Into the Review Process

Developer Assist brings security directly into Cursor so developers can validate AI-generated code while they are still reviewing it.

Instead of waiting for a later-stage scan, developers can get immediate feedback directly in the editor. Vulnerabilities, risky dependencies, secrets, infrastructure issues, and malicious packages can all be surfaced before the generated code is accepted or committed.

That is especially important in Cursor, where developers are often reviewing larger, more complex sets of generated changes.

Developer Assist helps developers move from simply accepting AI-generated output to actively validating it.

What Developer Assist Helps Cursor Users Validate

• AI-generated code for insecure patterns
• Multi-file changes that may introduce risk
• Dependency upgrades and package recommendations
• Exposed secrets and credentials
• Infrastructure-as-code (IaC) misconfigurations
• Malicious or suspicious packages
• Suggested remediations before they are accepted

Scans happen automatically while developers work, including when files are opened, edited, saved, or updated by AI.

That means developers can review security findings while they are still in the context of evaluating the generated code, instead of discovering issues much later in a pull request or pipeline scan.

Trust, But Verify

AI coding tools like Cursor are changing how software gets built.

They allow developers to move faster, automate repetitive work, and focus more on problem solving than implementation. But they also introduce a new responsibility: developers need to validate the code they did not write themselves. The gap between generation and validation is where risk accumulates, and it grows as speed increases.

The future of development is not about choosing between speed and security. Cursor can generate code in seconds, but speed means nothing if the code introduces vulnerabilities before it reaches production.

Developer Assist gives developers a way to close that gap, so AI-generated code secure, compliant, and ready to ship.

That speed has a cost. According to the World Economic Forum, 94% of surveyed leaders expect artificial intelligence to be the most significant driver of change in cybersecurity, even as 87% identify AI-related vulnerabilities as the fastest-growing cyber risk. Vulnerabilities now propagate faster than traditional controls can detect them. At this speed, pausing development to evaluate risk isn’t just inconvenient – it’s operationally impossible.

Security has to move with the code, not after it.

The Scale Problem: Vulnerability Growth Is Now an Operational Constraint

Alongside this explosion of AI-driven development, the global vulnerability landscape is expanding just as fast. The Forum of Incident Response and Security Teams (FIRST) projects that 2026 will be the first year to exceed 50,000 published vulnerabilities, with a median forecast of approximately 59,427. Manual prioritization is no longer viable.

The numbers alone don’t capture the operational shift. For decades, application security programs depended on predictable development cycles that created natural pauses for risk evaluation. AI-driven development removes those pauses. Code is generated automatically, refined instantly, and deployed continuously. Traditional security gates depend on time – and continuous delivery eliminates it.

A recent breach illustrates how quickly this can play out in practice. Using GenAI, a small group of attackers generated more than 400 custom scripts and launched attacks across 300+ servers, automating what once required coordinated teams and significantly compressing the time from vulnerability discovery to exploitation.

Security is no longer restrained by detection capability, but by decision capacity. The challenge is no longer whether organizations can find vulnerabilities. It is whether security teams can make decisions fast enough to keep pace with the volume and velocity of AI-generated code. Teams must determine which risks matter most and how to reduce exposure fast. As the National Institute of Standards and Technology (NIST) has observed, secure practices must be embedded directly into lifecycle stages rather than appended as separate steps.

From Engineering Problem to Organizational Risk 

AI security has moved from an engineering concern to an organizational one. Leaders increasingly recognize that the risks associated with AI-driven development extend beyond technical vulnerabilities to affect organizational resilience, regulatory compliance, and customer trust.

The risks are operational: misconfigured dependencies can introduce vulnerabilities, unauthorized access can compromise systems, and automated workflows can propagate errors at scale. Governance and engineering are describing the same problem from different angles, and the challenge isn’t choosing between them but integrating them.

That integration doesn’t happen through policy updates alone. It requires rethinking how AI development is structured, how dependencies are managed, and how security controls are embedded into the workflow itself.

The supply chain is where that challenge becomes most visible.

The Expanding Supply Chain: From Software Components to AI Systems

Supply chain risk has always been a central concern in software security, but AI introduces new layers of dependency that are harder to observe and harder to control. Traditional software supply chains included libraries, frameworks, and external services, while modern supply chains include AI models, prompts, orchestration layers, and runtime agents.

The European Union Agency for Cybersecurity reports that supply chain risks currently account for 10.6 percent of identified threat categories. As software ecosystems become more interconnected, the number of potential entry points for attackers increases – and dependencies that once served as conveniences become liabilities.

The recent attack on Cursor illustrates how quickly trust assumptions can be exploited. Attackers chained a prompt injection with a sandbox bypass and remote tunneling capability to obtain shell access simply by convincing a developer to open a repository. Because the attack leveraged legitimate tooling features rather than traditional malware, perimeter defenses offered little protection. Modern supply chain risk increasingly originates inside the developer workflow itself, where trusted automation interacts directly with untrusted code and content. Developer tool itself has become part of the attack surface.

This is part of a broader pattern. When applications automatically retrieve and execute external artifacts without verifying their integrity or origin, malicious actors can substitute compromised components into the execution environment – turning trusted dependencies into attack vectors.

These attacks do not rely on advanced exploitation techniques, but on assumptions: when AI systems automatically trust external components, attackers can manipulate that trust.

The Two-Layer Guardrail Architecture 

Security leaders are responding to these challenges by adopting a new architectural principle that treats AI-generated code as untrusted input until it has been verified through independent controls. This guardrail model gives this principle operational form, organizing security into two complementary control loops: prevention (inner loop) and enforcement (outer loop).

The preventive loop operates at the moment code is created. This is the stage when developers have the most context, and the remediation costs are lowest. Errors caught here can be immediately corrected, before vulnerabilities have a chance to propagate downstream. Traditional review processes were designed for a world where code arrived in batches. AI-generated code arrives continuously, which means security controls must operate continuously as well.

Checkmarx’s Developer Assist embodies this approach. Working within the developer workflow, it analyzes generated and handwritten code in real time, identifies patterns associated with security risk, and provides contextual guidance before changes leave the local environment. Security shifts from reactive to proactive, preventing vulnerabilities during creation instead of after deployment.

The enforcement loop operates at the moment that code is integrated. This is where organizations apply consistent policies across environments, evaluate risk in context, and establish accountability for security decisions.

Checkmarx’s Triage Assist and Remediation Assist operationalize this by analyzing vulnerabilities in relation to runtime behavior, dependency relationships, and exposure paths. Rather than surfacing large volumes of findings ranked by severity alone, the agent evaluates which issues are realistically attackable and generates prioritized remediation actions.

This distinction between detection and decision-making is central to the scalability of modern security programs. At the scale of today’s vulnerability landscape, the ability to prioritize effectively determines whether security controls reduce risk or simply generate noise.

A Continuous Security Workflow for AI-Driven Development 

The guardrail model operates as a continuous workflow across three stages.

As code is written, Developer Assist evaluates changes in real time, identifying potential vulnerabilities and recommending secure alternatives before anything leaves the local environment.

At integration, automated pipelines execute security scans and policy checks. Triage Assist and Remediation Assist analyze the results, determining which vulnerabilities pose immediate risk and generating remediation guidance. Human approval is required before deployment, keeping accountability for critical decisions with the team.

After deployment, monitoring systems track system behavior, detect anomalies, and feed insights back into the development workflow. This feedback loop allows security controls to dynamically adapt as new threats emerge, rather than waiting for the next scheduled review.

The result is a system where security is no longer a checkpoint, but a continuous property of the development process itself.

What Effective Governance Looks Like in Practice 

Organizations that succeed in AI-driven development environments build operational guardrails that define how software is generated, validated, and deployed. Governance works when risk management is translated into enforceable controls embedded directly into the development workflow.

A practical governance baseline for 2026 includes the following minimum controls:

1. Govern AI Systems as First-Class Assets 

AI coding tools, agents, and model components are now part of the software supply chain. They must be managed with the same rigor as production infrastructure.

Operational controls:

• Maintain a centralized inventory of AI coding tools, agents, and model dependencies  
• Assign accountable owners for each AI component  
• Classify AI systems by risk and operational impact  
• Enforce approved usage policies for AI development tools

Why this matters: AI systems become governable infrastructure rather than unmanaged productivity tools.

2. Enforce Risk-Based Prioritization

At the current vulnerability scale, remediation effectiveness depends on prioritization accuracy. Organizations cannot fix everything; they must fix what is exploitable in their environment.

Operational controls:

• Implement contextual risk scoring based on exploitability and exposure  
• Automate triage workflows within pull request and CI/CD pipelines  
• Define remediation service-level objectives tied to business risk  
• Suppress non-exploitable findings to reduce operational noise  

Why this matters: Engineering effort is directed toward vulnerabilities that materially increase risk.

3. Centralize Software and AI Supply Chain Controls

Modern supply chains include models, prompts, orchestration components, and external dependencies. These assets must be continuously verified to prevent trust-based compromise.

Operational controls:

• Enforce dependency provenance and integrity validation  
• Maintain software and AI bills of materials (SBOM and AI-BOM)  
• Monitor repositories and registries for unverified or malicious components  
• Apply consistent security policies across software and AI dependencies  

Why this matters: Supply chain risk becomes observable and controllable across the full development ecosystem.

4. Establish Guardrails for Agentic Systems

Agentic workflows introduce operational risk because automated systems can execute actions without direct human oversight. Governance must define the boundaries within which agents operate.

Operational controls:

• Assign unique identities to all AI agents and automation services  
• Define permission boundaries for agent actions  
• Enforce tool invocation policies for automated workflows  
• Maintain auditable records of agent decisions and system interactions  

Why this matters: Agent behavior becomes predictable, accountable, and traceable across environments.

5. Standardize Prompts as Governed Inputs

Prompts influence system behavior and security outcomes. They must be treated as controlled inputs rather than informal instructions.

Operational controls:

• Develop approved prompt templates for common development tasks  
• Enforce prompt validation and policy checks before execution  
• Log prompt activity for audit and incident response  
• Restrict generation patterns that introduce known security risks 

Why this matters: Prompt usage becomes consistent, auditable, and aligned with secure development practices.

6. Measure Security Performance Using Operational Metrics

Governance is only sustainable when performance is measurable. Metrics must reflect real risk reduction, not activity volume.

Operational controls:

• Track time-to-fix for exploitable vulnerabilities  
• Measure reduction in non-actionable findings  
• Monitor policy compliance across development workflows  
• Report risk reduction outcomes to executive leadership 

Why this matters: Security performance becomes quantifiable and aligned with business resilience.

The World Economic Forum emphasizes that guardrails and secure-by-design practices must accompany AI adoption. Without them, misconfiguration and adversarial manipulation become predictable outcomes rather than isolated incidents. The lesson is straightforward: resilience depends on architecture, not intervention.

The Strategic Shift Ahead

The most common mistake organizations make when confronting AI security challenges is assuming that the solution is more tools. Tools improve visibility, but they cannot compensate for structural misalignment between development speed and security processes.

Traditional security models assumed that software was produced by humans operating predictable workflows, but that assumption no longer holds. Software is now continuously produced by AI and security controls must operate at the same speed. This isn’t an incremental change; it’s a different relationship between development and risk. Organizations that recognize this shift early will be able to adapt their workflows and maintain confidence in their software. Those that don’t will find themselves managing the complexity of modern systems instead of reducing risk.

The organizations that succeed in the age of agentic development won’t rely on stronger gates or stricter controls. They’ll build smarter guardrails.

Want to see this in practice? Explore Triage Assist and Remediation Assist. Still evaluating your options? Check out the Agentic AppSec Buyer’s Guide.

Then, weeks later, leadership asks: “Are we using AI in any of our applications?” 

Honestly? No one knows. 

Somewhere in your codebase, invisible to every tool you have, an application is calling a hosted LLM service. An agent framework arrived through a dependency. Prompts are loading from runtime configuration. Embeddings are being sent to a vector store. 

None of it shows up in your SBOM. None of it is on anyone’s radar. 

This isn’t a failure of your security team. It’s a structural gap. 

The Supply Chain is Changing (Again) 

For years, traditional AppSec protected a predictable set of things: application code, open-source packages, secrets, containers, and infrastructure. SAST, SCA, vulnerability management, all built for that world. 

Then AI became a production dependency. 

More than 75% of enterprises are already embedding LLMs, AI SDKs, and AI services directly into their applications. But the security and governance programs designed to manage software haven’t caught up. 

Modern applications now depend on: 

• Hosted AI services (LLM APIs) 

• AI frameworks and SDKs 

• Agent code and MCP servers 

• Prompts and datasets 

• Embeddings and vector stores 

These don’t behave like traditional dependencies: 

• A model can be safe in testing and unsafe under real-world prompts 

• A prompt can quietly change system behavior without changing application logic 

• An MCP tool can expand execution capability beyond what developers intended 

• A service provider can change data retention terms without a code change 

Traditional AppSec tools don’t detect these risks because they weren’t designed to. They can’t assess model poisoning, unverified weights, unsafe adapters, malicious MCP servers, or licensing violations.  

None of these are hypothetical. They’re showing up in real pipelines, real codebases, and real compliance conversations, often without anyone realizing it. 

At the same time, regulatory pressure is real. The EU AI Act, ISO 42001, and other frameworks are creating real accountability for AI governance. Yet, most organizations lack even a basic AI asset inventory, let alone the ability to demonstrate compliance. 

The Hidden Threats in Your AI Dependencies 

Below are 10 prominent AI supply chain risks validated by OWASP LLM03:2025 (the industry standard) and our own Checkmarx Zero research team. 

These risks reflect where visibility gaps typically become security gaps in this new supply chain structure: 

Group A: Trust & Provenance Poisoned models, fake models, abandoned models, vulnerable AI packages—risks tied to where models actually come from and whether you can trust them. 

Group B: Modification & Fine-Tuning Malicious adapters, model merge exploits—risks introduced when models are altered without visibility. 

Group C: Deployment Risks Mobile and edge model attacks where compromised models are embedded outside standard update mechanisms. 

Group D: MCP Supply Chain Tool poisoning, compromised dependencies, shadow MCP servers, unauthorized integrations that expand what AI can actually do. 

Group E: Governance & Exposure Licensing violations, unclear terms-of-service, privacy policy drift that quietly changes how your data is used. 

Each reflects a different failure mode: compromised artifacts, unmanaged modifications, invisible deployments, unauthorized connections, and untracked obligations. 

Where Does Your Organization Actually Stand? 

Most security teams assume they’re at least partially aware of their AI exposure. In practice, the answer is usually Stage 1: Unknown. There’s no inventory, no policy enforcement, and no audit trail, just scattered usage across repos and environments. 

Getting from Unknown to Governed isn’t a single leap. It’s a defined progression: from discovery, to control, to compliance-ready reporting. Understanding where you sit today is the prerequisite to knowing what to do next. 

Visibility First, Then Everything Else  

What connects all these risks is something simple: if you don’t know an AI component exists in your software, you can’t assess it, govern it, or protect against what it might do. 

This requires building what didn’t exist before: an AI-BOM, an inventory that captures what AI is running your applications and what that implies for risk and compliance. 

This requires four capabilities: 

1. Discover AI assets across code and configuration 

2. Assess AI-specific risks (not just CVEs) 

3. Control through policy enforcement and approved registries 

4. Report compliance-ready documentation 

AI is already embedded in your stack, whether you know it or not. The goal isn’t to slow adoption, it’s to bring the same AppSec discipline to AI dependencies that teams already apply to everything else they ship. 

That starts with visibility.  

Want to go deeper?  

We’ve put together a full breakdown of the threat landscape with all 10 risk categories, real-world examples, and the controls mapped to each. But more than that: the guide walks through a practical AI Supply Chain Maturity Model so you can identify where your organization stands today, a side-by-side comparison of traditional SBOMs vs. AI-BOMs, and a two-floor security architecture that tells you what to preserve from your existing AppSec program and what to add on top of it. 

Read it now