ICTX and Semgrep Assistant: two approaches to scanner triage

Semgrep Assistant and ICTX start with the same practical problem: scanner output creates more findings than a team can investigate by hand. They make different tradeoffs, and the right choice depends on the workflow your team already has.

This is a narrow comparison of documented capabilities and the current ICTX product. It is not a head-to-head benchmark.

What Semgrep documents

Semgrep describes Assistant as AI triage inside the Semgrep AppSec Platform. It reviews findings, recommends a classification with a rationale, proposes fixes, and can use context such as ownership and codebase notes. Read the current Assistant documentation for the authoritative product description.

That platform path is useful when Semgrep is already the place where your team runs findings and manages the queue. Suggested fixes and broad language coverage are also meaningful if those are the problems you need to solve.

What ICTX does today

ICTX reads supported scanner output in SARIF, attaches evidence from code and configuration, and applies deterministic rules where the evidence supports a decision. Findings without decisive evidence stay open with the missing question stated. An agent can help investigate genuinely ambiguous cases.

The working product is a local CLI and keyboard-driven review interface. Today the supported scanner inputs are Opengrep OSS and Semgrep OSS, with deep evidence extraction for Java and Spring. A CodeQL importer is in progress.

The useful difference is the artifact beside a decision. ICTX records the evidence and the signal that supports the classification. That makes the result easier to inspect. It does not guarantee correctness, complete coverage, or reproducibility of every future run.

Different fit, not a universal winner

• Choose Assistant when the Semgrep platform, its coverage, or its suggested fixes match your existing process.
• Evaluate ICTX when findings come from more than one supported scanner, your stack is Java or Spring, and you want the evidence behind a decision in a local review workflow.
• You can also compare both on the same SARIF. The output will reflect different scopes and different ways of recording a judgment.

Where a decision can change

A decision that depends on a stated condition may need another look after software changes. Preserving those conditions and identifying affected decisions is a proposed next step for ICTX. It is not an available change-monitoring feature today.

No comparison result is published here. The case-by-case disagreement log remains empty until the documented evidence exists.

Limits of this comparison

• We build ICTX, so this is not neutral. The Semgrep links point to Semgrep's own documentation.
• We have not published comparable samples, versions, or a method for resolving disagreements.
• ICTX has narrower current coverage. JavaScript and TypeScript are not indexed in the Keycloak sample, and agent-path data handling is still being documented.

See the current workflow

How it works shows the ICTX workflow against real screenshots. The directory lists summaries with their limitations. Use those pages to decide whether the current first step fits your work.