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. 

Who turned up the heat? Mythos, Anthropic’s tectonic leap forward in bug detection. The new Claude model has astounding implications for enterprise security. Of the vulnerabilities Mythos has found so far, 99% haven’t been patched, according to Gartner.  
 
That stat came to life at the Gartner® Security and Risk Management Summit last week, where a show of hands in a room of roughly 300 security professionals revealed that barely ten had met a 30-day critical patch SLA. Almost none had hit 7 days. All this while Mythos can generate working CVE exploits in 10–15 minutes, at less than $1 per exploit. 
 
The reaction in the room said it all: every LLM is a potential attack surface. Mythos has made the tech debt bill come due, by surfacing a massive backlog of findings that can no longer be deferred. 

It’s never been faster, cheaper, or easier to do bad things in the digital world. The time to patch is now.

The Call is Coming from Inside the Code!

Humans aren’t the only ones who can wreak havoc with AI, as I learned from another Gartner session. The most dangerous thing an AI agent does might not be what an attacker tells it to do. It might be what it decides to do on its own. 
 
One researcher shared two sobering examples. In the first, an autonomous agent started deleting a director’s emails unprompted and kept going even after being told to stop. She had to physically unplug the machine. In the second, a company lost its entire production database in nine seconds. It wasn’t a human attacker, but to a coding agent “helpfully” searching for an API key that stumbled into a destructive command and crashed the platform.  
 
Unsettling? Yes. Also, exactly the wake-up call the industry needs to stop treating security as a checkpoint and start treating it as infrastructure.

Security as Infrastructure, Not Afterthought

The rapidly evolving threat landscape demands a fundamentally different approach. Organizations large and small must stop treating security as a gate at the end of the pipeline and start embedding it into every phase of development. That means collapsing raw findings into actionable signal, building remediation directly into developer workflows, and maintaining visibility across every layer of the software supply chain. 

Discovery is table stakes now. Remediation at scale is the true measure of success. CISOs need to stop counting vulnerabilities found and start tracking how fast they fix them.  
Because in a world where exploits can be generated in minutes for less than a dollar, the backlog IS the breach. 

It starts with the developer.

In my talk at this week’s Summit, “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. 
 
The first control point is the IDE, where AI-generated code is being written. This is where intervention is cheapest, where you have full application context, and where real-time assessment can catch issues before they ever leave the developer’s screen.  
 
The second is the build and CI/CD pipeline, where hybrid deterministic and AI-powered scanning can handle the sheer volume of findings and triage them by real exploitability — not just raw count.  
 
The third is the AI supply chain itself: MCP servers, agent frameworks, foundation model SDKs, and fine-tuning pipelines, all of which require deterministic discovery from outside the model.  
 
And the fourth is runtime, where dynamic testing extended for AI workloads and application security posture management tie findings back to business context and close the feedback loop. 
 
So catching a vulnerability in the IDE is roughly 10x cheaper than catching it in the build, 100x cheaper than in the supply chain, and 1,000x cheaper than in runtime/production. 

But here’s the harsh reality: only about one in five developers actually embed security at the point of code creation. We know this from the 2,350 AppSec professionals in 14 countries we surveyed for our most recent 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. Flaws caught late are flaws that can be exploited. Flaws that can be thousands of times more expensive to fix.

Cast Wide, Fix Fast, Trust Nothing

The future of application security is about casting the widest net possible: probabilistic, deterministic, agentic, and independent capabilities, all working together. These are the principles we’ve built into the Checkmarx platform, informed by two decades of protecting enterprise code and scanning trillions of lines of it. In my talk at the Summit, I outlined what we at Checkmarx see as the non-negotiables: 

• The benefits of hybrid scanning. Deterministic precision combined with AI-augmented reasoning — known patterns and novel zero-days, not one or the other. 

• Importance of prioritization by attackability. Performance is measured by ranking findings by real-world exploitability, not raw severity scores. Fix what matters first. 

• AI supply chain visibility is critical. MCP servers, agent frameworks, model SDKs, fine-tuning pipelines, all need to be governed from outside the model, because the student should never grade their own exam. 

• Enterprise-scale governance is mandatory. Barely one in five companies even have formal AI governance (another concerning stat from our Future of Application Security Report.) Organizations need policy management and guardrails that scale across organizations, not just individual developers. 

• Humans in the loop, always. AI handles the volume and velocity. Real experts stay in control with full oversight, policy enforcement, and audit-ready reporting.  
  

Let’s Jump Before the Water Boils

The agents are already here, writing code and taking actions at a speed no human team can manually oversee. The question isn’t whether you need agentic security — it’s whether you’ll have it before the next nine-second disaster. 

The water is getting hotter. The frog that survives is the one that feels the temperature and jumps before it’s too late. 

The challenge begins when that prototype meets production.

Real enterprise environments are messy: large codebases, multiple languages, constantly changing repositories, and strict rules around who can access what. A demo that works on clean, controlled inputs will struggle when it hits that reality – and the failures are often hard to spot until real damage is done.

The question isn’t whether you can build an AI security agent. It’s whether you can make it accurate, trustworthy, and dependable at scale.

What the Demo Gets Wrong

On the surface, building an AI security agent seems straightforward.

Your security scanner flags a potential vulnerability. The agent reads the relevant code and answers two questions: is this real and exploitable? And if so, what’s the fix? A capable engineer can wire this up in an afternoon, and the same pattern holds for most code-reasoning agents.

A basic pipeline is simple enough to build: take the finding, attach the relevant code, send it to a frontier model with a good prompt, and parse what comes back. In a controlled environment, the results can be impressive. The agent appears accurate, useful, and ready for production.

The prototype works because its assumptions are controlled: one language, a clean repository, a code snippet that fits in the context window, and all the information needed to make the decision already available. Production removes those assumptions one by one.

A real environment generates thousands of findings across dozens of languages and frameworks. Repositories are large monorepos with partial checkouts. The scanned commit may no longer exist. Branches get deleted. The code needed to understand a single finding can span multiple files, services, and dependency versions, far more than can fit into a context window.

On top of that, the model itself is non-deterministic. The same input can produce different answers on different runs. The hard part was never the model call. It is everything required to make that call correct, reliable, and repeatable at scale.

The Layers Most Prototypes Ignore

A production agent isn’t just a prompt, it’s three systems working together. Most prototypes focus almost entirely on the first, which is exactly why they struggle in production.

1. Prompt engineering

This is the part most people think about first: task framing, output schemas, system instructions, and few-shot examples. It determines how the model reasons about a problem. It is essential, but it only controls the model’s behavior. It does not determine whether the model has the right information or whether its answer can be trusted.

2. Context engineering

Context engineering is about getting the right information to the model in the first place. That means resolving the exact repository state, tracing data flow, identifying relevant dependencies, and selecting the smallest amount of code needed to make a correct decision. In practice, this is where accuracy is often won or lost.

3. Harness engineering

Harness engineering is everything around the model that makes it usable in production: orchestration, evaluation, guardrails, isolation, observability, retries, fallbacks, and cost and latency management. It is the layer that turns a capable model into dependable software.

Prompt engineering is the visible part of the system. Context engineering and harness engineering are the much larger layers beneath it that determine whether the agent can be trusted in production.

Those layers consist of a collection of supporting subsystems that rarely appear in demos but do most of the work required to make the agent reliable:

Data ingestion and normalization

A finding is a pointer, not a payload. The system must resolve the exact file at the scanned commit, across SCM, scanner, and CI systems, with consistent schemas across languages and scanner versions.

Context modeling

A monorepo will not fit in a context window. Techniques such as call-graph traversal and taint analysis identify the specific code, configuration, and dependencies a verdict depends on. The goal is to provide enough context to be correct without overwhelming the model.

Identity and access

The agent acts across repos with different permissions. Results must never expose code a user is not authorized to see, and multi-tenant environments must prevent data leakage between customers.

Workflow integration

A verdict that does not land in a PR, ticket, IDE, or SARIF stream has limited value. The agent must also stay synchronized with the systems that track vulnerability status and ownership, whether that is a ticketing or GRC system or the scanning platform itself. This means deduplication across scans, idempotent comments, and durable state for findings that have already been triaged or dismissed.

Evaluation

Quality must be measured before it can be improved. That requires labeled datasets for triage and remediation outcomes across languages and vulnerability types, along with regression suites that detect when prompts, models, or system changes reduce accuracy.

Security and governance

The agent reasons over attacker-influenced sources and makes decisions an enterprise is accountable for. It needs prompt-injection defenses, human-in-the-loop gates for high-impact actions, and policy controls over what it is allowed to decide on its own versus escalate.

How It Fails (Usually Quietly)

A prototype rarely fails with an error message. More often, it returns a confident, well-formatted answer that happens to be wrong. In a security workflow, a plausible wrong answer is harder to detect – and often more damaging – than an obvious failure.

Some of the most common failure modes look like this:

Getting an agent to be right most of the time is straightforward. The harder challenge – closing the gap between “works most of the time” and “can be trusted consistently in production” – is where most of the engineering effort lives. Each incremental improvement requires more context, more validation, and more operational controls than the one before it, and the work never really ends because models, threats, and codebases continue to change underneath the system.

It’s an Ongoing Commitment, Not a Project

Choosing to build an AI security agent internally is not a decision to complete a project. It is a decision to own and operate a long-lived ML system. The initial build is often the smaller investment. The ongoing responsibilities look like this:

• Model migration – Providers deprecate and release models on their schedule. Each change means re-validating every prompt and re-running the full evaluation suite before you can trust it.
• Evaluation upkeep – Labeled datasets must grow as new languages, frameworks, and CWEs appear, and as your own codebase evolves. Labeling is slow, expert, and never finished.
• Coverage expansion – Every new language or package manager is a new context-extraction and validation effort, not a configuration flag.
• Drift and regression detection – Quality degrades silently. Catching it requires production monitoring, sampling, and someone accountable when accuracy slips at 2 a.m.
• Agent attack surface – The agent itself is now part of your threat model and needs ongoing security review like any other production service.
• Audit and compliance – Every automated decision that dismisses a risk or merges a fix must remain explainable, attributable, and traceable for as long as your retention and regulatory obligations require. An agent whose decisions cannot be reconstructed later is a finding waiting to happen in your next audit.

Once you understand what it takes to operate the system, the build-versus-buy decision becomes much easier to evaluate.

Build or Buy?

The question isn’t whether a capable team could build this. They can. The question is whether this is a capability you want to own and operate.

Building internally tends to make sense when:

• This capability is core, differentiating IP, not supporting infrastructure.
• You have a dedicated ML/platform team with capacity to operate it indefinitely.
• You can fund continuous evaluation, labeling, and model-migration work as a standing cost.
• Your scope is narrow enough (few languages, controlled repos) to keep the context problem tractable.

A purpose-built product tends to make sense when:

• You need broad language and framework coverage from day one.
• You need audit, isolation, and compliance guarantees out of the box.
• You’d rather your security and platform engineers spend cycles on your business, not on operating an ML pipeline.
• You want the reliability curve already climbed, and kept climbed as models change.

Before You Build, Answer These

Conclusion

A prompt and a model call can produce an answer. Making that answer reliable, repeatable, and trustworthy across thousands of findings, repositories, and edge cases is the real work.

The challenge isn’t creating the agent. It’s operating the system around it.

That is the central finding of The Future of Application Security in the Era of AI, a global research conducted annually by Censuswide on behalf of Checkmarx and published today. 

The report is based on a survey of 2,350 CISOs, AppSec managers, and developers across 14 countries – our largest sample to date – and it describes an industry that has solved detection but can’t close the gap between finding a vulnerability and fixing it. 
 
Up until April, this tension was barely viable. Then Anthropic disclosed Mythos — a model capable of discovering and exploiting long-standing vulnerabilities across major operating systems and browsers, producing working exploits nearly 100 times more frequently than its predecessor.  

A world where a third of organizations leaving half their vulnerabilities unfixed for 90 days cannot survive a reality where Mythos and the models to follow it exist. The clock now runs in minutes, not months.  

Read the full report. 

What the Data Reveals 

Two years after AI code generation went mainstream, the development environment has fundamentally changed. But the systems responsible for securing it have not. 

Most code isn’t really yours anymore. 49% of production code is now AI-generated. 67% of organizations report that open-source components make up at least half their codebase. Human-written first-party code is no longer the norm. The developer role has shifted from author to editor, and the security model built for human-authored code hasn’t shifted with it. 

More AI code means more risk — and the correlation is linear. We segmented all 2,350 respondents by how much of their production code is AI-generated, then compared each group’s rate of shipping known-vulnerable code. Organizations where 81-100% of code is AI-generated ship vulnerable code at 3.4x the rate of those at 1-20%. The pattern is clear across every bracket: 14% → 19% → 23% → 36% → 47%. And 70% of developers themselves confirm that AI code generation tools introduced more vulnerabilities in 2025. 

Risk is normalized — from the bottom up and the top down. 75% of organizations knowingly deploy vulnerable code. 30% ship hoping the vulnerability won’t be found. At the leadership level, 95% of CISOs report being pressured to suppress or delay compliance-related security findings — 47% frequently. Budgets are growing (46% increased year-over-year), but only 19% of CISOs say their budget allows them to proactively reduce risk. The rest are operating in reactive or constrained modes where known risk is tolerated by design. 

Three roles, three realities. For the first time, this report analyzes how CISOs, AppSec managers, and developers diverge on the same questions — and the gaps are significant. CISOs say 11% of organizations were breach-free in the past year. Developers say 8%. AppSec managers — closest to the risk — say 1%. On shadow AI: CISOs see 5%, AppSec sees 18%. On whether AI coding is governed: CISOs and developers say 27-28% is “standardized and governed.” AppSec says 12%. The people responsible for security can’t agree on what’s happening inside their own organizations. 

Confidence and outcomes move in opposite directions. 73% of CISOs and AppSec managers rate their security posture as advanced or highly mature. Yet 81% of organizations were breached twice or more in the past 12 months, and 48% three or more times. The most striking finding: organizations that rate themselves “highly mature” report the highest AI code volumes (60%), the highest rates of shipping vulnerable code (42%), and breach rates virtually identical to the rest of the industry. 

The tools work. The system doesn’t. 96% of developers have AI-based security tooling in their IDE. Virtually all (99.6%) rate it effective. Yet only 18% apply security continuously as code is written — 82% still rely on checkpoints. Only 9% of organizations fix more than 90% of vulnerabilities within 90 days. A third leave half their known vulnerabilities unfixed within that window. Detection is solved. The organizational response is not. 

Developers are set up to fail. Developers spend nearly half (49%) of their time on security and still ship vulnerable code at the highest rate of any group (32% “often”). When remediation fails, they face consequences on every front: post-mortems (39%), performance reviews (37%), escalation (36%), blocked releases (33%). Yet the systems contributing to that failure — tools generating low-value findings (37%), unclear guidance (38%), feedback arriving too late (38%) — remain unfixed. All of the accountability, none of the support. 

What’s in the report 

The full report goes deeper: 

• Regional breakdowns across 14 countries and three regions — including why Europe leads on breach rates, budget increases, and slowest remediation simultaneously 

• The complete cross-tabulation analysis linking AI code volume to vulnerable code deployment and breach frequency 

• The three-way perception gap: how CISOs, AppSec managers, and developers report fundamentally different versions of the same reality 

• The confidence paradox: why “highly mature” organizations sit at the top of every risk curve 

• The developer burden data: time spent, friction sources, consequences, and why the current model is failing them 

• Six strategic imperatives for closing the gap between detection and action — including the case for agentic security 

From governance frameworks to the autonomy question to the case for agentic security, it’s not only the most comprehensive and up-to-date survey of how AppSec is practiced across the industry — it’s the playbook for what organizations need to do to stop letting known risks survive the decision chain. 

Read the full report. 

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

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

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

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

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

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

Smarter Triage: Context-Driven, Data-Driven Decisions 

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

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

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

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

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

Automated Remediation: Turning Decisions Into Fixes

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

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

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

Decisions become code almost instantly without any lag.

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

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

Results: Fewer Arguments, Faster Fixes

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

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