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.
I’m one of the creators of Hokage. We built this because we were tired of the usuall spreadsheet hell that comes with running open-source security tools at any reasonable scale.
If you are a small-to-mid-sized team, you likely use tools like Semgrep, Trivy, or Gitleaks. They are great scanners, but they all output different formats, don’t talk to each other, and result in hundreds of duplicate findings that make triage impossible.
Hokage is a self-hosted orchestration layer that attempts to fix this. It runs your scanners and normalizes the output into a Canonical Finding Schema (CFS). This allows us to:
1. Deduplicate findings (e.g., if a linter and a SAST tool find the same bug, we merge them).
2. Provide a single dashboard for triage across multiple repos.
3. Standardize fields (severity, confidence, location) regardless of the underlying engine.
This is an Alpha (Public Preview). It is not feature-complete, and the UX is still rough around the edges. We are releasing now because we need feedback on the data model:
1. Does our canonical schema cover your use cases?
2. Is the deduplication logic too aggressive?
3. Which scanners should we write adapters for next?
You can spin it up locally with Docker Compose to test it out. We’d love to hear your thoughts (and criticism) on the approach.