New Development: GitHub Repository 

We are writing to inform you of a new development in the ongoing Checkmarx supply chain security incident. 

Our investigation, conducted with support from a leading third-party forensic firm, indicates that a cybercriminal group has published data related to Checkmarx to the dark web. Based on current evidence, we believe this data originated from Checkmarx’s GitHub repository, and that access to that repository was facilitated through the initial supply chain attack of March 23, 2026. 

Checkmarx’s GitHub repository is maintained separately from our customer production environment. As standard practice, we do not store customer data in our GitHub repository. Our forensic investigation is ongoing and we are actively working to verify the nature and scope of the posted data. 

As part of our immediate response, we have locked down access to the affected GitHub repository while the investigation continues. 

If we determine that customer information was involved in this incident, we will notify customers and all relevant parties immediately. 

We expect to share a more detailed update within 24 hours. 

Questions and Support 

If you have questions about this incident or need assistance assessing your environment, please open a case via the Support Portal.

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.

What Happened

On April 22, we communicated with customers about a new development in the supply chain security incident that our team is actively investigating and addressing. We deeply value the trust you place in Checkmarx and are committed to keeping our customers informed as we continue to respond.

As part of our immediate response, we retained outside experts and are working around the clock to get to the bottom of this as quickly as possible. In the interim, we are sharing key findings to-date and recommended actions for our customers to take.

Key Findings

Notably, our investigation thus far indicates that the malicious artifacts did not override previously published, known safe versions. Customers using versions or SHAs published prior to the affected timeframes are not affected.

Affected Artifacts

The following artifacts have been identified as potentially affected:

1. Checkmarx public DockerHub KICS image – https://hub.docker.com/r/checkmarx/kics
   1. Malicious tags: v2.1.20-debian, v2.1.21-debian, debian, v2.1.21, v2.1.20, alpine, v2.1.20, v2.1.21, latest
   2. Malicious SHAs: sha256:222e6bfed0f3b, sha256:9183908decd0f, sha256:a6871deb0480e, sha256:ff7b0f114f87c, sha256:1b01a97753780, sha256:2588a44890263, sha256:54f8a56bf1f71, sha256:d186161ae8e33, sha256:415610a42c5b5, sha256:e35bc6afc4857, sha256:a0d9366f6f016, sha256:903eef3c05f6e, sha256:26e8e9c5e53c9, sha256:7391b531a07fc, sha256:4c963fa00e585
   3. Timeframe: from 2026-04-22 12:31:35.883 UTC to 2026-04-22 12:59:46.562 UTC
2. Checkmarx public ast-github-action – https://github.com/checkmarx/ast-github-action
   1. Malicious tags: 2.3.35
   2. Timeframe: from 2026-04-22 14:17:59 UTC to 2026-04-22 15:41:31 UTC
3. Checkmarx VS Code extension
   1. Microsoft marketplace: https://marketplace.visualstudio.com/items?itemName=checkmarx.ast-results
   2. Open VSX marketplace: https://open-vsx.org/extension/checkmarx/ast-results
   3. Malicious tags: 2.63, 2.66
   4. Timeframe – Microsoft marketplace: From 2026-04-22 13:06:00 UTC to 2026-04-22 17:48:00 UTC
      Timeframe – Open-VSX marketplace: From 2026-04-22 13:06:00 UTC to 2026-04-22 21:20:00 UTC
4. Checkmarx Developer Assist extension
   1. Microsoft marketplace: https://marketplace.visualstudio.com/items?itemName=checkmarx.cx-dev-assist
   2. Open VSX marketplace: https://open-vsx.org/extension/checkmarx/cx-dev-assist
   3. Malicious tags: 1.17, 1.19
   4. Timeframe – Microsoft marketplace: From 2026-04-22 13:06:00 UTC to 2026-04-22 17:48:00 UTC
      Timeframe – Open-VSX marketplace: From 2026-04-22 13:06:00 UTC to 2026-04-22 21:20:00 UTC

Actions We’ve Taken

To date, in response to this development we have:

1. Removed the malicious artifacts;
2. Revoked and rotated exposed credentials;
3. Blocked outbound access to attacker-controlled infrastructure;
4. Reviewed our environments for any signs of further compromise.
5. Initiated a forensic investigation with the assistance of an independent, third-party forensic firm.

Recommended Actions

We recommend that our customers take the following steps as soon as possible:

1. Block access to these domains and IP addresses:
   1. checkmarx.cx => 91[.]195[.]240[.]123
   2. audit.checkmarx.cx => 94[.]154[.]172[.]43
2. Use pinned SHAs and review or disable auto-update settings in IDE marketplaces
3. Rotate secrets and credentials if a compromise is suspected or detected
   1. DockerHub KICS image: latest, v2.1.20, alpine, Debian
   2. Checkmarx ast-github-action: v2.3.36
   3. Checkmarx VS Code extensions: v2.67.0
   4. Checkmarx Developer Assist extension: v1.18.0

Next Steps

This is an ongoing investigation. Please continue to monitor the Checkmarx Community Incident Page for more information.

If you have questions about this development, please open a case via the Support Portal.

We are grateful for your continued support and patience as we work to address this incident.

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  

On April 7, 2026, Anthropic revealed its new AI Model named “Mythos” (currently in private mode) that aims to secure software in the AI era.  

Anthropic claims that AI has reached a turning point in cybersecurity. With the expected release of Mythos, AI models are poised to be capable of identifying and exploiting software vulnerabilities at a level that rivals and, in many cases, surpasses top human experts. Mythos has already uncovered thousands of high-severity vulnerabilities across major operating systems and browsers, signaling rapid acceleration in both capability and risk.  

Quickly in the wake of the Mythos announcement, Anthropic launched a coalition, named Project “Glasswing” after the clear-winged, tropical butterfly. The project, which includes over 40 major technology organizations such as Apple, Google, Microsoft, and Nvidia, is critical to redirecting this vast new LLM power toward defense rather than exploitation. 

A recent example shared by Anthropic highlights the leap in capability: while the Opus 4.6 model was able to generate a working JavaScript shell exploit for a Firefox 147 vulnerability only two times out of hundreds of attempts, Mythos achieved a dramatically higher success rate, producing a working exploit in 181 cases. That’s not a marginal gain; it’s a fundamentally different level of capability. 

In this article, we will provide a useful guide to allow you to better understand the announcement, what it means for application security leaders as well as some recommendations that you can learn from as you are moving forward with your AI journey.

Why did Anthropic Make this Announcement? And, Why Now?

For years, many software vulnerabilities have gone undetected because identifying and exploiting them requires highly specialized expertise. With the rise of advanced AI models, the barriers due to cost, effort, and skill have dropped dramatically, making both discovery and exploitation accessible, fast, and scalable. As you can see in Checkmarx’s own research below, the time to exploit a security vulnerability decreases dramatically with the power and adoption of AI. 

Vulnerabilities that took weeks, months, or even years to exploit until recently, can now be weaponized in a matter of minutes. This defines an entirely new reality for application security, and it needs to be top priority for any head of security, head of engineering, and the entire executive team.  

According to our annual Future of Application Security report, over 81% of organizations knowingly ship vulnerable code driven by overwhelming noise, uncontextualized backlogs, and limited resources. This is just one of several AI-driven challenges AppSec leaders must now confront. In the next section, we break down the most critical ones. 

For additional perspective on how security is evolving with advances like Mythos, watch this industry discussion: 

The Challenges of Adopting only AI Model-Based Security Solutions

As organizations accelerate toward AI-native development, the security landscape is shifting just as rapidly, and not always in predictable ways. New AI models are demonstrating an unprecedented ability to uncover vulnerabilities in existing codebases, including long-standing flaws that have gone undetected for years. At the same time, these models are dramatically lowering the barrier to exploitation, enabling faster weaponization of both known and unknown vulnerabilities. This creates a dual challenge: while discovery improves, the volume and velocity of risk increase just as quickly. 

With that in mind, here are some of the key security challenges that are emerging in agentic development, that enterprises must acknowledge: 

• New models are uncovering large volumes of zero-days in older code. 

• AI Speeds weaponization of vulnerabilities: Known & unknown. 

• A great reference to learn from is the recent article around the “jagged frontier” of AI security. 

• As much as 45% of AI-generated code may be insecure.  

• LLMs are missing vulnerabilities; coverage is incomplete. 

• Models are trained from different sources, thus producing inconsistent results from one LLM to another. 

• AI Models are not comprehensive enough and are lacking context. 

Deterministic & Probabilistic AppSec for Known & Unknown Vulnerabilities

As the software landscape evolves into an agentic one and LLMs continue to advance, it’s critical to recognize that AI-driven security analysis alone is not sufficient. Models that generate, and flag issues based on probabilistic reasoning must operate alongside deterministic systems grounded in real-world context, customer environments, true exploitability, policy enforcement, auditability, and full visibility. At enterprise scale, this also means supporting thousands of repositories, distributed teams, and highly interconnected systems. 

As highlighted in Tomasz Tunguz’s “Jagged Frontier of AI Security” article above, AI capabilities are not linear; they are inconsistent and context dependent. While models like Mythos can demonstrate breakthrough performance in discovering and exploiting unknown vulnerabilities, similar outcomes can often be reproduced by smaller models when given the right inputs. At the same time, known vulnerabilities, often buried in backlogs and lacking prioritization, remain a significant and weaponizable risk in the age of AI. 

In this uneven reality, some vulnerabilities are identified with high precision, while others are missed entirely. This leads to false confidence, inconsistent outputs, and critical gaps in risk coverage. If detection isn’t consistent, it isn’t trustworthy. 

This is where a hybrid model becomes essential – AI with its probabilistic reasoning provides speed and scale, but it must be complemented by a deterministic security layer that validates findings based on context and real exploitability, and this is where we are focused. Brought together, probabilistic and deterministic approaches establish a new standard for agentic application security, one that delivers high-fidelity, actionable results at scale. 

Making the case for Agentic Triage & Remediation

We’ve established that combining LLM-driven security which uncovers a wide range of unknown vulnerabilities with an already unmanageable backlog of known issues (leaving 81% of organizations exposed) requires a hybrid approach that blends probabilistic and deterministic analysis. But that alone is not enough. 

The sheer volume of vulnerabilities now demands agentic triage and remediation. Manual processes cannot keep up; they fail to provide context, prioritize effectively, or resolve risk with confidence at scale. 

This is where AI agents become critical. By automatically performing intelligent triage to eliminate noise and prioritize truly exploitable risk, and by driving fast, automated remediation, they bring together reasoning and precision. The result is security that is not only scalable, but truly actionable in an AI-native development environment. 

Final Thoughts & Recommendations

The Mythos announcement and the formation of Project Glasswing mark a major milestone in AI-driven security, but they are not, and cannot be, a standalone solution. As outlined above, AI models both amplify existing risks and expose new ones, creating challenges that require a broader, more integrated approach. 

To build a truly enterprise-grade, trustworthy AI security program, we recommend the following steps: 

• Hybrid AppSec Model 
  Combine deterministic precision with probabilistic AI to cover both known and unknown risk. 

• Agentic Triage & Remediation 
  Leverage AI agents to scale context-aware triage and accelerate remediation. 

• Shift Left to the Source 
  Identify and fix AI-generated vulnerabilities at code creation, before they reach production. 

Learn more about Checkmarx’s agentic agents: Developer Assist and Triage and Remediation Assist.

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.