Checkmarx's New SAST Engine Isn't About the LLM. It's About What Comes After.

Every major SAST vendor has added an LLM to their scanner and called it next-generation. Checkmarx is betting that the LLM is the wrong place to differentiate — and that the real problem is what happens to findings after the scan runs.

What Happened

Checkmarx unveiled a next-generation SAST engine with a hybrid architecture addressing the core problem in AI-era security scanning: as AI coding tools generate more code, legacy scanners produce more findings — including more false positives — than development teams can act on.

The new engine combines three components: a deterministic rules-based scanner operating on code structure, an LLM trained specifically on security data that interprets code context, and a Finding Analysis Engine (FAE) purpose-built to classify findings as true or false positives before they reach a development team. The orchestration between these three engines, not the LLM itself, is Checkmarx’s stated differentiator.

Why It Matters

The false positive problem is the primary reason SAST adoption stalls in development organizations. Security scanners that generate 50 findings per pull request train developers to ignore them — and when developers ignore security findings, the tool’s value collapses to zero regardless of how accurate its true positives are. LLMs trained on code make this worse before they make it better: they find more issues, including more edge cases and more false positives, amplifying the signal-to-noise problem.

Checkmarx’s positioning is that most SAST vendors are applying the LLM to the detection step — which improves recall but degrades precision. The FAE applies a third stage of analysis specifically to the precision problem: classifying which findings are actionable before exposing them to developers. A finding that reaches a developer should already have been evaluated as a genuine vulnerability in this specific code context, not just a pattern match that triggered a rule.

The context is the AI coding tools flood. Teams using Claude Code, Copilot, or Cursor are generating significantly more code per developer per day than in a pre-AI workflow. The same ratio of false positives per scan now generates a dramatically larger absolute count of noise. SAST tools that were manageable at human coding velocity become unusable at agent-assisted velocity unless precision improves proportionally.

For enterprise developer platform teams maintaining AppSec programs, the agentic development pipeline creates specific pressure: if AI agents are generating and merging code faster than security review can keep up, the SAST tooling in the pipeline needs to match the velocity without generating review fatigue.

What This Means for Platform Engineers

The enterprise-level question is whether the FAE’s false positive reduction actually delivers in production against the specific codebases and languages the team uses. Checkmarx’s architecture is sound; the claims need to be validated against real codebases before procurement decisions.

The open MCP integration mentioned alongside the release suggests Checkmarx is also positioning for IDE-native security feedback — the same direction AWS Security Agent is moving with Kiro and Claude Code integration. For platform teams evaluating AppSec tooling in 2026, the IDE integration path is worth including in the evaluation criteria: security findings that surface inline during development are dramatically more likely to be addressed than findings in a separate dashboard.

Source: The New Stack

Content created with AI assistance and reviewed for accuracy.