ICTX vs Semgrep Assistant: auditable evidence or a score inside one platform

We get this question in almost every conversation, usually in this form: Semgrep Assistant already triages a large share of findings inside a platform we already pay for — what is left for you to do?

It is a fair question and it deserves a fair answer rather than a competitive one. Assistant is a good product built by people who understand this problem. The differences that matter are structural, and for some teams they point at Assistant.

What Assistant does, and does well

Semgrep Assistant is AI triage built into Semgrep’s AppSec Platform. It reviews findings the scanner produces, recommends whether each is a true or false positive with a short natural-language rationale, proposes fixes, and can carry context you give it — component ownership, notes about your codebase — into later triage. Their documentation describes the current capabilities and the agreement figures they publish; read it there rather than taking our summary of it.

Three things it genuinely gets right, and we would say the same in front of them.

• It is where the findings already are. If your team runs Semgrep in CI and lives in that dashboard, triage arriving in the same view with zero integration work is worth a great deal. Adoption friction is the reason most good security tooling never gets used, and Assistant has none of it.
• It covers the whole rule surface. Assistant reasons about any finding Semgrep produces, in any language Semgrep supports. That is broad, and it is broader than us — see the limitations section below.
• Remediation is in scope. Suggested fixes are a different and harder problem than deciding whether a finding is real, and we do not attempt it. If what you want is a smaller queue and a PR, that is a coherent product and we are not it.

Where the verdict stops being checkable

Here is the actual disagreement, and it is narrow. Assistant’s output is a recommendation with a rationale written by a model. The rationale is readable — it names files and reasoning in prose — but it is a description of a conclusion, not the derivation of one.

In practice that means three things you cannot do with it.

• You cannot re-derive the verdict. There is no rule that fired on a stated fact. To check the recommendation you go read the code, which is the work you were trying to compress.
• You cannot diff two runs meaningfully. If a verdict changes between scans, you cannot separate “the code changed” from “the model answered differently this time.” A deterministic engine gives you that separation for free; we made the full argument for it separately.
• You cannot invalidate a close later. A verdict that rests on a stated assumption reopens when the assumption breaks. A verdict that rests on a rationale has nothing to trip.

None of that is a defect in Assistant’s execution. It is what a model-first architecture is: the reasoning happens inside the model and what comes out is a summary of it. We chose the other architecture and pay for it in coverage.

For contrast, here is what our side of the same finding looks like. We are deliberately not printing a mock of Assistant’s output next to it — inventing a competitor’s artifact to lose a comparison is the oldest trick on a page like this. Go look at theirs in their docs.

VERDICT  close                      CWE-89  ReportController.java:52
  rule            constrained-input
  decisive signal value constrained to ^[a-z_]{1,32}$
  evidence        ReportRequest.java:31       @Pattern
  enforced at     ReportController.java:52    @Valid on parameter 0
  sink class      SQL identifier position     ReportService.java:88
  assumption      constraint stays on the field
  agent           not invoked

Every line is a fact with an address. That is the whole difference, and whether it is worth the coverage we give up to produce it is a real question with a real answer for your team, not ours.

The two structural differences

Scanner-neutral versus in-platform. Assistant triages Semgrep findings inside Semgrep’s platform. That is the right design for a team standardised on Semgrep and the wrong one for the common case we keep meeting: a team running an open-source scanner in CI, a legacy commercial backlog nobody will migrate, and CodeQL on two repositories. ICTX reads SARIF, the OASIS interchange format, so the triage layer is not tied to which scanner produced the finding. Today that means Opengrep and Semgrep OSS output, with a CodeQL importer in progress — the honest list, not the aspirational one.

Local versus cloud. ICTX is a CLI and TUI that runs on your machine; the deterministic path uploads nothing. That matters less for the security properties than people assume and much more for whether you can try it — no vendor review, no data-handling conversation, no procurement. Assistant’s data handling is documented in their privacy documentation, and if that question is live for you, read it rather than either vendor’s characterisation of it.

Which one you should use

Use Assistant if you are standardised on Semgrep, you want coverage across every language it scans, you want suggested fixes, and a well-argued recommendation you would spot-check is enough for how your team closes findings.

Use ICTX if your findings come from more than one scanner, your stack is Java or Spring where our evidence is deepest, and you need every close to carry a signal someone can check — because a pentest, an auditor, or your own postmortem process will ask.

They are also not exclusive. Running Semgrep, letting Assistant work the queue, and running ICTX over the same SARIF is a legitimate setup, and the findings where the two disagree are the most interesting ones in your backlog.

Where we disagree with bundled triage

This section is where the case-by-case log goes: findings where our verdict differs from a platform’s own triage, with both evidence trails published side by side so you can decide who is right.

It is empty, and it stays empty until we have 10 documented cases. Publishing three cherry-picked disagreements would be exactly the kind of unverifiable claim this page argues against, and a comparison page is the easiest place in the world to cheat. If you run both and hit a finding where the verdicts differ, send it to us — that is how this section gets written, and we will publish the ones where we turn out to be wrong.

Limitations of this comparison

• We are not a neutral party. We build one of these two things. Everything above is written to be checkable against primary sources rather than believed — the links go to Semgrep’s own documentation for a reason.
• We have not benchmarked the two side by side. No head-to-head numbers appear on this page because we do not have any worth publishing. When we do, they will come with the sample, the method, and the disagreements.
• Our coverage is much narrower. Deep evidence extraction is Java and Spring today. JavaScript and TypeScript are not indexed. If your codebase is mostly either of those, Assistant covers ground we simply do not.
• Assistant is a moving target. This was written in August 2026 against the documentation linked above. Product capabilities change; the docs are authoritative and this page is not.

Check it yourself

The only claim on this page we would ask you to take seriously is the one you can test in ten minutes: take a finding, look at what each tool hands you, and ask whether you could defend the close to someone who disagreed with it.

How it works shows what our evidence trail contains, and the directory lists every run we have published with its limitations attached. If you think this comparison is unfair in either direction — including to Semgrep — write to us at hello@ictx.sh and we will correct it.