ICTX
Run it

Your scanner flags. ICTX shows the proof.

ICTX turns scanner findings into decisions you can check — evidence from your actual code, deterministic rules, and a clear statement of what's still unproven. Not another scanner. Not an agent guessing over your repo.

curl -fsSL https://get.ictx.sh | sh
Read the sample report
sense — keycloak
$ sense run keycloak
▸ reading Opengrep OSS SARIF … 410 scanned · 395 investigated · 383 output
▸ 17 filters · 162 parse warnings · 0 agent investigations
▸ index: none · Java, JavaScript, TypeScript not indexed

   64  needs review           16.7%   promoted security queue
  103  policy queue           26.9%   CI / supply-chain policy
   14  routed out             3.7%    docs / test / tooling / unsupported
  186  likely noise           48.6%   strong evidence
   16  high-confidence review 4.2%    decisive evidence only

✓ 395 findings investigated in 36s · 383 findings output
  next: lens keycloak
$

The problem

Every scan dumps hundreds of findings into your queue. Most are noise, but you can't prove which without reading the code yourself — so triage becomes hours of manual dataflow tracing, developers learn to ignore the PR bot, and every “false positive” you mark dies in a Jira comment. The tools that auto-triage this hand you a confidence score you can't audit. You've been burned by scores before.

How a finding becomes a decision

extracted evidence
FINDING
cwe-89 · sql-injection
SOURCE
request param 'q' → repo.search()
SANITIZER
none on path
FRAMEWORK
Spring Data JPA, @Query bound

A real sample run. Audit the breakdown.

Full Keycloak run using unmodified Opengrep OSS output: 410 scanned, 395 investigated, and 383 output with zero agent investigations.

48.6%

of findings closed as noise — every one on decisive evidence.

36s

to investigate 395 findings, locally.

0

AI-agent calls on the full Keycloak run.

What this run doesn't prove — stated before you find it.

Java, JavaScript, and TypeScript sources weren't indexed for deep evidence in this run, and the corpus skews toward workflow/CI finding classes — among the easier classes to close deterministically. There were 162 parse warnings. That's why the Java/Spring dataflow benchmark exists.

Runs where you work

A local CLI and keyboard-driven TUI over the SARIF you already have

No SaaS onboarding, no code upload, nothing to get approved. Install, point it at a repo, read the verdicts. If your stack isn't listed, it's not supported yet — tell us and we'll say honestly when.

curl -fsSL https://get.ictx.sh | sh
Ingests SARIF from
Opengrep OSSSemgrep OSS
Deep evidence extraction
Java / Spring
On the roadmap
CodeQL importer (in progress)

What ICTX is not

Not a scanner.
Keep the ones you have. ICTX adjudicates their output.
Not an agent roaming your repo.
Deterministic rules decide; the agent breaks ties.
Not a dashboard.
It's a decision layer with a record you can hand to an auditor.
Not asking for your trust.
Every verdict carries the evidence to earn it — or the honest statement that evidence is missing.

Frequently asked questions

The objections we hear most, answered plainly. Still want to argue with a verdict? That's not a support ticket — that's the roadmap.

Email us

It does — for Semgrep findings, as an unauditable verdict inside one vendor's platform. ICTX is scanner-neutral, runs locally, and shows the evidence instead of a score. We publish where we disagree with bundled triage, finding by finding. If you trust the black box, use it. If you've ever been burned by one, check ours.

Drowning in findings? Send us the backlog.

We're taking on five design-partner teams: give us a scanner backlog, get it back stratified — closed with evidence, promoted with reasons, open with stated proof obligations. You audit a random sample. If you dispute our closes, we publish that too.

curl -fsSL https://get.ictx.sh | sh
Become a design partner