Prove it's exploitable.
Fix it before the exploit.

Severity is what you were told. Exploitability is what we prove.

One finding, seen two ways.

The short version

A finding arrives, gets investigated, and gets closed with the evidence attached to the ticket.

1. 01

   Connect

   Keep the scanners you already run. Konvu reads what they find.

   Connect the scanners you already run

   SnykSemgrepWizBlack DuckTrivyCheckmarx+20 more

   Drive it from anywhere

   REST APIkonvu CLIMCP serverKonvu Dashboard

2. 02

   Enrich

   What each service exposes and what it handles, joined to our vulnerability database, where the conditions that make each CVE exploitable are written down.

   Risk profile

   Crown jewel

   payments-api

   Exposure

   100/100

   Internet exposedServes web UIInternal network reachable

   Access

   54/100

   SSO · open enrollmentMFA · not enforcedACL · none

   Stakes

   100/100

   SecretsCustomer dataCloud credentials

   Blast radius

   37/100

   Single tenantNo shared datastoreIAM role · scoped

   Attackers

   100/100

   In CISA KEVRansomware · active useExploit PoC · public

   6 findings here outrank 240 on internal-tools, none of which touch a crown jewel.

   konvu·3m 41s·47 tool calls

3. 03

   Prove

   The verdict, with the reasoning trail and the code that decided it. One finding proved exploitable, one proved not, because a verdict only counts if it can come back either way.

   minimatch: catastrophic backtracking on nested extglobs

   HighEPSS 0.31% p55CVSS 7.5CVE-2026-27904 · minimatch 9.0.3

   False positive

   The bug needs a nested *() pattern to build the backtracking regex. Every pattern here is read from config at boot, so the attacker never supplies one.

   minimatch() on a request pathyes, src/api/files.ts:64

   Attacker controls the inputyes, the upload filename

   Attacker controls the patternno, static from globs.json← decides it

   konvu · 3 conditions testedDismissed in Dependabot

4. 04

   Fix

   Breaking changes found, call sites rewritten, tests re-run until the branch is green. False positives are dismissed straight back in the scanner that raised them.

   PR #1284/fix/CVE-2021-23337→main

   1. ✓lodash 4.17.21 blocked@acme/report-kit pins <4.17.21
   2. ✓report-kit bumped to 3.0.0one major, per its migration guide
   3. ✓Breaking changes found2 call sites use the removed renderSync
   4. ✓Call sites rewrittensrc/reports/render.ts, src/api/orders.ts
   5. ✕Test run 1 failed3 failing, snapshot expected the old shape
   6. ✓Test run 2 green1,284 passed, 0 failed

   PR merged, finding closed in the scanner, evidence on the Jira ticket.

   konvu · 8m 40s · 2 test runs

5. 05

   Prevent

   A missing ownership check has no dangerous call for a scanner to flag. Konvu learns your authorization model and hands it to the coding agent before it writes.

   ●●●your coding agent

   > add a GET /orders/:id endpoint

   ✻ konvu · 1 rule loaded into context

   ⎿handlers that load a record by id from the request must assert the caller owns it

   ⎿inferred from 34 handlers · no rule file to maintain

   ⏺ Update(src/api/orders.ts)

   ⎿ export async function getOrder(req, res) {
       const order = await orders.findById(req.params.id)
     +   assertOwnership(req.user, order)
       return res.json(order)
     }

   ✓ ownership check written, not caught later

   >

   konvu guardrails · the check ships with the feature

Where a frontier model stops

We build on frontier models and they keep getting better. Four things they still won't do for you.

1. 01

   The question is narrower than the model

   Is this vulnerability exploitable in this environment? Answering that needs almost none of a frontier model’s breadth. Narrow and deep beats wide and brilliant.

2. 02

   The conditions were never written down

   Which function has to be called, with what input, under which configuration, in what deployment. For most vulnerabilities nobody ever recorded it, so no model learned it. We maintain a vulnerability database enriched with exploitability conditions, built one vulnerability at a time.

3. 03

   Models declare victory too early

   A model that says “not exploitable” after an incomplete investigation produces a false negative that looks exactly like a clean verdict. Nobody pushes back, because nobody knows there was more to check. So the supervision lives in the system: bounded tasks, and verdicts that carry their evidence.

4. 04

   Graded on exploits, not on approval

   Preference training rewards answers people rate highly. An exploitability verdict is right or wrong whether or not anyone liked reading it. We grade against ground truth our own security engineers labelled.

Proof from real deployments

All three companies are anonymised at their request. The numbers are not. Each one ran Konvu against a live backlog its own team had already been working by hand, so the comparison is against trained security engineers rather than against nothing.

4%

exploitable and worth an engineer’s time

Read the case study

96%

assessed as false positives, each with written reasoning

Read the case study

4x

faster remediation on exploitable findings

Read the case study

Recognition

"The platform delivers two key outcomes: vulnerability prioritization and remediation, and is well positioned to solve both effectively."

James Berthoty, Founder at Latio

Read the full report →

Fits the stack you already have

Konvu Agents write verdicts back into your scanners, open PRs in GitHub, and ping your Slack. Drive the whole thing from the REST API, the konvu CLI, or an MCP server your own agents call. No new dashboard. No rip-and-replace.

You decide what leaves your environment

Two deployment models. Konvu Cloud, or our Kubernetes controller running inside your own cluster, where Konvu never has access to your code.

Point it at your own findings

Connect a scanner and Konvu works through the backlog the same way it worked through the ones above, with evidence on every decision.