Per-Finding Triage State in Vexta

Vexta's per-finding triage state answers where a specific bug stands, in its own words: open, submitted, duplicate, paid, wontfix, or ignored, plus a free-form note and an assignee, tracked separately for every single finding. Vexta is VITI Security's agentless, AI-augmented vulnerability scanner and pentest platform, and this state shows up as a status badge on every finding row in the /scans/<id> view without needing to expand anything.

What statuses can a finding carry?

Six values: open, submitted, duplicate, paid, wontfix, and ignored. Each one is operator-managed, meaning a hunter or team lead sets it deliberately rather than Vexta inferring it from scan data. A finding that has been sent to a bounty program's triage queue is submitted; one a program already knows about is duplicate; one that earned a payout is paid; one the program has decided not to fix is wontfix; one that turned out to be a false lead the team has decided to stop tracking is ignored.

That six-value set maps closely to how a bounty submission actually moves through its life: a finding starts open the moment Vexta reports it, moves to submitted once a hunter sends it to the program, and lands on duplicate, paid, or wontfix depending on how the program responds. Keeping that status on the finding itself, rather than in a separate spreadsheet or the bounty platform's own tracker, means the scan data and the outcome live in one place.

How is triage state stored and surfaced?

State lives in a finding_notes table keyed by organization, scan, and finding ID together, which keeps multi-tenant deployments isolated: one organization's triage notes never bleed into another's view of the same underlying finding type. In the dashboard, the current status shows as a badge right in the row header, visible without expanding the row. Expand it, and a text area for the free-form note, a row of action buttons, and an assignee dropdown appear.

Putting the status badge in the row header rather than behind a click matters when a hunter is scrolling a long finding list from a large scan. A quick glance down the list shows which findings are still open, which have already been submitted, and which are done and dusted as paid or wontfix, without opening a single row. That's the difference between a triage session that takes a few minutes and one that means expanding and reading every finding in order to remember where things stand.

Assigning findings to a specific person

The assignee field takes a team-roster email, so a finding can be handed to a specific person the same way it would be assigned in a ticketing system. Combined with the note field, that turns a finding row into a small unit of work: who owns it, what status it is in, and whatever context the assignee or a teammate has added, all attached to that one finding without leaving the scan view.

This is where per-finding triage state stops being a personal habit and starts being a team process. On a two- or three-person team splitting up a large finding list from one scan, an assignee dropdown next to each finding is what keeps two people from independently writing up and submitting the same bug. It also gives a team lead a straightforward way to see who is carrying how much open work at a glance, without a separate spreadsheet mirroring what the scan already knows.

The free-form note pulls its own weight here too. A status of wontfix or duplicate is a single word; the note is where the actual reasoning lives, a link to the program's response, a line explaining why a finding was marked ignored, or a reminder of what still needs manual reproduction before it can move past unverified. Six months later, that note is often the only thing that explains a decision that would otherwise look arbitrary.

Setting triage state from the CLI

The same state is available from the command line: vexta triage --scan ID --finding FID --status STATUS with an optional --note flag. That matters for anyone scripting a workflow around Vexta: updating triage state in a CI job after a bounty platform webhook fires, or bulk-updating a batch of findings after a program review, rather than clicking through the dashboard one finding at a time.

CLI parity also matters for anyone who runs Vexta as part of a larger pipeline rather than sitting in the dashboard all day. A script that pulls status updates from an external system and calls vexta triage for each affected finding ID keeps that external system and Vexta's own record in sync without a human relaying updates by hand between the two.

Between the dashboard and the CLI, the same six statuses, the same note field, and the same assignee mean a team can move between the two without translating anything. A finding triaged from the command line during an automated batch update looks exactly the same, badge and all, the next time someone opens that scan in the dashboard.

Per-finding triage isn't listed against one specific plan tier in Vexta's public feature breakdown; check the pricing page for what's included on your license.