Triage is where backlogs are born. Checkmarx Triage & Remediation Assist is how they’re cleared.

Where do application security programs lose time and create a backlog? Not in the detection itself, but in the gap between detection and an approved fix.

Every finding that reaches your team opens four questions before anyone can act on it:

1. Can the vulnerable path actually be reached?
2. Can the condition be exploited?
3. Do existing safeguards change the answer?
4. What code change will close the risk without breaking the application?

Detection only surfaced the problem. Four questions, four brakes, and every one has to come off before the finding moves and the queue clears. A finding may be technically correct and still sit untouched because the people receiving it lack enough evidence to act. AppSec investigates. Development reconstructs the same context. The ticket moves, but the risk does not.

Checkmarx Triage & Remediation Assist is built for that gap. Here’s the process within Checkmarx One:

• Triage Assist evaluates eligible findings for reachability and exploitability.
• Remediation Assist generates suggested code changes for supported vulnerabilities.
• Risk Orchestration keeps the finding, analysis, proposed fix, and decision history attached to the same risk record.

The rest of this article follows a single finding through all three, starting where every decision starts: with the path.

Start with the path, not the label

The path starts in Risk Orchestration, the Checkmarx One view that consolidates findings from the latest project scan. A reviewer can group, filter, sort, and configure the table around the attributes that matter to the investigation, then open one finding without leaving the working view.

For a SAST result, the Issue view supplies the technical spine of the case: the affected file and line, a syntax-highlighted code excerpt, and, in Full Details, the complete attack vector from source through intermediate nodes to sink. Checkmarx also marks the Best Fix Location, the point in the flow where the vulnerability can be addressed most efficiently.

That foundation matters. The AI agent is not reasoning from a vulnerability title pasted into a chat window. It is working from a finding with a stable technical identity and an established data-flow path. Severity describes potential impact. The attack vector shows how data moves. The next question is whether this specific path represents a concrete risk in this application. In other words: is it Attackable?

Severity is the wrong question. Attackability is the right one.

On an eligible SAST risk, a reviewer can select Triage with AI directly from the Risk Orchestration side panel.

Triage Assist evaluates whether the vulnerable method is reachable and whether the condition is exploitable, and it checks whether masking or sanitization measures prevent exploitation. Reachable, exploitable, unmitigated: those three conditions are what make a finding Attackable. The output is not another generic severity score. It is a risk assessment tied to this finding.

The resulting summary and reachability and exploitability analysis appear in the Info tab. When the finding is both reachable and exploitable, AI Triage sets the state to Confirmed. When it determines that the finding is not reachable or not exploitable, it sets the state to Proposed Not Exploitable. An AI indicator beside the state makes the automated decision visible.

Proposed is an important word. Proposed Not Exploitable is not a final false-positive determination, and it does not remove the finding from reporting. It indicates that the available analysis suggests the risk is not reachable or exploitable and should be reviewed before the team makes a final disposition. A reviewer can inspect the AI rationale, validate it against the application’s expected lifecycle and deployment conditions, and then retain the proposed state, return the finding for further investigation, mark it Confirmed, or, when the team is certain that it poses no present or future risk, change it to Not Exploitable. The agent proposes. The human disposes.

AI state changes also follow the platform’s rules for identical findings. For SAST, identity is based on a shared Similarity ID or Attack Vector ID, depending on account settings. The triage change carries into subsequent scans and applies retroactively to identical SAST results in earlier scans. A decision therefore becomes operational memory, not a conclusion one analyst has to recreate every time the scanner runs.

This is where the backlog stops regenerating: the same finding does not come back for a second verdict.

That propagation model differs for SCA. Checkmarx considers SCA results identical when they share the same package version and package manager. AI Triage changes carry into identical SCA results found in subsequent scans, but unlike SAST, they are not applied retroactively to previous scans. Triage & Remediation Assist supports eligible SAST and SCA findings overall; the manual Triage with AI and Remediate with AI controls in Risk Orchestration are currently available only for SAST risks.

Remediation is a separate, reviewable decision

A Confirmed finding is still not fixed. Triage answers: should we act? Remediation answers: what should change? Keeping those actions separate is a control, not friction. It prevents a risk classification from quietly becoming a code change.

For an eligible SAST finding, the reviewer can explicitly select Remediate with AI. Remediation Assist then generates a suggested code fix. Inside Remediation > AI Remediation, Checkmarx One presents a summary, the actual proposed code changes, and an expandable explanation organized around three practical questions: What is the issue? Why should it be fixed? How should it be fixed?

The center of this workflow is SCM-neutral. Across supported project types, Checkmarx One provides remediation guidance. The responsible engineer can inspect the proposed change, compare it with the finding and triage rationale, test it, refine it, or reject it, then move it through the organization’s existing code-change and approval process.

The final delivery step depends on the integration. For GitHub Code Repository Integration projects, Checkmarx can create a separate pull request containing the suggested fix. For other SCM integrations and manual projects, remediation remains available inside Checkmarx One, but Checkmarx does not automatically create a remediation pull request. In either model, the proposed change remains subject to human review and the organization’s existing approval controls. Nothing in this workflow automatically merges code.

The risk record becomes the evidence trail

The most important technical distinction is where the outputs live. Triage and remediation are not transient answers in a separate AI conversation. They surface in the same places the team already uses to manage the finding:

• The results table shows the current state and identifies AI-driven state changes.
• The Info tab holds the triage summary plus the reachability and exploitability analysis.
• The Remediation tab holds the suggested fix and its what, why, and how explanation.
• The Change Log records the previous and new state, any severity change or note, the actor, and the timestamp. AI-driven changes are attributed to AI Assist, with the reasoning available for review.

That record lets the team answer three questions later: Why did this finding matter? What change did the system propose? How did the risk state change?

AI is a visible participant in the workflow, not an invisible co-author. The people accountable for the application still make the final acceptance of risk and code.

Scale the decision, not uncontrolled code change

One manual investigation proves the experience. Enterprise value depends on repeating it selectively. Checkmarx One can run AI Triage automatically when a scan completes, scoped by project, branch, scanner, risk status, and severity, with administrators controlling which of those a project team can override.

The boundary is explicit: automated configuration runs AI Triage, not AI Remediation. A team can automate the repeatable analysis that keeps a backlog current without granting the system an open-ended mandate to change code. Remediation remains a separate, human-initiated action.

Consumption is governable too. Both actions draw on Checkmarx Credits, triage does not re-run or re-charge on an identical finding, and administrators can see burn rate and projected depletion before deciding where to point the capability next. Configuration and credit details are in the documentation.

Measure the operating loop, not the demo

A convincing demo ends with a suggested fix. A credible AppSec program asks whether the loop performs at scale. The AI Triage & Remediation dashboard reports activity and adoption across the organization, including total triage and remediation actions, unique developers, estimated developer time saved, activity trends, triage outcomes, remediation results, and the projects using the capability most. Filters let teams examine the data by resource, branch, scanner, time range, tags, and groups.

For an evaluation, measure the process from the scan forward:

• Time from scan completion to an explainable triage decision.
• Reviewer agreement with AI-generated triage outcomes.
• Time from Confirmed risk to a review-ready proposed fix.
• First-attempt resolution after the proposed change is scanned.
• Material rework required before approval.
• Credits consumed per risk moved to resolution.

Checkmarx reports up to 95% faster MTTR and 65%+ of findings fixed on the first attempt. Read those alongside the metric that matters more: whether the open backlog is trending down. A falling MTTR beside a rising queue is a warning, not a win. Results may vary by eligible finding, scanner, repository integration, vulnerability type, language, configuration, and operating baseline. These are outcomes to validate against your environment, not a reason to skip measurement.

The technical shift is from alerts to governed decisions

Triage & Remediation Assist does not replace scanning. It starts with findings generated in Checkmarx One and carries eligible risk forward: from a deterministic code path, to an explainable reachability and exploitability decision, to a suggested fix, to a durable record of how the team acted. Rather than a black-box promise that AI will fix everything, the result is a governed decision loop: establish the path, determine whether the risk is reachable and exploitable, propose a review-ready change, preserve the rationale, and keep approval with the people responsible for the code.

Checkmarx One reduces the distance between finding and fix without requiring every AppSec analyst to reconstruct the same investigation, every developer to decode a context-poor ticket, or any one source code management platform to carry the entire story.

See the governed decision loop in action

Explore Checkmarx Triage & Remediation Assist — see product details and request a demo.