Vektor

Problem

At the scale of a large engineering organization, static analysis stops being a detection problem and becomes a triage problem. Each engine has a different sweet spot: CodeQL’s data-flow analysis, OpenGrep’s fast pattern coverage, Joern’s code property graphs. Run them all and you multiply findings — most of them duplicates or false positives — until developers stop reading the reports.

Architecture decision

Vektor treats the engines as complementary sensors rather than competing products. Findings are normalized into a common model, deduplicated across engines, and then passed through an LLM-based false-positive filter that reasons about reachability and context before anything lands in a human queue. The critical constraint: every suppression must stay inspectable. The filter records why it downgraded a finding, so the decision can be audited and the filter itself can be evaluated.

Outcome

Evaluation set, per-engine precision baselines, and triage-time comparisons are being prepared for publication. Until those numbers are verified, this page intentionally makes no quantitative claims.