Software changes. Your assurance should keep up.
We're building a way to preserve the reasoning behind security decisions and check whether it still holds as software changes. We're starting with scanner triage. Today, ICTX turns findings into decisions you can inspect, with evidence from your code.
curl -fsSL https://ictx.sh/install | sh$ sense run keycloak ▸ reading Opengrep OSS SARIF … 454 scanned · 439 investigated · 427 output ▸ partial scanner success · 218 parse warnings · 0 agent investigations ▸ Java and Python are indexed; JavaScript and TypeScript are not indexed. 114 needs review 26.7% promoted security queue 103 policy queue 24.1% CI / supply-chain policy 15 routed out 3.5% docs / test / tooling / unsupported 179 likely noise 41.9% strong evidence 16 priority review 3.7% strong evidence · confirmation pending ✓ 439 findings investigated in 69s · 427 findings output next: lens keycloak $
Our first step
Explain the finding.
A scanner flags a possible problem. Someone still has to trace the code, check the configuration, and decide what the finding means. ICTX brings that evidence into the review.
How a finding becomes a decision
Help your team trust, or challenge, what its SAST tools report, finding by finding.
- FINDING
- cwe-89 · sql-injection
- SOURCE
- request param 'q' → repo.search()
- SANITIZER
- none on path
- FRAMEWORK
- Spring Data JPA, @Query bound
Run it on your repo
A local CLI and keyboard-driven TUI over the SARIF you already have
A local CLI and keyboard-driven review interface for the scanner output you already have. The deterministic path runs on your machine. Current support is limited to the list shown here.
curl -fsSL https://ictx.sh/install | sh- Ingests SARIF from
- Opengrep OSSSemgrep OSS
- Deep evidence extraction
- Java / Spring
- On the roadmap
- CodeQL importer (in progress)
A first step you can inspect.
The Keycloak sample shows how the current workflow classifies findings and explains its decisions. It covers 454 scanned findings, 439 investigations, and 427 output findings.
See how it worksof 427 output findings closed as likely noise in this sample.
for 439 investigations in this sample.
agent investigations in this sample.
What this run doesn't prove, stated before you find it.
Java and Python are indexed; JavaScript and TypeScript are not indexed. This run reports partial scanner success and 218 parse warnings. A smaller review queue does not mean the entire codebase was proven safe. The Java/Spring dataflow benchmark remains a separate check of deeper coverage.
Frequently asked questions
Practical questions about what works today, how decisions are made, and where the current workflow stops.
Evidence-backed scanner triage on supported stacks. ICTX classifies findings and lets you inspect the reasons. Preserving decisions across changes and revalidating them are proposed next steps.
Proposed direction
What if a decision could tell you when it needs another look?
We want to preserve the reasons behind a security decision and identify changes that require renewed review. That capability is not available yet.
Working today
Explain scanner findings
ICTX attaches evidence from code and configuration to supported scanner findings and produces decisions a person can inspect.
Proposed next step
Revalidate earlier decisions
We want to preserve the reasons and assumptions behind a decision, then identify changes that require renewed review.
Longer-term direction
Keep important constraints current
The same approach could support security, privacy, architecture, and developer or agent workflows. Each extension needs its own evidence.
Illustrative future scenario: a finding was dismissed because callers passed input through validation. If a later change bypasses that validation, the earlier decision would need another look. This is a hypothesis to test, not a current feature.
Who is building ICTX
We're cybersecurity leaders, operating in stealth and building our first product toward a larger vision.