Show HN: Kekkai – Interactive security triage in the terminal
3 comments
+1 on triage being the real problem. Question, when Semgrep surfaces something ambiguous, lets say a SQL query that looks parameterized but the ORDER BY is built elsewhere, what does reviewing that actually look like? I'm wondering how much context you get before needing to jump out to the codebase.
Great question. Right now (v2.0.1), The TUI is optimized for metadata triage. You see the Rule ID, Severity, the full Semgrep message (which often contains the taint trace), and the File/Line location.
The Workflow:
1. I see [High] SQL Injection in db.py:45. 2. If the description is obvious (like a string concatenation), I mark it Confirmed (c) or False Positive (f) right there. 3. For ambiguous cases (like your ORDER BY example where the context is split), I currently keep the TUI open on one side and my IDE on the other. I use the TUI to quickly filter the noise and jump to code only for the complex ones.
We are actually adding a Syntax widget to render the surrounding 10 lines of code and the taint trace directly in the TUI so you don't have to alt-tab, this is coming in v2.1. But for now, we prioritize keeping the interface snappy.
1. I see [High] SQL Injection in db.py:45. 2. If the description is obvious (like a string concatenation), I mark it Confirmed (c) or False Positive (f) right there. 3. For ambiguous cases (like your ORDER BY example where the context is split), I currently keep the TUI open on one side and my IDE on the other. I use the TUI to quickly filter the noise and jump to code only for the complex ones.
We are actually adding a Syntax widget to render the surrounding 10 lines of code and the taint trace directly in the TUI so you don't have to alt-tab, this is coming in v2.1. But for now, we prioritize keeping the interface snappy.
It’s open source (Apache 2.0) and Written in Python/Textual.
As an AppSec engineer, I’ve spent a lot of time running and tunning open-source security scanners like Trivy, Semgrep, Gitleaks and Dojo. What I have found is that running them is easy, reviewing the results, not so much. Each tool outputs different JSON, false positives pile up, and CI either becomes noisy or blocks everything.
So I built Kekkai (formerly Hokage), a small open-source CLI that wraps these scanners and focuses specifically on human triage.
Kekkai runs the scanners in isolated Docker containers, normalizes their outputs into a single format, and provides an interactive terminal UI to review findings, mark false positives, and save decisions locally.
You can try it out:
``` pipx install kekkai-cli kekkai scan kekkai triage ```
What it currently does:
- Runs Trivy (dependencies), Semgrep (code), and Gitleaks (secrets) - Normalizes findings into a unified report - Provides a keyboard-driven TUI for reviewing and marking findings - Supports .kekkaiignore for false positives - Has a CI mode with severity-based failure thresholds
Design choices:
- Local-first by default (no SaaS required) - No proprietary scanning logic, it sits on top of existing tools - Scanners run in read-only, no-network Docker containers
This is still early and aimed at individual developers and small teams. The next things I’m working on are persistent triage state across runs (baselines) and better PR-level workflows.
Repo and docs: https://github.com/kademoslabs/kekkai
I’m around to answer questions about tradeoffs, limitations, or why this exists at all.