Triage capacity, decision consistency, and remediation throughput are being outpaced by modern development velocity, especially as AI-assisted coding becomes standard practice. The operating environment has changed. There is more code, more change, more dependencies, and more AI tooling.  

These conditions are turning manual triage into a governance and audit liability. The only sustainable path forward is to move security decisions and remediation into the pull request. There, risk decisions are documented, fixes are verified, and accountability already exists through governed, reviewable AI-assistance that accelerates execution without surrendering control. 

The Reality Security Executives Are Living In 

Security and AppSec leaders are seeing the same pattern repeat across teams: findings accumulate, remediation cycles aren’t keeping pace with development, and audit conversations are becoming more demanding. The reason isn’t just rising expectations, but the reality that modern software delivery keeps expanding the attack surface while simultaneously making risk decisions harder to track and standardize.

This exposure isn’t an insufficient tooling or coverage problem. Application security testing has expanded significantly over the past decade, introducing more scan types, deeper integrations, and great vulnerability visibility. Despite this progress, a consistent pattern remains: organizations often release new software even when they know risk is present, simply because their operating model cannot keep pace with delivery. 

Checkmarx research found that 81% of organizations knowingly shipped vulnerable code, and 98% experiences a breach tied to vulnerable code within the last year. Risk exposure is not cause by a lack of awareness; it’s a breakdown in execution. As AI-assisted development becomes the norm, that pressure only grows.

Leaders at major software organizations have publicly stated that AI now generates a significant share of their code, with some estimates ranging from 20 to 30 percent of code in repositories and more than a quarter of new code.  

As software production accelerates, risk enters at the same pace. And when risk enters the system faster than teams can triage it, remediation becomes unpredictable. That unpredictability is what boards and regulators ultimately penalize. Detection has scaled. Execution has not. 

Detection Scaled, Execution Didn’t. Now What? 

Application security programs have made substantial progress over the last decade. Most enterprises now operate with broad coverage that includes SAST, SCA, CI/CD integrations, and developer-focused tooling. However, many programs are now over-detecting vulnerabilities relative to their ability to act on findings. This imbalance creates operational friction and weakens overall security outcomes. 

The symptoms are consistent across organizations. Triage bottlenecks form as teams struggle to review large volumes of findings. Identical issues are handled differently across teams, creating inconsistency in decision-making. Findings remain unresolved for extended periods because priority is unclear, or remediation effort is high. Backlogs grow with items that are technically valid but not treated as immediate risk, while other issues are escalated without sufficient context. 

This dynamic explains why more findings rarely reduce exposure. When everything is flagged, nothing gets fixed. Security leaders feel this as a credibility gap: dashboards show activity, but stakeholders want to know if the organization is getting more secure. That’s a hard question to answer when decision-making is inconsistent, and remediation throughput cannot be predicted. 

The NIST Secure Software Development Framework reinforced this shift, by requiring organizations to document how risk decisions are made and demonstrate evidence of secure development practices. Detection alone is not sufficient. Organizations must show that vulnerabilities were evaluated in context and resolved in a consistent, auditable way.  

Detection is not the end state. Evidence-backed execution is. 

Why Manual Triage Is Now a Business Risk 

At enterprise scale, manual triage is no longer simply inefficient. When security teams manually interpret findings across hundreds of repositories, inconsistency is inevitable and becomes an operational and governance risk. Depending on the team reviewing, identical findings receive completely different treatment. One team immediately remediates, another dismisses it, and another marks it as accepted risk without a standardized rationale. That inconsistency becomes a liability as regulators and auditors increasingly expect organizations to formally document how vulnerabilities are categorized and managed. When the answers to basic governance questions vary across the organization, regulators interpret that variability as a lack of control. Who made the decision? What evidence supported it? Which policy is applied? Without consistent answers, risk exposure becomes unpredictable and difficult to defend.  

These growing expectations arrive precisely when teams are least equipped to meet them. Security teams face ongoing budget pressures and staffing shortages while vulnerability volumes keep rising. Headcount cannot scale in proportion to code volume.  Instead, organizations need to scale execution by relying on more consistent, efficient, and automated approaches to vulnerability management. 

The Pull Request Is the New Control Plane 

If risk is introduced continuously throughout development, governance must be applied at the point where decisions are actually made. In modern engineering environments, that point is the pull request. 

The pull request is where code changes become official: approvals granted, discussions recorded, checks enforced, and ownership is established. It is the only place where execution can be observed and governed at the same speed as development.   

Security decisions belong where code is reviewed, approved, and merged, not buried in dashboards and ticketing systems. 

 Checkmarx’s Triage Assist and Remediation Assist operate directly within pull requests, ensuring that risk decisions are made in the same place where change control already exists. The principle is straightforward: if security execution is not visible within the pull request, it cannot be governed. 

From Alerts to Outcomes: What Changes 

This shift does not eliminate human involvement; It just changes where human judgment is applied. Instead of spending time manually investigating large volumes of findings, teams focus on policy definition, exception handling, and approval. 

Triage Assist introduces a contextual, risk-based prioritization model that converts scan output into decision-grade outcomes. It evaluates vulnerabilities using attackability-driven analysis, combining reachability, exploitability, and policy context to determine which issues require action. This approach moves triage away from severity-based sorting toward context-based decision-making. Findings are classified into clear outcomes such as false positive, acceptable risk, or action required, enabling consistent and defensible decisions across teams. The shift toward context-driven decisioning aligns with broader industry efforts such as the Vulnerability Exploitability eXchange (VEX), which communicates the exploitability of a vulnerability in context , not simply if it’s present. 

Remediation Assist addresses the next stage of execution. Once a decision is made, it generates reviewable, merge-ready fixes directly within the pull request workflow. These fixes are delivered as diffs or remediation pull requests that align with existing development processes. Nothing merges automatically; developers review and approve changes as part of their standard workflow, preserving governance while accelerating remediation throughput. 

Together, Triage Assist and Remediation Assist transform application security from a process centered on alerts to one focused on outcomes. 

Governed AI, Not Autonomous Chaos 

Security leaders don’t need autonomous systems making unchecked changes to code. They need governed execution that improves speed while maintaining control. This distinction matters more as AI expands both development capabilities and the attack surface that comes with it. 

New risks, including prompt injection, supply chain manipulation, and excessive agent permissions, require careful control over how AI is used within development workflows. Even systems that include human oversight can introduce risk if decisions are not transparent or if context is incomplete. Industry frameworks such as the OWASP Top 10 for Large Language Model Applications highlight emerging risks including prompt injection, supply chain manipulation, and excessive agent permissions, reinforcing the need for controlled and explainable execution. 

Read more: When the AI Lies: A New Threat Emerges for “Human-in-the-Loop” Security 

A governed approach to AI-driven security execution is grounded on clear principles. Human review remains mandatory through established approval workflows. Decision rationale is preserved to support auditability. Usage is scoped and controlled across repositories and environments. Automated changes are never merged without review. 

This model ensures that AI accelerates your execution without also introducing uncontrolled behavior. It aligns with the needs of regulated, audit-driven environments where traceability and accountability are essential.

What Success Looks Like for Security Executives 

The goal isn’t better visibility alone, but predictable execution with measurable outcomes: reduced time to decision, faster remediation cycles, and smaller vulnerability backlogs. Standardized, evidence-based triage reduces the need to repeatedly evaluate the same issues across teams, which improves both efficiency and consistency. 

Higher fix acceptance rates and fewer regressions indicate that remediation is delivered in ways that fit developer workflows, without destabilizing applications. Consistent outcomes across teams means that governance is being applied systematically rather than left to individual judgement.

Audit readiness matters just as much. Security artifacts must be tied directly to execution, including pull request discussions, approvals, and documented decisions. This reduces reliance on retrospective explanations when auditors and boards come asking. These outcomes are becoming more critical as exploitation windows continue to shrink. Vulnerabilities are often exploited shortly after disclosure, which mean delayed triage is no longer a workflow preference. It’s a business risk.

The Strategic Shift 

Security leaders do not need more alerts, they need more finished work. Moving away from manual triage is not about reducing security effort, but about operationalizing security in a way that scales with modern development. 

Effective application security requires decisions that are grounded in context, remediation delivered within the development workflow, and governance preserved through auditable processes. This is the shift toward agentic application security, where the gap between how quickly software is created and how quickly risk is understood and mitigated can be closed without slowing innovation. 

Ready to move from manual triage to scalable, governed execution? Explore Checkmarx’s Agentic AI Buyer’s Guide to see how leading teams are operationalizing this shift.

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 

Security programs now find more vulnerabilities than they can fix, and remediation hasn’t kept pace with how fast teams ship code. AI-generated code has made that gap worse, adding volume and complexity faster than security processes have adapted. 

Coverage has expanded, scanning is continuous, and visibility is no longer the bottleneck – but the ability to act on that visibility at scale hasn’t kept up. Backlogs grow, MTTR stays stubbornly high, and the same classes of vulnerabilities reappear across releases, even as detection improves. 

The gap isn’t that security teams lack maturity. It’s that AppSec was never built to operate at this scale. 

Detection Has Scaled. Execution Has Not. 

A growing share of organizations now acknowledge shipping software with known vulnerabilities to keep delivery moving But the pace of exploitation is accelerating at the same time. Research shows that the average time to exploit newly disclosed vulnerabilities has dropped dramatically in recent years, with attackers increasingly weaponizing vulnerabilities within days of disclosure and sometimes within hours. In 2025, nearly one-third of known exploited vulnerabilities were exploited on or before the day they were publicly disclosed, leaving organizations little time to evaluate and remediate risk.  

The distance between discovery and remediation is no longer a theoretical chasm. It is operational, measurable, and increasingly visible to boards, regulators, and customers. 

Detection Solved Visibility, Not Outcomes 

For more than a decade, AppSec investments focused on improving detection – and that initially worked. Coverage expanded across proprietary code and open-source dependencies, scanning became faster, findings became richer,  and dashboards and reporting improved. But risk outcomes did not. 

Security teams now operate in an environment where visibility is abundant, but action is constrained. Thousands of findings accumulate without clear prioritization, causing analysts to spend hours validating reachability and exploitability. At the same time, developers receive findings without enough context to determine what actually matters. Different teams end up making different decisions on identical issues and the result is a system that knows more but fixes less. 

This mismatch is becoming more pronounced as AI continues to accelerate development velocity. Leaders at major software organizations have publicly stated that a significant portion of new code is now generated with AI assistance and only reviewed by engineers before release. 

More code, shipped faster, means more potential risk, and more risk requires more capacity to remediate, not just more capacity to detect. Detection surfaced the problem. It didn’t solve it.  

The Execution Gap Is the New AppSec Bottleneck 

The execution gap is not a single failure point, but the accumulation of small inefficiencies that compound at scale.  

Triage still depends on human judgment that gets repeated inconsistently across teams, with prioritization varying based on who happens to review a given finding. Fix guidance is often advisory, leaving developers to interpret and implement solutions themselves. And governance tends to exist in policy documents instead of the workflows where decisions are actually made. Individually, these issues are manageable. At AI-scale, they become systemic, thereby compounding AppSec challenges, not because teams lack tools, but because the system connecting detection to action is inconsistent. When execution varies, risk becomes unpredictable and auditability degrades. When workflows depend on manual interpretation, service-level commitments become unenforceable. 

 What looks like a technical problem is, at its core, actually an operational one. 

The Pull Request Is the Only Place Execution Can Scale

For years, AppSec findings have flowed into tickets, dashboards, and reports – but that’s not where fix decisions get made.  

Execution happens in the pull request, where code is reviewed, discussed, approved, and merged. It is where context exists, accountability is enforced, and decisions are recorded by default. Pull requests can be configured to block merges until required checks pass, including security scanning results.  

In practice, this means remediation decisions and risk acceptance already occur in the pull request workflow, whether security teams formally recognize it or not. So why are security decisions still being made outside of this workflow? 

From Detection to Decision Infrastructure 

Modern AppSec needs a system that can turn findings into decisions. Not every vulnerability is exploitable; some represent real, reachable risk, others are false positives, and others fall within acceptable risk thresholds depending on context. Today, this distinction is made manually and inconsistently.

Decision infrastructure changes that. It classifies findings with reasoning, distinguishes between what must be fixed and what can be deprioritized, and surfaces those decisions directly in the pull request. It enables guided, reviewable remediation that is aligned with how the application actually works.

The industry has largely moved toward context-driven prioritization, with modern vulnerability management frameworks emphasizing exploitability and real-world impact over severity scores alone. But translating detection signals into actionable risk decisions requires decision infrastructure, and without it, the value of detection is incomplete.

Where Triage and Remediation Actually Happen 

Modern AppSec programs are beginning to embed agentic workflows directly in the pull request, delivering security decisions and fixes where code is actually reviewed and merged. Checkmarx One is built on this model. Triage Assist addresses the first execution bottleneck: deciding what requires immediate action. It evaluates findings using contextual analysis to determine whether a vulnerability is reachable, exploitable, and relevant within the application environment. Instead of presenting developers with raw scan output, it produces decision-ready outcomes that identify which issues must be fixed, deferred, and or represent acceptable risk under policy. 

This shift replaces manual triage queues with consistent, evidence-based decision logic that can be applied across repositories, teams, and applications. Decisions become standardized, rationale becomes visible and governance becomes enforceable. 

Remediation Assist addresses the second execution bottleneck: turning decisions into completed work. Once an issue is identified as requiring action, remediation guidance is delivered directly in the pull request as a reviewable code change that aligns with the application’s frameworks and dependencies. Developers evaluate the proposed fix using their existing review process, preserving accountability and control while accelerating resolution. Human approval remains mandatory, but developers don’t need to start from scratch when addressing security issues. The path from detection to remediation becomes shorter, more predictable, and easier to govern. 

Together, these capabilities transform the pull request into a true execution layer for application security. Risk decisions are made where code changes occur, fixes are delivered where developers work, and evidence is recorded where auditors expect it.  

And this approach scales. 

Why Governance Must Be Embedded, Not Enforced Later 

When governance exists outside the workflow, it is optional by default. It relies on teams remembering to follow it, interpreting it correctly, and applying it consistently. At scale, that approach breaks down. 

But when governance is embedded in execution, it becomes part of how work gets done. This principle is increasingly reflected in secure software development standards. Frameworks such as the NIST Secure Software Development Framework emphasize the importance of maintaining evidence and artifacts that demonstrate how security decisions were made and implemented throughout the development lifecycle. 

That requirement changes what AppSec governance actually means.  Policy alone isn’t sufficient; what matters is documented execution that preserves human oversight, where prioritization criteria are applied consistently, remediation is scoped and controlled, and decisions are captured automatically without additional administrative overhead. This is the difference between policy and control. Triage and remediation capabilities built directly into development workflows don’t replace decision-making, they structure it, bringing prioritization, reasoning, and fix guidance into the pull request where decisions are already happening. The result is governed execution, not autonomous remediation.

What Changes When Execution Is Operationalized 

When execution is built into the workflow, the system begins to behave differently. 

Manual triage effort drops because classification is no longer repeated across teams. Time to decision shrinks because context and reasoning are already available. Remediation becomes more consistent because developers are not guessing what matters or how to fix it. Risk acceptance becomes explicit, not implied. Auditability improves because decisions are captured as part of normal development activity.  

Perhaps most importantly, the relationship between security and engineering changes. When developers receive clear, contextualized guidance in the pull request, security stops being perceived as noise and starts being seen as actionable input, reducing friction. The conversation shifts from asking why a finding exists to deciding what action should be taken. 

This shift is increasingly necessary as development complexity grows. Software supply chain risk, third-party dependencies, and AI-assisted development are expanding the attack surface faster than traditional workflows can keep pace.

Recent reporting shows that most organizations have experienced supply chain attacks within the past year, reinforcing the need for consistent, scalable remediation processes.  By adopting this approach, AppSec can scale effectively without requiring a proportional increase in headcount. 

The Necessary Shift to Agentic AppSec 

Detection is table stakes in 2026. The organizations that optimize detection alone will continue to generate more findings than they can act on. Backlogs will grow and the gap between visibility and execution will widen. Security teams will remain overwhelmed, and risk decisions will remain inconsistent.  

The organizations that operationalize execution will close that gap. They will make decisions where work happens. They will standardize how those decisions are made. They will embed governance into the workflow instead of enforcing it after the fact. And they will measure success not by how much they find, but by how much they fix.  

This shift is defining modern, agentic application security. 

Read the next article: Attackability: Why Context, Not Reachability, Should Drive Remediation

Learn how modern AppSec teams prioritize vulnerabilities based on reachability, exploitability, and real-world impact to reduce noise and focus remediation where it matters most. 

But reachability is not exploitability. A function can be reachable and still pose no practical risk if it sits behind authentication, processes only trusted inputs, or is mitigated by runtime controls. Reachability confirms that code can run, not that an attacker can abuse it. 

Modern software development requires more than execution analysis. 

Checkmarx Triage Agent addresses this head on with Attackability: AI-driven triage that traces attacker-controlled inputs from real ingress points to potential impact and verifies which controls prevent exploitation – and which do not.  

The result is triage based on demonstrated exploitability, not theoretical reachability. 

What Reachability Actually Tells You 

Most SCA tools define reachability at the function level: is there a path from your code to the vulnerable function? If yes, the finding is flagged as reachable. If not, it’s deprioritized. 

That’s useful, but it’s also incomplete. Here’s what reachability doesn’t tell you: 

• Whether the input reaching that function is attacker-controlled, or only comes from trusted internal sources 
• Whether there’s a real ingress point (a public API, a webhook, a file upload) that a real attacker could use 
• Whether required preconditions exist, like a specific protocol behavior or a privileged network position 
• Whether controls on the path, such as a safe parser, an authentication check, or an allowlist, already break the exploit chain 
• What the actual impact would be: RCE, data exposure, privilege escalation, or something else

A finding can be technically reachable yet completely unexploitable in production. When that happens, engineering time is wasted for no reason, and real risk competes for attention. 

Security teams don’t need to know “can this function run?” they need to know “can an attacker exploit this in our application, given our ingress points, our controls, and our runtime environment?” 

That’s the difference between reachability and attackability.  

How Attackability Works 

Checkmarx Triage Assist introduces Attackability: AI-driven triage that traces attacker-controlled input from real ingress points to potential impact, and validates which controls prevent exploitation and which do not. 

Attackability follows a consistent five-step flow regardless of the scanner type: 

1. Identify the vulnerable capability and candidate sink. Confirm what the vulnerable library, pattern, or API surface is, and form an initial hypothesis about how exploitation would occur. 
2. Prove or disprove a real execution path. Trace whether the vulnerable code path is reachable in the repository, including direct calls, indirect framework behavior, and configuration-driven invocation. 
3. Validate attacker control and real ingress. Identify how data enters the system (API endpoints, file uploads, queues, webhooks, scheduled jobs) and whether an external attacker can actually influence the data that reaches the sink. 
4. Validate controls and preconditions. Check whether security controls apply on the relevant path: safe parsing, allowlists, auth boundaries, sanitization, runtime hardening. Document any required preconditions, such as a MITM position or specific deployment settings. 
5. Conclude exploitability and explain impact. Give a clear verdict (exploitable, not exploitable, or risk accepted with rationale), state the concrete impact, and provide a minimal-disruption remediation

This moves the conversation from “is this reachable?” to “is this exploitable?” 

Not Just for SCA 

Attackability isn’t limited to dependency finding; it applies the same reasoning across most scanner types. 

For SAST findings, it connects a detected code pattern to a real exploit chain by asking whether there’s a genuinely attacker-controlled source, whether the data flow reaches a dangerous sink, and whether controls on the path already prevent exploitation. A tainted data flow that never crosses an authentication boundary, or that’s constrained by an allowlist, can be reachable in code without being attackable in production. 

For IaC and cloud misconfigurations, it evaluates whether a configuration issue is externally accessible and whether it creates a realistic path to impact, factoring in exposure surfaces, identity controls, and network controls. 

For container findings, it assesses whether a vulnerable package is used at runtime, whether the container runs with elevated privileges, and whether the affected component is exposed through a reachable service. 

For secrets detection, it evaluates whether the credential is valid, scoped, and exposed in a way an attacker can actually leverage, factoring in repository visibility, rotation state, and downstream blast radius. 

What Makes the Output Credible 

The Attackability data is useful precisely because it’s verifiable. It includes concrete code references showing how the library or sink is used, a path narrative describing the chain from ingress to sink to impact (including where the chain breaks if the finding isn’t exploitable), explicit control validation, and a precise impact statement. 

This matters more than triage speed. It means developers can see exactly how the issue is triggered and what minimal change breaks the chain. It means risk acceptance decisions are documented with evidence, so security and engineering teams are aligning on facts (not assumptions).  

Reachability Is Just a Starting Point 

Reachability made vulnerability data more relevant. But reachability is not enough. 

Checkmarx Triage Assist’s Attackability adds attacker context, environmental context, and control validation, turning a reachability result into something a team can actually make a decision on. 

Ready to go deeper? Read the Agentic AI Buyer’s Guide to understand what separates decision-grade triage from theoretical analysis or watch the Checkmarx Triage Assist demo video to see Attackability in action.

Most DAST tools were designed for a world where release cycles were measured in months and penetration testing happened once a year. That model made sense when development moved slowly enough for episodic security reviews to provide meaningful coverage.  

Then AI accelerated everything, with AI coding assistants compressing weeks of work into hours. 

The gap between how fast applications are being built and how quickly they can be validated is exactly where risk lives. Runtime validation has moved from a nice-to-have to a foundational part of any serious application security program.  

The question is no longer whether to implement DAST. It is whether your DAST can keep pace with how fast your teams are building. 

Checkmarx has been investing and adapting in runtime security since 2023, well before AI-driven development made it a market-wide priority. So, when AI fundamentally changed the pace of software development, we didn’t need to retrofit our approach – because we were already building for this moment. 

The result is the next generation of Checkmarx DAST: runtime security designed to move at AI speed. 

Why Traditional DAST Can’t Keep Pace 

Legacy DAST often depends on heavy infrastructure setup. Scanning internal applications can require firewall changes, VPN access, security exceptions, or container deployments. These dependencies introduce approval cycles and coordination overhead that simply don’t align with applications being built in days or hours.  That model may work for annual testing, but it breaks down completely when security needs to run continuously in your CI/CD pipeline. 

Configuration adds another layer of friction. Authentication scripting, scan tuning, and policy setup frequently require specialized expertise. When onboarding takes longer than development itself, coverage gaps become inevitable. 

Even when scanning runs successfully, context is often fragmented. If SAST and DAST operate in separate systems, teams must manually reconcile findings, deduplicate issues, and correlate risk. That overhead slows remediation and reduces the practical value of runtime testing. 

In short, traditional DAST wasn’t built for continuous, developer-driven workflows. It was built for episodic pen testing. And in the AI era, this security creates exposure. 

Runtime Validation Is Now Foundational 

Runtime testing has become a core component of modern application security programs. 

In fact, according to the Future of AppSec report, DAST adoption increased 24% year over year, with 47% of organizations now deploying DAST – up from 38% the previous year. The reason is clear: static analysis alone isn’t enough to secure dynamic, API-driven, AI-assisted applications. 

Many vulnerabilities, such as business logic flaws, authentication weaknesses, and configuration errors only emerge when applications are running. So, validating behavior in live environments is no longer optional; it’s essential. 

The conversation has shifted from whether to implement DAST to how to implement it effectively without slowing development. 

Why Runtime Validation Matters in the AI Era 

AI-generated code increases productivity, but it also introduces new risks. Large language models (LLMs) generate functional code, yet they lack full business context and architectural awareness. At higher velocity, human review becomes more constrained. 

SAST remains critical for identifying vulnerabilities in source code before deployment. But it does not verify how an application behaves once it is running, especially in environments with complex authentication, APIs, client-side logic, and layered infrastructure. 

DAST provides that validation. 

By simulating real-world attacker behavior against live applications, it identifies issues that only appear under real operating conditions. 

Static analysis shows you what the code is. Runtime validation and DAST show you how it behaves. Modern application security requires both. 

How Does Checkmarx DAST Solve This? 

Complete AppSec in One Platform

Checkmarx DAST is built natively within Checkmarx One, delivering unified SAST and DAST findings in a single platform. DAST vulnerabilities are incorporated into a unified risk scoring, enabling faster triage and eliminating duplicate effort. 

It is true platform integration with shared context from code to runtime.  

Live API scanning further strengthens coverage. REST, SOAP, and gRPC endpoints are tested dynamically, and APIs discovered by both SAST and DAST are consolidated into one unified inventory. 

Production-Ready in Minutes

Traditional DAST adoption has been slowed by infrastructure and configuration barriers.  

Checkmarx DAST removes them. 

Teams can begin scanning immediately without complex network reconfiguration or custom authentication scripting through: 

• Pre-configured tunneling for secure internal application scanning
• Advanced authentication support with guided setup and MFA validation
• Pre-built templates that simplify configuration 
• Direct CI/CD integration for continuous testing

What once required weeks to set up now can be done in minutes. 

Designed for Developer Workflows 

With legacy tools, teams file networking tickets, wait for authentication scripts, and manually reconcile findings before deployment. 

With Checkmarx DAST, scanning is configured quickly, authentication is validated through guided workflows, and SAST and DAST findings appear together with correlated risk scoring. Developers receive actionable feedback directly within their pipeline and deploy confidently without introducing bottlenecks. 

Security moves with development, not against it. 

Runtime Validation You Can Trust 

Checkmarx DAST validates live applications and uncovers vulnerabilities that only emerge at runtime. Because it operates within a unified platform, findings are correlated with SAST results to reduce false positives and improve prioritization. 

The result is accurate, actionable runtime security without added friction. 

Here’s What Makes Checkmarx DAST Different

Checkmarx DAST stands apart because it is: 

• Integrated seamlessly within Checkmarx One, not acquired technology stitched together  
• Infrastructure-light, eliminating complex agent and network requirements
• Comprehensive in scope, covering full web applications and APIs
• Enterprise-grade, while remaining accessible to development teams

It is built on the proven ZAP foundation with commercial-grade enhancements. The Checkmarx-ZAP collaboration enables open-source innovation alongside enterprise reliability and scalability.  

In fact, ZAP project leaders Simon Bennetts, Rick Mitchell, and Ricardo Pereira joined Checkmarx to help build the next generation of our enterprise-grade DAST offering, while continuing to invest in the open-source ZAP project and grow its global community. 

Getting Started 

Existing Checkmarx customers: Professional and Enterprise plans include DAST. Essentials customers can add DAST to their existing subscription.  

New customers: See the unified Checkmarx One platform in action and discover how DAST integrates seamlessly with SAST for complete code-to-runtime security. 

You can also tune into our DAST webinar to see it in action here. 

What’s Next 

The shift is already underway. According to the Future of AppSec report, DAST adoption grew 24% year over year – not because security teams suddenly discovered runtime testing, but because the old model of annual pen tests and periodic scans no longer provide meaningful coverage. Teams building with AI-generated codeneed security that moves on the same timeline. 

Checkmarx DAST is built for that reality: unified with SAST on a single platform, deployable in minutes, and designed to work within developer workflows rather than around them. 

If you are an existing Checkmarx customer, DAST is already included in Professional and Enterprise plans. Essentials customers can add it to their current subscription and new customers can see it in action at our upcoming webinar. 

On March 23, 2026, Checkmarx identified a cybersecurity supply chain incident affecting certain Checkmarx‑related developer artefacts distributed via third‑party channels.

This post contains a structured overview of the incident and the steps we have taken to date, as well as additional resources to support our clients and team members.

What Happened

On March 23, 2026, Checkmarx was the target of a cybersecurity supply chain incident which affected two specific plugins distributed via the OpenVSX marketplace and two of our GitHub Actions workflows.

OpenVSX Plugins

On March 23, 2026, at approximately 02:53 UTC, malicious versions of two plugins were published to the OpenVSX registry.

Only organizations that downloaded the following artifacts from OpenVSX on 23 March, 2026 between 02:53 UTC and 15:41 UTC and ran it are potentially impacted by this incident.

• ast-results-2.53.0.vsix
• cx-dev-assist-1.7.0.vsix

The affected plug-ins are no longer available and all older GitHub versions have been permanently removed.

Plugins downloaded from the VS Code Marketplace were not affected.

Recommended actions

The following guidance is provided as a precautionary measure to support customer‑led assessments and remediation, where relevant to their environments.

If a client downloaded and ran either of the above extensions from the Open VSX registry, their organization may be affected.

If the client organization may have been affected, we strongly recommend taking the following steps as soon as possible.

1. Remove Malicious Components

• Uninstall the following VSIX extensions from all environments:
  • checkmarx.ast-results-2.53.0.vsix     
  • checkmarx.cx-dev-assist-1.7.0.vsix
• use ast-github-action – v2.3.33 only
• use kics-github-action – v2.1.20 only
• Ensure they are removed from:
  • All developer machines
  • All VSCode profiles and environments

2. Revoke and Rotate Credentials

GitHub Actions

An issue was also identified in KICS and AST GitHub Action on March 23, 2026. The attacker injected malicious payloads into the following GitHub Actions workflows which were available between 12:58 and 16:50 UTC:

• checkmarx/ast-github-action
• checkmarx/kics-github-action

Maintainers revoked the affected tags, securing access, and preventing unauthorized changes.

All GitHub Actions have been updated to the following latest verified releases, and all older versions have been permanently deleted from the organization’s repositories:

• ast-github-action — v2.3.33 (released March 23, 2026)
• kics-github-action — v2.1.20 (released March 23, 2026)

Both versions are the only ones available in our repos. All pipelines must reference these versions exclusively or newer.

Recommended actions

If you downloaded the malicious versions of either plugin (ast-results-2.53.0.vsix or cx-dev-assist-1.7.0.vsix) from OpenVSX during the affected period, we strongly recommend following these precautionary steps:

• Revoke and rotate all secrets and credentials accessible to CI runners during the affected period, including GitHub Personal Access Tokens (PATs), cloud service credentials, and repository or organization-level secrets.
• Review GitHub Actions runs, search for suspicious indicators such as references to tpcp.tar.gz, aquasecurity, or checkmarx.zone, and check for unexpected repositories like tpcp-docs. In case you spot any occurrences of these, please remove them or contact the Checkmarx Support for guidance.
• Revoke access to the following tokens, and issue new ones:
  • GitHub credentials
  • Microsoft Azure access
  • Google Cloud (GCP) access
  • AWS access
  • Kubernetes service account tokens and kubeconfigs
  • SSH keys
  • Docker registry credentials
  • Block Malicious Infrastructure by restricting access to checkmarx[.]zone and review historical network traffic for any communication with this domain
• Review logs and systems for GitHub activity such as unexpected API usage, suspicious repositories or artifacts such as docs-tpcp and/or tpcp.tar.gz, unauthorized releases or CI-triggered changes
• For any revoked token, key or credentials from previous stages:
  • Review related activity within exposure time frame, to validate no lateral movement took place
  • Monitor for any future attempts to use these credentials to identify ongoing attempts to attack infrastructure

Containment & Remediation

Upon identification of the issue, we took immediate steps to contain and remediate the incident. We removed the unauthorized code, pinned our workflows to safe verified commit SHAs, revoked and rotated relevant credentials, blocked outbound access to the attacker-controlled domain, and reviewed our environments for any signs of further compromise.

Investigation Status

We have commenced a formal investigation and engaged external forensic specialists to support that work. This investigation is ongoing and includes investigating the behaviour and objectives of the malicious code.

Available information indicates that the primary functionality of the code was focused on the attempted collection and exfiltration of credentials and secrets from affected environments, without evidence to date that such data was successfully exfiltrated from any customer environment.

Based on the investigation to date, and subject to the evidential limitations described below, we recommend continued vigilance and that you notify us promptly if you become aware of any suspicious activity.

While the investigation is ongoing, to date, we do not have evidence indicating that the incident resulted in unauthorised access to customer data or systems, that data held by Checkmarx has been accessed, nor can we yet confirm that any particular customer environment was compromised.

It is important to note that because the affected artefacts execute within customer‑controlled environments, confirmation of whether a particular customer was impacted depends on an assessment of those environments, rather than on telemetry held by Checkmarx. Those CI/CD pipelines and developer workstations are customer‑controlled environments, and Checkmarx does not have independent visibility into their execution or logs.

Our Commitment to You

If you have any questions or need assistance assessing client exposure, please reach out to our security team at infosec@checkmarx.com. Additionally, we have published detailed assessment and remediation guidance, including indicators of compromise, version information and recommended next steps for customers on our support portal.  

Protecting the security and privacy of our clients and team members is a responsibility we hold to the highest standard. As part of our commitment to transparency, we will provide updates as appropriate and as our investigation progresses.

With GenAI taking over almost everything we do, a great emerging use case is “vibe coding.” The formal defintion of vibe coding is: “an AI-dependent programming technique where a person describes a problem in a few sentences as a prompt to a large language model (LLM) tuned for coding.”

Basically it allows anyone to create applications without knowing how to code a single line. It has the potential to help accelerate velocity, untangle previous bottlenecks, and reduce the need to have every request go to R&D – allowing R&D to focus more on complex business logic.

What Is Vibe Coding?

Vibe coding describes a style of AI-assisted development where a user prompts an LLM or coding assistant to generate code, refine logic, and iterate quickly toward a working outcome. It lowers the barrier to entry, increases development speed, and helps teams prototype and ship faster.

But the same acceleration that makes vibe coding attractive also creates new security pressure. AI can introduce insecure logic, unsafe dependencies, weak access controls, or exposed secrets at a pace that quickly outstrips manual review. In other words, the more software is created at machine speed, the more important vibe coding security becomes.

For engineering leaders, the opportunity is clear: faster delivery, fewer bottlenecks, and more experimentation. For security leaders, the challenge is equally clear: less visibility, more change volume, and a wider software supply chain to govern. The real question is not whether teams should use AI-assisted development. It is how to make it secure at scale.

The Security Risks of Vibe Coding

Vibe coding security risks are not theoretical. When AI generates code without strong guardrails, teams can inherit the same classes of issues security teams already know well, only faster and at greater scale.

1. Insecure AI-generated code

AI coding tools can reproduce insecure patterns from training data or generate flawed logic under pressure to produce fast results. That can lead to issues such as injection flaws, weak authentication, broken authorization, or unsafe handling of sensitive data.

2. Vulnerable and unverified dependencies

AI-generated code often introduces open-source packages, frameworks, and libraries automatically. Without validation, teams can inherit vulnerable, malicious, or simply inappropriate dependencies that expand software supply chain risk.

3. Hard-coded secrets and unsafe configuration

Generated code may expose API keys, tokens, credentials, or permissive defaults. These issues are easy to miss during rapid iteration and can become high-impact weaknesses once merged or deployed.

4. Over-trust in AI output

One of the biggest vibe coding security issues is not just bad code. It is uncritical acceptance of AI-generated code. If teams assume generated output is production-ready, vulnerabilities can move downstream without meaningful validation.

5. Reduced auditability and governance

As AI tools generate more code and suggest more changes, it becomes harder to explain how decisions were made, what dependencies were introduced, and whether policy requirements were followed. That creates friction for governance, compliance, and risk ownership.

6. More change volume than traditional security processes can absorb

AI-assisted development increases code volume, dependency churn, and pull request activity. Traditional detection-only workflows struggle to keep up, which means backlogs grow even when teams are trying to move faster.

Why Traditional AppSec Struggles With Vibe Coding Security

Most security programs were built for a world where code moved at human speed. Vibe coding changes that. AI can generate, modify, and refactor code continuously, which means security teams are no longer dealing with occasional bursts of change. They are dealing with a new operating model.

That is why securing vibe coding requires more than periodic scanning or post-hoc review. Security has to work in parallel with creation. Teams need visibility into AI-generated and human-written code, the dependencies AI introduces, and the real business risk associated with each issue. The goal is not to slow innovation down. The goal is to make trust scale as fast as development does.

How to Improve Vibe Coding Security in Practice

Organizations do not need to choose between AI-driven velocity and secure development. They need guardrails that fit the way modern teams actually build.

Treat AI-generated code like any other untrusted input

Every AI-generated change should be validated before merge. Teams should review generated logic, check dependencies, and verify that security controls still hold under real usage conditions.

Add security guardrails where developers already work

Security works best when it fits naturally into the developer workflow. That means surfacing security feedback in the IDE, pull request, and CI/CD pipeline instead of forcing teams into disconnected tools and manual handoffs.

Prioritize what is truly risky

High-volume AI-assisted development can flood teams with findings. Prioritization should account for exploitability, reachability, runtime context, business impact, and policy alignment so teams can focus on what materially reduces risk.

Validate runtime behavior, not just code patterns

Static analysis matters, but so does verifying how applications behave at runtime. AI-generated code can introduce logic flaws, authentication gaps, and API weaknesses that only become visible when applications are tested under real conditions.

Govern dependencies and the AI software supply chain

Securing vibe coding also means governing the packages, frameworks, models, and other AI-related components that code generation tools introduce. Visibility and policy enforcement are essential if teams want to prevent risky components from shipping.

Preserve human oversight

AI can accelerate triage and remediation, but production-bound changes should still remain reviewable, explainable, and auditable. The strongest security programs use AI to help teams move faster while preserving control.

What Securing Vibe Coding Looks Like at Scale

As AI-assisted development becomes part of normal engineering workflow, security teams need more than isolated scanners and after-the-fact review. They need a way to secure human and AI-generated code as it is created, prioritize the issues that matter most, and keep remediation inside the workflows developers already use.

That is the shift from reactive AppSec to continuous assurance. Instead of waiting for risk to pile up, organizations can reduce exposure earlier with security controls in the IDE, richer prioritization across the platform, and governed remediation that supports developer speed without sacrificing oversight.

Secure AI-Generated Code

Protect vibe-coded applications without slowing developers down

Checkmarx Developer Assist helps teams secure human and AI-generated code in real time inside the IDE, with explainable guidance and safe remediation that keeps developers in flow.

Start 30-day Free Trial Now

Conclusion

Vibe coding is here to stay. It can unlock major gains in speed, experimentation, and developer productivity, but it also creates a faster, more complex risk surface. That makes vibe coding security a business and engineering priority, not just a coding hygiene issue.

The organizations that succeed will be the ones that secure AI-generated code without interrupting the flow of development. That means combining visibility, prioritization, runtime validation, supply chain governance, and developer-first guardrails so teams can move quickly with confidence.

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

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

And that’s exactly the problem. 

When Confidence Outpaces Security 

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

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

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

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

More Code, Same Security Team

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

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

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

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

Development Is Now Human + AI 

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

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

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

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

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

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

Security Has To Evolve 

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

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

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

Meanwhile, AI is introducing new threat vectors: 

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

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

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

From Backlog to Automation 

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

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

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

Securing at the Speed of Confidence 

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

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

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

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

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

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

Not because it replaces traditional application security. 

Not because it suddenly makes AI-generated code safe. 

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

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

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

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

A New Way To Think About Detection 

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

But the philosophies differ. 

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

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

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

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

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

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

In simple terms: 

Claude Code Security is deep and novel. 

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

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

Scope Matters in the AI Era 

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

It lives in: 

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

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

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

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

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

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

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

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

The difference is operational scale and ecosystem integration.

Enterprise Readiness Is Not an Afterthought 

Claude Code Security is currently in limited research preview. 

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

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

Innovation is exciting, but operational maturity is essential. 

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

This Isn’t Replacement — It’s Evolution 

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

The more honest framing is this: 

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

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

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

The Bigger Opportunity 

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

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

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

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

The future of security isn’t defensive. 

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

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

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

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

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

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

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

The Noise Problem: Volume vs. Actionable Insights 

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

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

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

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

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

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

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

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

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

Contextual risk scoring takes the following into account:

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

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

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

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

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

Correlation Between Scanners: Full Context Requires Multiple Signals Working Together

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

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

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

Let’s look at an example:

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

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

Without it, everything becomes noise.

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

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

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

Turning Contextual Insights Into Actionable Remediation 

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

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

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

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

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