Checkmarx’s hybrid model removes that tradeoff.

A deterministic detection engine and an AI reasoning engine analyze the code in parallel, and a third engine, the Findings Analysis Engine (FAE), reconciles their output into one verified result. It is precise, broad, and repeatable every time.

But the hybrid model is only the start.

Checkmarx Fusion, now in Early Access for SAST within Checkmarx One, adds a new layer on top of that hybrid foundation. Its Multi-Model AI Engine runs several curated frontier AI models on top of the FAE’s already-reconciled results, surfacing vulnerabilities with no known rule, CVE, or signature to catch them.

Here’s how it works – and how this model finds what other scanners were never built to see.

Why a New Model Is Needed

The limitations of traditional detection are becoming more consequential as AI changes both how software is built and how quickly it can be attacked.

AI assistants are generating more code, across more languages, faster than security teams can review it. Checkmarx’s latest Future of Application Security report found that organizations where AI generates 81–100% of production code ship known vulnerabilities at 3.4 times the rate of organizations that generate only 1–20% of code.

At the same time, attackers are moving faster. Anthropic research found that a working exploit could be generated within an hour of a patch being released. A vulnerability that goes undetected may become an active risk before security teams have time to respond.

But simply adding more AI is not enough. Standalone AI scanning can be inconsistent from one run to the next, while operating frontier models at enterprise scale can create high, unpredictable token costs.

Organizations need detection that can keep pace with AI-generated code without sacrificing precision, repeatability, or operational control.

How the Hybrid Model Works

The hybrid model provides that foundation. It is made up of three engines, each serving a distinct role:

Deterministic Engine: Rules-based analysis of known vulnerability classes. Precise, explainable, and consistent from scan to scan.

AI-Based Engine: Extends coverage to languages and patterns that rules alone cannot reach, including novel logic and AI-generated code.

Findings Analysis Engine (FAE): Reconciles the output of both engines into one clean result set. False positives removed, true positives kept.

This foundation transforms what a security scan can deliver – and it’s currently powering our Next Generation SAST. But Fusion takes it even further.

Fusion’s Multi-Model AI Engine applies several curated frontier models to the hybrid model’s verified findings. Each analyzes the code from a different perspective, allowing Fusion to uncover vulnerabilities that no single rule, signature, or AI model would be likely to identify alone – including issues with no known rule, prior CVE, or existing signature.

The advanced AI models are selected and validated by Checkmarx research, and customers can choose higher- or lower-cost options based on the needs of each project. This extends AI-driven coverage while keeping scan costs predictable.

Together, the hybrid model and Fusion deliver:

• Precision without sacrificing coverage: deterministic precision and AI coverage together, not a compromise between them.
• Consistent, repeatable results: scan it twice, get the same result, on any scan type running the hybrid model. Standalone AI scanning can’t promise that.
• Less noise for teams: the Findings Analysis Engine, part of the hybrid model, strips noise before it reaches your team. Every finding traces to a rule or a verifiable signal, the same standard across every scan type.
• One unified risk view: every scan’s findings land in Checkmarx One ASPM (Risk Orchestration) next to each other, scored against the same risk model, instead of a fragmented view across separate tools.

As Erik Brown, Business Information Security Officer and AppSec Leader at Nelnet, put it: “With AI generating unprecedented amounts of code, security has to be an enabler, not a bottleneck.” He added: “The industry finally has an approach built for what AI demands.”

The Data Backs It Up

The numbers show just how much this model changes security outcomes.

The F1 score measures both precision – how many reported findings are real – and recall – how many real vulnerabilities are found. A higher score means stronger detection – that is, finding more real vulnerabilities – without burying teams in false positives.

Traditional, query-based SAST averages roughly 0.20. Next-Gen SAST, run on the hybrid model, raises that score to 0.64, more than triples the baseline. Add a Fusion scan, and it reaches 0.74 – nearly four times the industry average – with 60–70% fewer false positives than standalone AI scanning.

Teams get broader coverage with a result set they can realistically manage. Fusion improves precision and recall even more, extending that coverage into novel vulnerabilities, unseen patterns, and flaws unique to AI-generated code.

Mustapha Kebbeh, Chief Security Officer at UKG, put it this way: “The question I hear every day is no longer whether we have vulnerabilities, it’s whether we’ve discovered the ones that matter most and whether we’re fixing them fast enough. That’s exactly what Checkmarx Fusion is built to address.”

Efficient at Scale

That level of coverage only matters if it can be delivered efficiently, predictably, and securely at enterprise scale. Fusion uses a bounded, curated set of research-validated models rather than relying on open-ended frontier API calls. In practice that means:

• Predictable Cost: Higher- or lower-cost models, your choice, with no token bill that compounds across every commit.
• Model Optionality: Choose high- or low-cost models per project, without being locked to any single provider.
• Cost Optimization: Prompt, context, and harness tuning, combined with incremental scans, keep performance high and spend controlled as usage grows.
• Enterprise Scale: Incremental scanning re-scans only new and changed code, so performance improves as your codebase grows.
• Built-In Data Protection: Source code and customer data remain within your own cloud environment or tenant using Amazon Bedrock.

The hybrid model – now offered within Next-Gen SAST – remains part of standard Checkmarx licensing, while Fusion is offered as an optional, usage-based add-on that draws on Checkmarx credits.

How to Use Fusion

Here’s what running Fusion looks like inside Checkmarx One, start to finish.

1. Turn it on. Enable Checkmarx Fusion under Account Settings → AI Capabilities. From here, teams control the account-level switch, see which curated models are active, and track remaining token budget in real time.

A note on the numbers in this screenshot: the token and per-model figures are illustrative. Treat any dollar or token figure here as a preview, not a rate card.

2. Start a scan and select Checkmarx Fusion. Point Checkmarx One at a repository, file, or SBOM, then choose which scanners run. Fusion sits alongside SAST, SCA, IaC, API Security, and the rest, so enabling it is a checkbox in the same flow, not a separate tool.

3. Review results at the portfolio level. Once scans complete, risk level and total vulnerabilities roll up per project. Scanner badges show which engines contributed to each result.

4. Drill into Risk Orchestration. Every finding lands in the same Risk Orchestration view, regardless of which engine produced it. Teams can filter for Checkmarx Fusion’s LLM-based results alongside every other scanner.

5. Know what’s AI-generated. The results table labels findings as “LLM Generated Result” when AI-based analysis produced them, so nothing is a black box.

From here, findings flow into Triage Assist and Remediation Assist.

From Finding to Fix, All Within Checkmarx One

Fusion findings don’t land in a separate tool, queue, or workflow. They’re part of the unified risk picture in Checkmarx One’s Risk Orchestration, where they can be prioritized and acted on alongside findings from the rest of the platform. Fusion focuses on discovery, delivering a clean, high-fidelity finding on top of what our hybrid engines already found.

Triage and Remediation Assist takes from there. It carries eligible findings forward – from determining whether it presents a real application risk to preparing a fix. Together, this interconnected workflow can deliver:

Up to 95% faster MTTR: Attackability-based decisions and review-ready guidance cut the time from finding to fix.

65%+ fixed on the first attempt: context-aware remediation guidance gets it right without repeated back-and-forth.

Up to 60% lower operational cost: fewer handoffs and less rework between AppSec and development teams.

Governed, not autonomous: scoped rollout, eligibility criteria, and action-mode controls (diffs vs. PR) mean the agent proposes, and the developer disposes.

This is where Checkmarx Fusion’s higher fidelity pays off. Cleaner, more trustworthy findings give downstream prioritization and remediation a stronger foundation, reducing manual validation and helping teams move more risk toward resolution faster.

Zoom out and see that this handoff is part of a bigger picture of the connected security lifecycle within Checkmarx One:

• Prevent with the Assist family of agents – from Developer Assist, Triage Assist, and Remediation Assist. Developer Assist catches issues before code is even generated for a developer.
• Discover with Fusion and Next-Gen SAST, which find what got through, including zero-day and unknown-pattern vulnerabilities no rule or signature could catch alone.
• Remediate with Triage & Remediation Assist, which clears the backlog and resolves the exploitable risk that discovery surfaces, including the zero-day findings Fusion turns up.

Fusion makes sure that what gets handed off is real, so the resolution stage isn’t wasting time on noise.

See It in Your Application

Checkmarx Fusion is in Early Access, available within Checkmarx One for teams using credits. Schedule a demo to see how it works in your own environment or visit the Checkmarx Fusion solution page for more details.

Securing enterprise codebases was already challenging because most contain code written in multiple languages. AI assistants are now adding to that challenge by generating code in whichever language they determine is best for the task, whether or not your scanner can read it. TIOBE’s index now tracks more than fifty languages in active use – and they aren’t the languages you might expect. For example, Go and Haskell now rank alongside Python on some of today’s most visited sites. 

Those AI assistants write faster than people do, too. Microsoft Research clocked developers using GitHub Copilot at 55.8% faster on an identical task than developers without it. Checkmarx’s 2026 Future of Application Security survey names what that speed has done to the job: developers have moved from authoring code to editing it, supervising output instead of producing it.  

That combination – more code, written faster, across more languages – creates a security challenge most teams don’t understand and were not built to handle. This is where vulnerabilities live. 

The more production code AI generates, the more risk can slip through at scale. According to the same report, organizations where 81-100% of production code is AI-generated ship known vulnerabilities at 3.4x the rate of organizations where AI writes just 1-20%.  The issue is not just speed. AI-generated code can look correct while still carrying insecure patterns from the code it learned from, making vulnerabilities easier to miss and harder to trace. 

And, in addition, attackers are not waiting for security to catch up. Anthropic’s research on N-day exploits found that WannaCry took 59 days to weaponize after its 2017 patch, and that 16 of 25 historical vulnerabilities studied by Mandiant took a month or more to exploit. That timeline is already history. In the same research, Anthropic’s own model, Claude Mythos Preview, had a working Firefox exploit ready within an hour of Mozilla shipping the patch, 18 days before the patched browser itself even went out.  

The imbalance is clear: attackers can now move in hours, while defenders are still trying to understand code generated at AI speed, across more languages than ever. Closing that gap needs to start before the code ships. 

One Scan, Two Lenses 

Scanning code has always meant choosing a lens. A deterministic scanner looks through the lens of known rules, signatures, and patterns. It is consistent: run it twice on the same code, and you’ll get the same result. This repeatability is why auditors and compliance teams trust it. An AI-based scanner uses a different lens. It reasons through code more like a human reviewer, which helps it catch risks that do not match a known rule or signature. But that flexibility comes with less predictability: ask it the same question twice, and the answer might change. 

Neither one was ever going to be enough by itself. That is the compromise Checkmarx’s hybrid architecture refuses to make: depending on the language, either a deterministic, rules-based engine or an AI-based reasoning engine runs, and a Findings Analysis Engine (FAE) reconciles the output into one validated list. That pairing is Next-Gen SAST, built for known, N-day vulnerabilities at the highest fidelity a scanner reaches without going further. On its own, it reaches an F1 score of 0.64, up from 0.20 for basic query-based scanning, the standard approach used by traditional SAST solutions. 

One Step Further 

But known and N-day vulnerabilities are only part of the picture. The harder challenge is finding risks with no CVE, signature, or established pattern to match.  

That is where Checkmarx Fusion, currently in Early Access, adds another layer. Built on top of Checkmarx’s next generation hybrid SAST scanner, Checkmarx Fusion runs several frontier AI models, hunting for zero-day and unknown-pattern findings with no CVE or signature yet to match. Checkmarx reconciles that broader set of results back through the same rigorous validation process, producing one trusted output.  

Run together, Checkmarx SAST with Checkmarx Fusion achieves an F1 score of 0.74. The point is not to add AI just for the sake of it. The point is to give developers scan results that they can trust: precise enough to avoid false-positive noise, and broad enough to catch critical vulnerabilities that simpler scanners might miss.  

 Frontier AI models give Checkmarx Fusion a broader detection lens, surfacing complex or novel vulnerabilities that static rules and signatures alone would miss. And because AI models evolve rapidly, Checkmarx isn’t locked to any single one. The best model today may not be the best model tomorrow. So as models improve, Checkmarx swaps in whichever performs best – while the deterministic backbone, code context, and validation process remain fixed. 

Inside Checkmarx One 

A clean finding is not the same as a fixed one. Checkmarx Fusion sits as the final layer of Checkmarx SAST, and the same model is coming to other scan types, extending coverage across the full application development lifecycle so security doesn’t stop at detection. It is not the layer every team starts with. It is the layer teams reach for once standard scanner coverage is no longer enough, when getting a finding right matters as much as finding it fast. 

That need is only growing. New models keep arriving faster than security roadmaps can account for, and each one can change what attackers are able to find and exploit. Claude Mythos Preview’s hour-long path from patch to exploit showed what that looks like in practice: a working exploit within an hour of a patch being released.

A scanner built only to catch what it already knows will always be one step behind. Checkmarx Fusion exists to close that gap for teams that need deeper validation and greater confidence in what they are shipping.  

The apprentice’s mistake wasn’t casting the spell. It was assuming he could still control however many brooms showed up. Checkmarx Fusion is built for the version of that story where the brooms keep coming faster than anyone planned for, and someone still has to know which ones matter. 

Visit the Checkmarx Fusion landing page. Read more on the Checkmarx blog or in the documentation. 

Every seasoned investor knows to never put your money behind a single asset.   
A successful investment strategy is diverse.  
 
No one puts all their money in stocks: markets correct. Real estate goes through cycles of boom and bust. Cash may feel safe, but inflation erodes its value over time. Having different investment assets helps offset volatility, so your portfolio as a whole stays resilient, even if that meme coin you bought on a whim takes a nosedive.  
 
The same principle of diversification applies to our work in application security. Staying ahead of emerging threats and bad actors in the era of AI-generated code demands more than a single line of defense. It requires a layered, deterministic, and probabilistic approach. Each approach has limits on its own. Together, they work like a diversified portfolio. 

The Growing Gap Between Functional and Secure 

This is the essence of our Checkmarx strategy, and we’re thrilled to see our vision backed by independent, hard data. We sponsored recent research published in The Weather Report, a non-profit AI security and safety lab led by Dr. Ilya Kabanov, former founder of AI Safety & Security at Google and a research affiliate at MIT Sloan Cybersecurity. While Checkmarx funded the study, Kabanov and his team retained full control over design, methodology, evaluation, and conclusions.

In his research, Kabanov re-ran two established security benchmarks: a snippet-level test, and a broader agentic test built around real open-source repositories. He tested both against frontier models in their native CLIs: Claude Opus 4.8, GPT-5.5, Gemini 3.1 Pro, and Gemini 3.5 Flash.

The results? These models now produce working code 83–95% of the time, but secure- 
and-functional code, or output that both works and passes security tests, still reaches only 24–36%.

That finding alone should give any AppSec manager pause. But Kabanov’s research went even further. Adding inference-time security steps, or threat modeling before coding, security review after, raises the secure-and-functional rate from a baseline of 24-36% to 47-56%.

But this improvement comes at a steep cost. Running a task through the full intervention ladder uses roughly four to five times the tokens required to write the code alone, while still leaving roughly half of all tasks insecure.

That’s like paying a premium for a guess dressed up as a guarantee. But even then, Kabanov isn’t convinced that better code generation leads to more secure code, noting that “functional capability is a weak predictor of security.” In his findings, one of the top-ranked coders actually finished last on security. 

LLMs Alone Can’t Keep the Codebase Secure

These are the reasons we built the Checkmarx One unified platform as the most efficient, cost-effective way to deliver security at the speed of frontier LLMs. It’s a deterministic floor for ground truth and auditability, offering AI-augmented reasoning for context and novel patterns, with security context (reachability and business risk) layered on top.

Because while the leading LLMs are exceptionally good at code generation, when it comes to protecting that code, an “LLM-only” approach isn’t enough. The smart investor never bets on a single asset. The smart AppSec team doesn’t bet on a single model. 
 
Our deterministic tools apply consistent rules and proven detection logic, producing repeatable results that teams can trust and verify. That’s the core of our Checkmarx vision: a hybrid platform that we call Fusion that pairs certainty (deterministic ground truth) with possibility (probabilistic AI reasoning). 

Relying on the same model to check the code that it writes is an inherent conflict of interest. The Chief Financial Officer doesn’t audit her company’s financials. We champion independent verification in AppSec: a system of checks and balances to keep any single point of failure from compromising the stack.  

Tokenization Savings Is Only the Start

Not only are there cost savings to be realized by leveraging a hybrid AppSec strategy, but when issues are addressed earlier in the development lifecycle, the cost to fix them goes down. Way down.  
 
In a recent talk I gave, “When Code Secures Itself: The Rise of Agentic AI in Application Security,” I outlined four control points across the AI development lifecycle and a simple, uncomfortable truth: the cost of fixing a vulnerability rises roughly 10x at every stage you wait. 
 
Fixing a vulnerability in the IDE is roughly 10x cheaper than in the build pipeline, 100x cheaper than in the AI supply chain, and 1,000x cheaper than in runtime.  
 
Yet only one in five developers embed security at the point of code creation, according to the 2,350 AppSec professionals we surveyed for our Future of Application Security Report. 
 
More than 80% of AppSec is conducted at defined stages after the code already exists, or worse, reactively once incidents surface. And the later a flaw is found, the more it costs in time, money, and exposure. 

Show Me the Metrics

An F1 score measures a scanning engine’s fidelity, how well it finds real vulnerabilities without burying teams in false positives.

In head-to-head testing across seven real production codebases, Checkmarx One’s hybrid engine achieved an F1 score of 0.64 – more than three times the industry average of 0.20 – across competing approaches that Checkmarx evaluated.

We are building on this momentum by helping AppSec teams address the new challenge of AI-generated code: shifting the focus from discovery and “mass-detection” to “mass remediation” to fix vulnerabilities quickly and consistently, whether newly-created or languishing in the backlog. 
 
Our newly-launched agentic experiences – Triage Assist, Remediation Assist, and Developer Assist – are purpose-built for this moment.

Triage Assist cuts through vulnerability noise using reachability, exploitability, policy context, and application risk to surface what deserves attention first. Remediation Assist then generates contextual, merge-ready fix recommendations that fit how developers already work. Developer Assist 2.0 is a fully autonomous virtual assistant working alongside developers in the IDE, detecting issues, generating fixes, and iterating until code is clean.

The result: fewer hours lost to manual analysis, fewer handoffs between AppSec and development, and faster remediation across the ADLC. This drives better credibility for AppSec teams, and more time for developers to do what they do best: build. 
 
But knowing how to find and fix vulnerabilities faster only matters if you know what you’re securing in the first place. That’s the gap our newly-launched Checkmarx AI Inventory closes.  
 
AI Inventory gives teams continuous, deterministic visibility into every AI component running in their code (like models, agents, MCP servers, SDKs,) and generates an AI-BOM (AI Bill of Materials.) This provides policy controls and audit-ready documentation for every AI component discovered, helping teams manage assets, monitor risk, and stay ahead of emerging compliance requirements.

The Portfolio Approach to Application Security

The best portfolios don’t win by picking one great asset. They win by pairing complementary strengths to deliver returns no single position could achieve alone.

In application security, that means combining the fluency of frontier AI with the certainty of deterministic enforcement.

Working in balance. Proven by the numbers. Built to scale with whatever comes next. 

That’s the Checkmarx strategy. Built for today’s threats. Ready for whatever comes next. Get a personalized AppSec demo from Checkmarx today. 

Learn More About What’s New from Checkmarx

Checkmarx Triage Assist  
Checkmarx Remediation Assist  
Checkmarx Developer Assist 
Checkmarx AI Inventory 
 
Download the 2026 Checkmarx Future of Application Security Report

In 2023, a path traversal vulnerability in Starlette, one of Python’s most popular web frameworks  – was found, disclosed as CVE-2023-29159, and fixed. Case closed. The bug was dead and buried, like hundreds of thousands of CVEs before it: discovered by researchers, patched by maintainers, laid to rest by the security community’s accumulated, painstaking work. 

In 2026, a frontier AI coding agent rebuilt that same feature. The vulnerability walked right back out of the ground. And it wasn’t a one-off.  

That is the one of the central findings of new independent research Checkmarx commissioned from Ilya Kabanov, CEO of The Weather Report — the first study to measure, generation over generation, whether AI code is getting safer as it gets better. 

The answer is not. In fact, ironically, it’s quite the opposite.  

Security, it seems, is simply not a benchmark in the AI agents’ arms race toward ever-greater capability. And the result is AI output that, in the way that matters, is getting unsafer: a generation ago, most insecure attempts didn’t even work, so they never shipped. Now nearly everything works, everything ships, and according to the research, 65–75% of it trips over the same old CVEs the industry already resolved, dragging them back into production. 

Read the Full Research

The graveyard test 

Rather than invent yet another benchmark, the study re-ran two established ones on today’s frontier models: Claude Opus 4.8, GPT-5.5, Gemini 3.1 Pro, and Gemini 3.5 Flash, each in its own native agent CLI. 

The tougher of the two, SusViBes, is effectively a graveyard: 200 real feature tasks inside large open-source repositories, each one built around a real vulnerability that a human already found, disclosed, and fixed. The agent is asked to build the feature. The question is whether it independently arrives at the protection the human fix contained, or digs the old bug back up. 

The results: 

• Functional success surged to 83–95% across the cohort — up from 44–61% a single model generation ago. Writing working code is nearly solved. 

• Secure-and-functional success reached only 24–36%. Across models, 65–75% of working patches resurrected the vulnerability the humans had put to rest. 

• The functional–security gap widened — in the Claude lineage, from 38 points to 63 points in one generation. 
  
  

The models know, but still ignore 

Here’s what makes this more concerning than a knowledge gap. These CVEs are public. Their advisories, their fix commits, their write-ups are all over the training data. The models have, in all likelihood, seen the fixes, and they resurrect the bugs anyway. 

The study’s failure audit makes this concrete. In the analyzed failures, agents named the exact required defense in their own threat model, then shipped the vulnerable code anyway.  

“Just prompt it to be secure” doesn’t work 

The study tested a ladder of increasingly expensive interventions: 

• A one-line “follow best security practices” reminder added just 1–8 points of security, depending on the model. 

• Maxing out reasoning effort added zero security in a targeted spot-check — and halved the number of working patches. 

• A dedicated threat-modeling step before coding lifted cumulative secure-and-functional success to 43–49%, at roughly 2x the token cost of writing the code alone. 

• Adding a post-hoc security review reached 47–56% — at roughly 2.5x the token cost. 

Even paying the model multiples of the original task to secure its own output, roughly half the tasks still shipped insecure. 

What this means for your pipeline 

One scoping note the researchers are careful about, and so are we: these benchmark tasks were selected because the vulnerability is the natural way to build the feature. On generic everyday code, the resurrection rate is likely lower. But that scoping is cold comfort: real codebases are full of exactly these features, because that’s where the CVEs came from in the first place. 

And this isn’t confined to the lab. Checkmarx’s own 2026 Future of AppSec report – a survey of 2,350 CISOs, AppSec managers, and developers across 14 countries – supports these findings:  

•  70% of developers say AI code generation created more vulnerabilities in their code in 2025.  

• AI-generated code already contributed to 25% of breaches, making it a top-four breach vector in its first year of tracking.  

• And the dose-response curve is unmistakable: organizations where 81–100% of code is AI-generated ship vulnerable code at 3.4x the rate of those at 1–20%.  

With nearly half (49%) of production code now AI-generated, this isn’t one zombie wandering out of a grave – it’s a horde of them. 

Read the full research 

The complete paper, including the per-CWE breakdown, the intervention cost analysis, and the full failure-mode taxonomy, is available here: 

Read the Full Research 

Checkmarx One for Government (CxG) has officially achieved FedRAMP Certified status at the Moderate Impact Level (Class C, Rev5), a milestone that gives U.S. government agencies streamlined, compliant access to the industry’s most comprehensive application security platform.

The certification comes as agencies face growing pressure to modernize their systems, secure increasingly complex software supply chains, adopt AI responsibly, and meet evolving federal requirements without adding operational burden.

Federal Systems Demand a Higher Standard

Federal information systems carry an outsized burden. They hold Controlled Unclassified Information, power services that citizens depend on, and increasingly serve as the connective tissue between agencies, contractors, and critical infrastructure.

A vulnerability introduced at the code level doesn’t stay contained; it propagates into production systems that the public relies on every day.

FedRAMP exists precisely because of that reality. The Moderate baseline requires roughly 323 security controls across 17 control families, covering everything from access control to system and communications protection. Achieving that bar isn’t a checkbox exercise; it’s a rigorous, independently assessed validation that a platform is built to protect the confidentiality, integrity, and availability of federal data.

For Checkmarx, that data integrity isn’t just a compliance requirement, it’s foundational. An AppSec platform is only as trustworthy as the assurances it can make about the code, dependencies, and infrastructure it scans.

Achieving its FedRAMP Moderate certification means Checkmarx One for Government has been independently vetted to meet that bar for the U.S. government’s most sensitive unclassified workloads. Checkmarx is also pursuing the FedRAMP High Impact Level for its most mission-critical use cases.

Where Modern Risk Actually Enters

Protecting the integrity of federal systems requires more than securing custom code. Agencies also depend on vast ecosystems of open-source libraries and third-party components, creating additional paths for malicious code to enter trusted software.

Malicious packages are legitimate-looking software components – often libraries or modules – that have been intentionally crafted to perform harmful actions when installed or executed. Checkmarx has collected the largest malicious package database in the industry, over 400,000, helping organizations stay ahead of cyber threats and safeguard agencies from malware, spyware, and other threats.

Bad actors also target organizations by exploiting vulnerabilities in their trusted vendors or suppliers. Malicious code that is unnoticed may inadvertently be included in packages or updates from outside developers. These attacks can spread rapidly, affecting numerous users and organizations that rely on the compromised software, resulting in widespread damage and disruption. Notable examples include SolarWinds, MOVEit, and 3CX Software, which involved the distribution of malicious code through legitimate software or updates.

AI Is Changing the Math

AI-assisted development is raising the stakes even further.

AI has rapidly reshaped how software is built, with 99% of development teams using it for code generation. Developers across government and industry are leaning on AI coding assistants to move faster, and the productivity gains are real.

But so is the risk: AI-generated code is being shipped at a pace that often outstrips organizations’ ability to review it, and a growing body of evidence shows that a large share of organizations using AI coding tools are shipping vulnerable code as a result.

That shift changes what agencies need from application security in two important ways.

First, the sheer volume of code being produced means scanning has to happen continuously and automatically – human-speed code review was never designed for AI-speed code generation.

Second, the kinds of risk introduced by AI-generated code aren’t always the same patterns that legacy static analysis engines were tuned to catch, which means the depth and currency of an AppSec vendor’s detection engines matters more than ever.

Federal agencies need security that can leverage AI to operate at the speed of modern development while also distinguishing meaningful, exploitable risk from noise.

Code to Cloud: The Need for Unified AppSec

These changes make fragmented application security increasingly difficult to sustain.

Agencies that stitch together disconnected scanners for code, dependencies, containers, and cloud infrastructure end up with fragmented risk visibility and duplicated effort.

The challenge is no longer simply finding vulnerabilities. It is understanding how risks relate to one another, determining which findings matter most, and helping teams act before those risks reach production.

That requires a unified platform spanning the full software development lifecycle, from the first line of code through deployment. It must continuously update as threats evolve, apply consistent security policies across environments, and give developers and security teams a shared view of risk.

Why SaaS Delivery Is Now an Economic Necessity

Agencies must meet these requirements while operating under growing fiscal and staffing constraints. Agencies are being asked to do more – modernize legacy systems, meet Zero Trust mandates, comply with executive orders on secure software development – without adding more operational burden. In that environment, SaaS delivery isn’t just a convenience; it’s an economic necessity.

A FedRAMP-certified SaaS platform eliminates the need for agencies to stand up and maintain their own security infrastructure, reduces the redundant, agency-by-agency assessment cycles that FedRAMP was designed to eliminate in the first place, and shifts the burden of patching, scaling, and continuous monitoring to the vendor. That “do once, use many times” model is estimated to save significant time, cost, and staff effort across government.

For AppSec specifically, this matters. The tooling must evolve continuously alongside new development practices, vulnerabilities, attack techniques, and software ecosystems. Delivering those capabilities as an updated service is often more sustainable than maintaining a static, self-hosted deployment – freeing agency teams to focus on reducing risk, not managing infrastructure.

The Breadth Federal Agencies Need

Checkmarx One for Government is built for this environment. The platform brings application security capabilities together across the full development lifecycle, helping agencies reduce tool sprawl and manage risk through one consistent, FedRAMP-certified environment. Its capabilities include:

• SAST (Static Application Security Testing): identifying vulnerabilities directly in custom source code
• SCA (Software Composition Analysis): securing open-source dependencies and managing license risk
• Malicious Package Detection: flagging compromised or intentionally malicious open-source packages before they reach production
• IaC Security: scanning Infrastructure as Code templates for misconfigurations before they’re deployed
• Container Security: securing container images and runtime environments
• ASPM (Application Security Posture Management): correlating findings across all of the above into a unified, risk-prioritized view
• DAST (Dynamic Application Security Testing): coming soon to the platform, extending coverage to runtime behavior and closing the loop from code to cloud.

Together, they give federal agencies consistent visibility and control across custom code, open-source software, infrastructure, containers, and deployed applications.

Find Vulnerabilities Before They Happen

But visibility alone does not reduce risk. Agencies also need a practical way to understand which findings matter and help development teams address them before they reach production.

That is where Application Security Posture Management (ASPM) becomes especially important. ASPM brings findings from across the application lifecycle into one unified, risk-prioritized view, helping security teams understand which vulnerabilities matter most, identify coverage gaps, track remediation progress, and maintain a clearer picture of their overall security posture.

Rather than treating every finding as equally urgent, agencies can use that context to direct limited resources toward the vulnerabilities most likely to create meaningful exposure. This supports more proactive vulnerability management, stronger compliance, and better coordination between security and development teams.

ASPM also helps translate that intelligence into prioritized tasks within the tools developers already use, allowing them to address issues closer to the moment code is created without repeatedly leaving their workflows to interpret disconnected security reports.

For federal agencies, that matters. Security teams can apply consistent policies from development through deployment, reduce the number of vendors and consoles they manage, and turn fragmented findings into coordinated remediation.

This code-to-cloud approach connects broad security coverage with the context and workflows teams need to act on it.

What This Means for Federal Agencies

A FedRAMP-certified platform strengthens cybersecurity by standardizing environments, enabling continuous monitoring, and automating processes, freeing resources and helping security teams stay ahead of evolving threats.

With Checkmarx’s FedRAMP Moderate certification established, federal agencies now have a faster, lower-friction path to deploying Checkmarx One for Government: a single, comprehensive, cloud-native AppSec platform, independently assessed against a rigorous federal security baseline, covering the full software development lifecycle.

They can secure applications from code to cloud while reducing infrastructure overhead, consolidating disconnected tools, and giving development and security teams a shared view of risk.

The platform is also backed by more than two decades of application security experience. Checkmarx helped define the SAST category and pioneered developer-centric approaches to finding and fixing vulnerabilities in custom code.

That history matters in a federal environment. Agencies need confidence that the vendor securing their software supply chain can adapt to changing compliance frameworks, development models, threat patterns, and mission requirements.

As agencies continue to navigate secure software development mandates, Zero Trust requirements, and constrained budgets, that combination of breadth, maturity, and compliance is becoming less of a nice-to-have and more of a baseline expectation – and Checkmarx One for Government is built to meet it.

For AppSec teams, this creates two core problems:  volume and visibility. 

• Volume. AI is speeding up development output, but AI-generated code produces 1.7x more vulnerabilities than human-written code. More code means more findings per scan, growing backlogs, and a security team forced to choose between rigor and velocity.  

• Visibility. The AI components powering development – models, datasets, MCP servers, agent frameworks, and prompt libraries – are entering codebases without formal review or governance. Most organizations don’t know which AI assets they’re running, where they’re embedded, or what risk they carry. That gap has consequences: over 75% of organizations have experienced a software supply chain attack in the last year, because every new AI component introduces a potential attack path.  

As development speeds up, these unmanaged AI components accumulate faster than security teams can evaluate them, pushing AppSec programs beyond the limits they were designed for.  

The Shadow AI Problem in Your Software Supply Chain 

This gap exists because traditional AppSec was built for a world where the building blocks of software were code, libraries, and configurations. That world still exists, but now it runs alongside a parallel supply chain of AI components that most tools can’t see. 

Today, a typical AI-enabled application might include a fine-tuned LLM pulled from a public model hub, an agent framework that invokes external tools autonomously, an MCP server connecting the app to live data sources, embeddings generated from sensitive internal documents, and system prompts hardcoded in config files. 

None of these appear in a standard SBOM and only a few get flagged in a standard code scan. Each introduces distinct risks, from model poisoning and unverified weights to unsafe autonomous tool invocation and exposed datasets. 

Three forces are making this worse: 

• Visibility is breaking down. Most organizations can’t fully inventory which AI assets are in use, where they live, or what risk they introduce. It mirrors the early days of open-source governance, but with faster adoption and higher-stakes components. 

• The toolchain has expanded. Every model, dataset, MCP server, API, and open-source dependency creates a potential attack path. This growing web of dependencies increases both complexity and exposure.  

• Shadow AI is the new shadow IT. Just as shadow IT created governance blind spots in the cloud era, developers and DevOps teams are adopting AI tools, models, and plugins without formal security review, often because no review process exists yet. 

The attack surface isn’t theoretical. The EU AI Act, ISO 42001, and NIST AI RMF now treat AI component governance as a compliance requirement. If your AppSec program can’t answer what AI is in your software, where it is, and what it does, you have a gap. 

Why Existing Approaches Fall Short 

Several vendors have taken a swing at AI security, but the results don’t quite land for AppSec teams.  

• Cloud-posture tools that view AI through the lens of services and infrastructure exposure. These tools are useful, but they miss what’s embedded directly in code and configuration.  

• Artifact-level scanners review model files for malicious payloads, but don’t provide visibility into how those models are wired into your applications in the first place. 

• SCA extensions that identify open-source LLM dependencies in package manifests, but don’t understand agent frameworks, MCP servers, embedded prompts, or dataset references. 

Most importantly, tools that rely on AI inference to detect AI introduce the exact kind of non-determinism that worries auditors. If your compliance report is exclusively based on probabilistic detection, it isn’t audit-ready. 

To close this gap, you need a fundamentally different approach to discovery.  

Deterministic Discovery: Seeing What’s Actually There 

Checkmarx AI Supply Chain Security takes a different approach: code-first, deterministic detection with high-fidelity scanning. Instead of inferring the presence of AI assets, it reads them directly from imports, manifests, file paths, and configuration – the same signals a developer would traditionally follow to understand what a codebase depends on. 

This means: 

• LLMs and model references are identified by their identifiers in code and config, not guessed from patterns 

• Agent frameworks are detected from imports and initialization code 

• MCP servers are discovered from configuration and integration points 

• Datasets and embeddings are traced from references in source and manifests 

• System prompts are surfaced from hardcoded strings and config files 

The result is a complete, auditable AI asset inventory, not a probabilistic best guess. Every finding can be traced back to a specific line of code or configuration entry, which matters when you’re presenting results to a compliance auditor or explaining a finding to a developer. 

Risk Assessment Built for AI-Specific Threats 

Visibility helps close the gap, but it doesn’t solve the volume problem. More assets mean more potential risks, more findings, and more decisions – now extending across an entirely new class of components.  

Once you know what AI assets exist, you still need to understand what risks they introduce and how to address them at scale. 

Checkmarx AI Supply Chain Security assesses AI-specific supply chain risks that traditional AppSec tools weren’t built to find, including: 

• Model poisoning and unverified weights: Models pulled from public sources without integrity verification can carry malicious payloads or backdoors introduced during training. The LLM Security scanner identifies ML artifacts (PyTorch files, GGUF, H5, and others) and evaluates them for deserialization and execution risks. 

• Unpinned model versions: Floating model references (the AI equivalent of * in a package manifest) let upstream updates silently change your application’s behavior. Version pinning is enforced as a policy requirement. 

• Unsafe autonomous agents: Agents that invoke external tools without proper scope constraints create execution risks that are unique to AI systems. These are surfaced and assessed as part of the asset inventory.  

• Exposed datasets and embeddings: Datasets used for fine-tuning or RAG pipelines can expose sensitive internal information if they’re not properly scoped. Dataset references are tracked as first-class assets with their own risk profiles.  

• Dataset exposure and license violations: Open-source models and datasets carry licensing obligations that differ significantly from traditional software licenses. AI asset metadata includes license information, enabling policy enforcement before non-compliant components ship. 

The Same Workflows. Extended To Cover AI. 

Adding a new security tool usually means adding friction: a new platform to learn, a new set of alerts to triage, a new reporting workflow to maintain in parallel with everything else. This is where AppSec integration matters. 

Checkmarx AI Supply Chain Security is built directly into Checkmarx One, the same platform where you’re already managing vulnerabilities, running SAST and SCA, enforcing policies, and generating compliance reports. There is no separate product or parallel workflow to manage. 

In practice, that means: 

• AI components appear alongside traditional findings in the same dashboards, with the same triage workflows. 

• Policy enforcement happens in pull requests and CI/CD, the same way you gate on open-source vulnerabilities or SAST findings today. You can block unapproved models, flag unsafe agents, or require version pinning without writing custom automation. 

• AI-BOM generation means that AI assets appear in the same Bill of Materials as your OSS dependencies, with origins, licenses, dependencies, and risk metadata attached. 

• ASPM workflows including risk orchestration, analytics, dashboards, extend naturally to cover AI components without separate instrumentation. 

• API and CLI support lets AI scanning drop into existing pipeline automation without new integrations. 

The goal is accountability without friction. You’re not replacing your AppSec workflow; you’re just extending it to cover a new class of components. 

Here’s What Your AppSec Team Gets 

The result is a practical extension of your existing AppSec program. 

• Complete AI asset inventory across the enterprise. Every LLM, agent framework, MCP server, dataset, embedding, and system prompt that exists in your codebase is surfaced deterministically from code and configuration, compiled into a searchable, auditable catalog. 

• AI-specific risk assessment. Model poisoning, unverified weights, unsafe agents, exposed datasets, unpinned versions are detected with evidence-backed findings and actionable remediation guidance. 

• Regulatory readiness. AI-BOMs are aligned with compliance posture tracking against EU AI Act, ISO 42001, NIST AI RMF, and OWASP LLM Top 10, and ready to export when an auditor asks. 

• Policy enforcement in the developer workflow. Approved model lists, framework allowlists, version pinning requirements are enforced in pull requests and CI/CD, not after the fact. 

• No new platform overhead. Everything lives in Checkmarx One, using the same permissions, dashboards, and reporting your team already relies on.  

The Bottom Line for AppSec 

AI components have changed what your software is made of and are now part of the software supply chain. The question isn’t whether they exist, but whether your AppSec program can handle the visibility and volume that they introduce.   

Governing the AI supply chain isn’t optional anymore. Your AppSec program needs the visibility, tooling, and workflow integration to keep up. Checkmarx AI Supply Chain Security is built for that. Deterministic discovery, evidence-backed risk assessment, and end-to-end governance built directly into developer workflows. It integrates with your existing pipelines, giving you a unified risk picture across code, dependencies, models, and runtime environments without adding another silo to manage. 

See It in Action 

If this gap sounds familiar, it likely already exists in your organization’s environment. The good news?  It’s solvable without disrupting the AppSec program you’ve already built. 

AI coding assistants are helping developers move at unprecedented speed. But that same speed is creating a new security reality: more code, more vulnerabilities, faster exploitability, and a growing backlog that traditional AppSec processes were never designed to handle.

That tension shaped the conversation at the second annual Agentic AppSec Unleashed Summit, held on June 16. Across six main sessions and four exclusive early-access discussions, CISOs, customers, and product leaders explored how security teams can adapt to the AI-driven software supply chain.

One message came through clearly: Agentic development demands security that moves at the same pace.

The teams that succeed will not be the ones that slow down development. They will be the ones that learn how to secure software as fast as AI can create it.

The Future of AppSec: Deterministic Security Meets Frontier AI

Checkmarx CEO Sandeep Johri opened the summit by framing the challenge facing security teams today. AI is helping enterprises write code two to three times faster, but that acceleration is also producing more vulnerable code than traditional AppSec programs can absorb.

According to Johri, AI-generated code has a much higher concentration of vulnerabilities than human-written code, contributing to a threefold increase in the overall vulnerability backlog. Left unchecked, that backlog could slow the very innovation AI was meant to accelerate.

At the same time, attackers are also using AI. Exploit creation is becoming faster, cheaper, and more scalable. In 2018, exploiting a zero-day vulnerability could take roughly two years. Today, that window has shrunk to just one or two days, and it continues to narrow.

Given that speed, it may seem logical to fight AI with AI by relying on frontier models to find vulnerabilities faster. But Johri made clear that an “LLM-only” approach is not enough. Frontier models can uncover novel exploit paths, but they can also be inconsistent. Their results may change depending on the prompt, they can produce false positives, and they can still miss known critical vulnerabilities.

That is where deterministic security remains essential. Unlike LLMs, deterministic tools apply consistent rules and proven detection logic, producing repeatable results that teams can trust and verify.

The answer, Johri argued, is not AI or deterministic tooling – it’s both. Modern application security needs a hybrid platform that pairs deterministic ground truth with probabilistic AI reasoning, combining the consistency of traditional security with the speed and creativity of frontier models.

Johri also made an important architectural point: a the same model producing the code should not be trusted to secure it. Just as a system should not manage its own permissions or store its own master keys, the security control plane must remain independent of the AI it evaluates. He called it a “separation of church and state.”

That separation is central to the platform Checkmarx is building: one that combines deterministic ground truth with AI-powered reasoning while keeping security validation independent, consistent, and verifiable. The result is already showing impact, including a 60–70% reduction in false positives.

Beyond the False Choice: How AI and AppSec Win Together

The second session brought Johri together with other security leaders who are already navigating this shift:

Michael Schrank, former Group CISO, Adidas; CEO, Three Rivers Advisory

Joseph Wilson, SVP & CIO, CSG

Laurent Donnay, SVP IT Sales and Platforms, Deutsche Telekom

The central question in this session was simple: If AI can write code, find vulnerabilities, and generate exploits, what is left for AppSec to do?

The answer was not that AppSec becomes less important. It becomes the layer of trust, governance, and execution that makes AI-driven development safe.

AI can accelerate coding, scanning, and even exploitation, but organizations still need deterministic security to validate results, prioritize real risk, and ensure findings lead to remediation.

That is where the operational challenge begins. Most teams are not struggling because they lack security signals; they are struggling because those signals are fragmented and overwhelming. To turn findings into remediation, they need a connected view of risk that brings together code, runtime, identity, and data context to show what is truly exploitable and what should be fixed first. Wilson captured the maturity challenge directly: “Discovery without mitigation is just inventory.”

From there, the panel focused on what mature AppSec programs need to do differently:

• Measure what matters. Maturity isn’t how many vulnerabilities you find. It’s MTTR (mean time to remediation), how fast you resolve them.
• Integrate, don’t interrupt. Remediation belongs inside the existing SDLC, with agents proposing fixes directly in the pull request.
• Let agents do the grunt work. Triage and remediation that could take hours for developers can be completed by an LLM in two to three minutes.

The Vulnerabilities Were Always There: Now What?

In my session with Jonathan Rende, Chief Product Officer at Checkmarx, we put numbers behind the problem.

AI is not just changing how quickly software is written; it is changing how quickly security debt accumulates.

AI-generated code is introducing more defects per unit of code, with defect rates up 1.7x. When that increase is multiplied across the growing volume of AI-generated software, it compounds into roughly 5x more exploitable flaws. In other words, organizations are not just writing more code. They are also creating more risk for security teams to manage.

At the same time, attackers are moving faster and more cheaply than ever. A working CVE exploit can now cost as little as $1 and only minutes of compute. That means the window between disclosure and exploitation is no longer long enough for slow, manual response processes.

The result is a widening gap between what teams find and what they fix. Over the last year, vulnerability submissions increased while monthly fixes fell 46%. Discovery has scaled with AI, but remediation has not. Critical vulnerabilities are now piling up faster than most teams can resolve them.

The solution isn’t to replace traditional tooling with AI, but to combine both deliberately.

AI is fast and creative, which makes it useful for surfacing novel patterns that traditional scanners may miss. Deterministic security is consistent and repeatable, which makes it essential for catching known vulnerabilities, validating findings, and producing the evidence auditors require.

Put simply, AI casts the wide net, while deterministic logic confirms what is real.

That combination produces better signal. In Checkmarx labs, the hybrid engine reached an F1 score of 0.64, compared to roughly 0.20 for a pure frontier model like Claude Opus 4.7. That difference matters because it turns a noisy alert pile into findings teams can actually trust and act on.

Our conclusion was clear: discovery is no longer the hardest part. The teams that lead will be the ones that improve remediation throughput – their ability to fix vulnerabilities quickly, accurately, and consistently across both new code and the existing backlog.

Getting to High Fidelity

Checkmarx VP of Product Ori Bendet continued the case for a hybrid model by pointing to the limits of LLM-only security. In the BaxBench benchmark, even the best frontier models returned solutions that were incorrect or insecure more than 45% of the time. “If you go all-in on LLMs, you’re going to have missing results,” he said, “and those missing results create risk for your organization.”

Cost is another important factor. Scanning millions of lines of code with premium models can become expensive quickly, especially at enterprise scale. Security teams need an approach that is not only accurate, but also scalable, repeatable, and cost-effective.

Frank Emery, Senior Director of Product Management, then explained how Checkmarx’s next-generation SAST engine is built to deliver that balance. It combines three core capabilities: a deterministic, rules-based foundation for consistency and trusted ground truth; an AI-based, language-agnostic scanner that expands coverage to frameworks and languages traditional tools may not support; and a Findings Analysis Engine that reviews findings in context and removes false positives before they reach developers.

Together, these capabilities feed the Checkmarx ASPM platform, which helps teams understand where risk lives. From there, AI-powered agents, including Developer Assist, Triage Assist, and Remediation Assist, can identify issues earlier, triage zero-day and backlog vulnerabilities faster, and support remediation before risks escalate.

The result is less noise, broader language support, and stronger fidelity than traditional SAST. Just as importantly, this approach is grounded in two decades of Checkmarx research, detection logic, and AppSec expertise.

Remediation at AI Speed: From AI Vibe Coding to Verified, Governed Code

The next session shifted from strategy to practice in a discussion moderated by Checkmarx VP of Product Management Harshil Parikh. He was joined by two PatientPoint security practitioners: Femi Oyesanya, application security engineer, and Lily Leith, application security risk analyst. Together, they explored a practical question facing many AppSec teams today: remediation has always mattered, but how does AI’s speed change the way teams approach it?

For Oyesanya, the opportunity is clear. “We have a better, more reliable, faster way of doing it,” he said. But he also cautioned that automation brings new complexity. Risk does not come only from application code; it can also come from SCA vulnerabilities, compromised libraries, and other parts of the software supply chain. That means controls need to extend across the infrastructure, not just the code.

Leith described how PatientPoint has moved from a reactive model to a more anticipatory one. Instead of spending hours responding to the “attack of the day,” her team now uses automation to shorten response times. That includes monitoring new CVEs, checking whether GitHub packages are malicious, and using agents to determine what is actually exploitable.

The key, both speakers emphasized, is trusted context. By pulling in intelligence from sources like Checkmarx, teams can decide whether a vulnerability should trigger a break-build policy or move through another remediation workflow.

They also stressed that humans still need to stay in the loop. Developers remain the experts on their own codebases, so they need to review AI-generated fixes, catch hallucinations, and make sure suggested changes do not introduce new risk. For critical or externally facing systems, formal change management remains essential.

That is where governance becomes critical. Security gates, policies, and review processes keep AI-accelerated development accountable. Parikh closed on a note of hard-won optimism: the industry has been “notorious about not fixing things,” but he believes agentic remediation can finally help drive down MTTR with a solution built for practitioners.

Bring Visibility Across the Supply Chain

The final session focused on one of the biggest governance challenges in the AI era: visibility across the AI software supply chain. Checkmarx Product Director for SSCS David Dewaele and AWS Principal Solution Architect for ISV Security Paul DeLaria discussed how organizations can identify, assess, and govern the AI components now entering modern applications.

Most large organizations are familiar with shadow IT, where employees use tools that were never approved by the company. Security teams now face a newer and more complex version of the same problem: shadow AI.

Developers moving quickly may adopt unsanctioned AI tools, models, agents, MCP servers, or other AI components, creating risk that security teams cannot manage if they cannot see it.

DeLaria’s central point was simple and important: organizations cannot secure what they cannot see. Many leaders do not yet know which AI components are running inside their applications. Without that visibility, it becomes difficult to assess risk, enforce policy, or demonstrate compliance.

Visibility begins with the Shared Responsibility Model. Cloud providers are responsible for securing the cloud infrastructure itself, while enterprises are responsible for what they build and run on top of it. In the AI era, that includes identity and access management for agents, the AI tool supply chain, and observability into what those agents are doing.

Dewaele outlined a three-layer approach to AI supply chain governance.

• Detection: Identify every AI asset, from LLMs to agents to MCP servers, across the whole SDLC.
• Risk assessment: Run purpose-built scanners that catch new threats like malicious artifact injection and dangerous model loaders, alongside traditional scans.
• Governance and compliance: Generate AI Bills of Materials (AI-BOMs) to evidence security against frameworks like the EU AI Act, NIST, and ISO.

The goal is not only to detect risk. It is to create the visibility, context, and evidence organizations need to govern AI-driven development responsibly.

That’s a Wrap

The summit ended where it began: with the central idea that securing software at the speed of AI cannot be solved by one tool, one team, or one model. It requires a new AppSec discipline that is built layer by layer, from detection to remediation to governance.

That discipline starts with deterministic ground truth. It adds AI-driven reasoning where AI can provide speed, scale, and broader coverage. It uses agents to accelerate triage and remediation, and it creates visibility across the full software supply chain, including the new AI components that are quickly becoming part of modern applications.

AI has made it easier, cheaper, and faster for attackers to exploit software, but it has also created a new opportunity for defenders. With the right architecture, security teams can move faster without giving up trust. They can reduce noise without missing critical issues. They can govern AI-generated code without slowing innovation.

That is the blueprint Checkmarx laid out at Agentic AppSec Unleashed ’26: deterministic security and frontier AI, working together so organizations can secure software as fast as AI can build it.

The full sessions and slides are available on demand.

We believe this recognition validates our dev-first, unified approach to comprehensive supply chain protection and centralized governance.

Gartner evaluated vendors across two critical dimensions: Completeness of Vision and Ability to Execute, and we feel our placement underscores our innovation in supply chain risk detection and ability to deliver measurable business impact for enterprises managing complex software dependencies.

Securing the Supply Chain

We believe this recognition reinforces our commitment to helping organizations detect and remediate supply chain risks in a way that fits seamlessly into how development teams work.

By embedding security directly into developer workflows, through IDE integration, source control, and CI/CD pipelines, Checkmarx One makes it easy to catch supply chain risks early without slowing teams down. The unified platform covers SCA, container security, malicious package detection, secrets detection, SBOM generation, and our recently launched AI-BOM solution for managing AI components with audit-ready documentation.

Ready to Learn More?

Access the 2026 Gartner® Magic Quadrant™ for Software Supply Chain Security report or request a demo to learn more about Checkmarx One Software Supply Chain solutions.

^{Gartner does not endorse any company, vendor, product or service depicted in its publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner publications consist of the opinions of Gartner’s business and technology insights organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this publication, including any warranties of merchantability or fitness for a particular purpose.}

^{Gartner and Magic Quadrant are trademarks of Gartner, Inc. and/or its affiliates.}

The question is how did that happen, and how can you evaluate if your next tool will do the same thing?

It comes down to how vendors measure accuracy.

A scanner can lower its false positive count by simply flagging fewer things, but this means real vulnerabilities are passing through undetected. A scanner can also raise its detection rate by flagging everything, but this means your developers spend their time chasing noise until they stop looking at findings altogether. Both outcomes look fine on the summary slide – but neither is fine in practice.

The metric that closes this loophole is the F₁ score, a specific type of F-score that weighs precision and recall equally. Improving it requires improving both simultaneously – gains in one don’t compensate for weakness in the other.

It’s also why most AppSec vendors don’t advertise their F₁ score: the numbers reveal what they’d rather hide. Publish a weak F₁ and they’re admitting either that the scanner either misses critical vulnerabilities or that it drowns users in false positives. And neither is a compelling sales pitch.

The Basics: Precision and Recall

Every security scanner produces four types of outputs:

• True positives (TP): real weaknesses the scanner correctly identified.
• False positives (FP): findings that are not actually weaknesses.
• False negatives (FN): real weaknesses the scanner missed.
• True negatives (TN): clean code that the scanner correctly ignored.

Precision measures the share of findings that are real: 𝑇𝑃 / (𝑇𝑃 + 𝐹𝑃).
A high-precision scanner means fewer false positives so your team spends less time investigating findings that turn out to be nothing. The catch is that a scanner can achieve perfect precision by flagging almost nothing, which means real vulnerabilities sail through undetected.

Recall measures the share of real vulnerabilities that were found: 𝑇𝑃 / (𝑇𝑃 + 𝐹𝑁).
A high-recall scanner misses very little. But its catch is that a scanner can achieve perfect recall by flagging everything, which destroys signal-to-noise ratio (and sends your developers back to ignoring the queue).

AppSec vendors exploit this tension constantly. A tool can reduce false positives by simply reporting fewer findings, which quietly creates false negatives, letting real vulnerabilities pass through undetected. The tool looks precise on paper, but the vulnerabilities it stopped flagging didn’t disappear – they just stopped showing up in the report.

What the F Score Captures

The F score is the harmonic mean of precision and recall, a single number that captures both at once:

$F_1 = 2 \times \frac{\text{Precision} \times \text{Recall}}{\text{Precision} + \text{Recall}}$

Unlike a simple average, the harmonic mean heavily penalizes imbalance. A scanner with 90% precision but only 10% recall scores of 0.18, not 0.5. Both numbers must be high at the same time to produce a strong F₁ score. You cannot hide a weak recall behind a strong precision score, which is exactly what makes it a more honest benchmark than either metric alone.

An F₁ score runs from 0 to 1. What counts as a good score depends on the data being analyzed. Controlled benchmark studies with purpose-built vulnerable code tend to produce higher scores across all tool categories than tests on real production code. On real production code, scores are lower across the board – for traditional SAST tools, LLM-native reviewers, and hybrid approaches alike. This isn’t a flaw in the tools, but a reflection of how messy the real world is compared to carefully constructed examples.

This is why the test dataset matters as much as the score itself. A vendor quoting an F₁ score based on a controlled benchmark is making a very different claim than one quoting a score from real production code. And, if a vendor does not name the dataset, that is worth asking about.

Why This Matters for SAST

Static application security testing (SAST) is a classification problem at scale. On a single codebase, a scanner might analyze thousands of code paths and return hundreds of findings. For AppSec teams managing backlogs, false positives from scanners teach developers to ignore scanner output, leading to worse security outcomes.

Traditional rules-based SAST engines tend to favor high recall: find every possible match for known patterns. The tradeoff is well understood: by casting a wider net, they inevitably produce a higher false positive rate. Most security teams have learned to accept this as the cost of minimizing missed vulnerabilities.

AI-driven scanners take a different approach. Because they aren’t limited to simple pattern-matching, they can reason about the code in ways AI-only SAST engines cannot. But they introduce a different challenge: an AI model reviewing the code can’t self-police. It’s the computational equivalent of the fox guarding the hen house.

Some vendors address the false positive problem by reducing recall, so the findings look cleaner, which in turn quietly increases false negatives. Vulnerabilities that are missed do not announce themselves – and as a result, vendors can advertise low false positive rates while quietly allowing more real issues to slip through. This is precisely why the F₁ score matters. It makes the “low FP” trick harder to get away with. Vendors that report recall without precision (or precision without recall) are just emphasizing whichever metric presents their product more favorably. The F₁ score puts both dimensions on the table simultaneously, providing a more balanced measure of scanner effectiveness.

What Good Looks Like in Practice

Checkmarx Zero research published benchmark data from a study across seven production codebases (Istio, indico, OpenMRS, Mezzanine, SimplCommerce, Jellyfinn, ThreatByte) comparing hybrid SAST against LLM-native scanning with Claude Opus 4.7. The results:

• Checkmarx SAST: F₁ score of 0.64
• Claude Opus 4.7 (standalone LLM reviewer): F₁ score of approximately 0.20

The gap is significant. Checkmarx Zero research tested an LLM-augmented SAST engine head-to-head against Claude Opus 4.7 across seven real production codebases in Python, Go, and C#, covering 747 findings. The Checkmarx engine had an 11% higher true positive rate than Opus 4.7, found 327 additional true positives that Opus missed entirely, and Opus 4.7 generated a 44.1% false positive rate. Nearly half its findings were wrong.

The gap comes from architecture, not just model quality. The hybrid approach runs a deterministic rules engine first, extends coverage with a purpose-built AI model, then applies a classification layer that filters findings before they reach the analyst. Each layer addresses what the others cannot do alone.

For the full methodology and benchmark detail: LLM Application Security: Governing AI-Driven Risk Across the Software Lifecycle.

How to Use F Score To Evaluate a Scanner

If the F₁ score is the most balanced measure of scanner performance, then it should also be one of the first metrics you ask about when evaluating a vendor. Unlike standalone precision or recall figures, the F score makes it much harder to hide tradeoffs between finding vulnerabilities and avoiding false alarms.

Start by asking a vendor for their scanner’s F₁ score on a defined, real-world codebase. The dataset matters. Purpose-built, vulnerable-by-design projects are useful for research and benchmarking, but do not represent production code. What matters is results from real code shipped by real software teams.

Ask if precision and recall are reported separately. A vendor willing to disclose both numbers is making a more credible claim than one that highlights only detection rates or false positive reduction. Without both numbers, it’s impossible to understand the actual performance.

Watch for vendors who improve one metric by degrading the other. Lower false positives achieved by missing more vulnerabilities is not an accuracy improvement. F₁ exposes exactly that tradeoff.

If a vendor cannot provide an F₁ score or refuses to identify the test dataset, that should prompt further investigation before making a purchasing decision.

The Bottom Line

Security vendors will always have metrics, benchmarks, and marketing claims. Detection rates, false positive reductions, and accuracy scores that can all look impressive in isolation. The problem is that each tells only part of the story – and many can only be improved by optimizing one outcome while sacrificing the other.

The F₁ score is different. It rewards scanners that can do both: find real vulnerabilities and avoid overwhelming teams with false alarms. A scanner cannot achieve a strong F₁ score by excelling at only one side of that equation.

That is why the F₁ score is one of the most useful measures of scanner performance. It forces precision and recall to be evaluated together, making tradeoffs visible instead of hiding them behind carefully selected statistics.

When a vendor can provide an F₁ score on a named, real-world dataset, they are making a claim that can be examined, challenged, and compared. When they avoid quoting one, it is worth asking why.

That is the starting point for any honest conversation about scanner accuracy.

See how our Checkmarx SAST helps reduce noise, uncover more real vulnerabilities, and deliver balanced performance across precision and recall.

Security is falling behind how software actually gets built. 

Developers are spending more of their day inside AI assistants than inside any web platform. AppSec teams are answering the same questions, what are my riskiest projects, which findings need triage, how does this week compare to last, but still doing it by logging in, clicking through dashboards, and switching between tools. Security leaders need visibility on demand, not after a report gets pulled. 

The interface layer is changing. AI assistants are becoming the primary way people interact with their tools. In a growing number of cases, agents are executing workflows without a visible interface at all, triggering builds, resolving dependencies, making decisions without a human ever opening a tool. This is what headless application security looks like in practice: security that either participates in the workflow at execution time, or misses it entirely. 

If security is not present in that layer, it gets consulted after the fact. Or not at all. 

Why This Matters Now 

MCP has quickly become the standard for connecting AI tools to external systems. 

MCP-related SDKs reached 97 million monthly downloads within their first year. OpenAI adopted MCP in early 2025, deprecating its own Assistants API. In December 2025, Anthropic donated the protocol to the Linux Foundation, with OpenAI, Microsoft, AWS, Cloudflare, and Bloomberg as founding members. 

This is no longer an emerging standard. It is the standard. 

As AI assistants become the primary interface for software development and security operations, the question for every security tool is simple: are you present where decisions get made, or are you consulted after the fact? 

Today, that question has an answer. 

Introducing Checkmarx MCP Server 

Checkmarx MCP Server connects your Checkmarx One environment directly to any MCP-compatible AI tool, including your IDE assistant, your chat interface, and your automated pipeline. 

Configure it once, and Checkmarx becomes a native tool available everywhere your team already works. 

Built for How Security Work Actually Happens 

MCP serves the entire security workflow, not just developers. 

Developers stay in flow inside their IDE or CLI. They can trigger scans, retrieve findings, drill into vulnerabilities, and explore remediation options without switching tools. 

AppSec teams replace dashboards with queries. They can ask for findings across projects, compare scan results, and analyze application posture from a chat interface without logging into the platform. 

Security leaders get instant visibility. They can ask how many critical issues exist across the organization, which applications carry the highest risk, and how posture is changing — without waiting for reports. 

The result is simple: security moves from a system you visit to something that works alongside you. 

What You Can Do With It 

At launch, Checkmarx MCP Server ships with around 20 tools covering the core security workflow directly inside your AI assistant. You can: 

1. Trigger SAST, SCA, IaC, and Secrets scans 

2. Retrieve and filter findings with full context 

3. Get risk visibility across projects and applications 

4. Manage applications and projects 

5. Run the complete create to scan to review to act loop without leaving your environment 

These are not raw API calls wrapped in a tool. They are high-level, composable actions designed for natural language interaction, built so an AI agent can reason over them and chain them dynamically based on what you ask. 

Simple to Connect, Enterprise Ready by Design 

Connecting takes minutes. An admin enables access once and it becomes available across the organization. 

Developers can connect from any MCP-compatible client through marketplace and connector integrations — available now on Claude, GitHub, Cursor, Visual Studio Code, and OpenAI, that handle configuration automatically. For advanced setups, standard JSON-based configuration is also supported. 

Enterprise-grade controls are built in from the start, including RBAC passthrough, multi-tenant isolation, audit logging, and TLS. The same security posture you expect from Checkmarx One, extended to the agent layer.