Triaging Reports

How to use the Kanban triage board, read SLA indicators, assess severity, and resolve or dismiss reports.

Why It Matters

Unstructured triage is where most vulnerability disclosure programs fail. Valid reports get buried in noise, SLA deadlines breach without anyone noticing, and researchers give up on your program. The Kanban triage board gives your team a shared, real-time view of every open report with SLA visibility built in — so nothing slips through.

The Triage Board

Navigate to VDP > Triage Board to see all reports organized by status. Each column represents a stage in the report lifecycle, and each card represents a single report.

The board supports two views:

Board view — Kanban columns with drag-and-drop cards (default)
List view — Sortable table with the same filters

Each report card shows:

Element	Description
Report ID	Prefixed identifier (e.g. `RPT-abc123`)
Title	Vulnerability title, truncated to 40 characters
Severity badge	Color-coded severity tier from assessment
SLA countdown	Time remaining with green/yellow/red indicator
Assignee	Team member avatar, or “Unassigned”
Flags	Duplicate warning or AI screening badge, if applicable

Use the filter bar above the columns to narrow your view:

Severity — Multi-select (Informational through Super Critical)
Assignee — Dropdown (team members + “Unassigned”)
SLA — On Track / At Risk / Breached
Search — Filter by title, report ID, or researcher email

The last three columns (Fix Verified, Paid, Dismissed) are collapsed by default and show only their count. Click to expand.

Report Lifecycle

Every report follows a defined state machine. Drag a card between columns on the board, or use the status controls on the report page’s banner — one primary button for the obvious next step plus a menu of the other valid moves. You can attach a note to any status change (it appears in the timeline), and moving a report backward requires one. Dismissing always asks for a reason: dragging a card into the Dismissed column opens the dismissal modal rather than closing the report silently (see Dismissing Reports).

                                ┌─────────────┐
                           ┌───>│   Dismissed  │
                           │    └─────────────┘
                           │  (from Submitted, Triaged, Needs
                           │   Clarification, Validated, or In Progress)
                           │
┌───────────┐  ┌─────────┐│  ┌───────────────────┐  ┌───────────┐
│ Submitted ├─>│ Triaged ├┴─>│    Validated       ├─>│In Progress│
└───────────┘  └────┬────┘   └─────────┬──────────┘  └─────┬─────┘
                    │                  │                    │
                    v                  v                    v
              ┌───────────────────┐                  ┌──────────┐
              │Needs Clarification│                  │ Resolved │
              └───────────────────┘                  └────┬─────┘
                                                          │
                                                          v
                                                   ┌──────────────┐
                                                   │ Fix Verified │
                                                   └──────┬───────┘
                                                          │
                                                          v
                                                      ┌──────┐
                                                      │ Paid │
                                                      └──────┘

Status	Meaning
Submitted	Initial state after a researcher submits the intake form
Triaged	Team has reviewed the report and begun assessment
Needs Clarification	Team sent a question; waiting on the researcher’s response
Validated	Confirmed as a real, in-scope vulnerability; fix work begins
In Progress	Engineering fix is underway
Resolved	Fix deployed; researcher notified
Fix Verified	Researcher confirmed the fix works (optional retest step)
Paid	Bounty disbursed and lifecycle complete
Dismissed	Closed without a fix — can happen from Submitted, Triaged, Needs Clarification, Validated, or In Progress

Two special transitions to note:

Dismissed can be reached from Submitted, Triaged, Needs Clarification, Validated, or In Progress (not from Resolved or Fix Verified). The researcher is always notified with a reason. If the report has an approved bounty, dismissing it also revokes the bounty — see Dismissing Reports below.
Dismissed > Submitted reopens a report if the dismissal was made in error. Reopening does not reinstate a revoked bounty — approve a new one manually once the report is validated again.

Every status transition is logged in the report’s audit trail with the actor, timestamp, and optional comment. For details on sending messages to researchers at each stage, see Communicating with Researchers.

SLA Indicators

Each report card displays an SLA badge so your team can spot overdue work at a glance. The acknowledgment SLA clock starts the moment a report is submitted.

Badge	Color	Meaning
On Track	Green	Well within the SLA window
At Risk	Yellow	SLA deadline is approaching — act soon
Breached	Red	SLA deadline has passed

Use the SLA filter on the triage board and select Breached to immediately surface reports that need attention. SLA targets are configured per severity level in VDP > Program Settings > SLAs.

AI Screening

Every submitted report is automatically screened for low-effort, AI-generated content before it reaches the triage board. The screening runs in the background and attaches its results to the report within seconds.

The screener checks for signals that indicate mass-produced or fabricated reports:

Signal	What It Detects
Hallucinated functions	References to function names, API methods, or file paths that are plausible but likely invented
Fabricated CVEs	CVE numbers that do not exist in public databases
Cited previous CVE as new	A known, publicly disclosed vulnerability presented as a new finding
No specific PoC	No proof-of-concept, no target-specific steps, no expected vs. actual output
Vague reproduction steps	Generic steps like “navigate to the login page and enter a payload” that could describe any application
Template language	Canned phrases like “As a security researcher, I discovered…” without target-specific context
Template structure	Rigid numbered sections and bold headers suggesting copy-paste from a report generator
Generic remediation	Boilerplate advice like “sanitize all inputs” with no target-specific guidance
Inconsistent technical details	Technologies, frameworks, or versions that do not match the target endpoint
References nonexistent code elements	Fabricated commit hashes, function names, or file paths that cannot be verified

The screening produces a confidence score (0–100) and a recommendation:

Recommendation	Score Range	Effect
Pass	0–30	Report appears on the board normally
Review	31–60	Report appears with a subtle review badge
Flag	61–100	Report is marked with an AI screening badge on the Kanban card

AI screening never auto-rejects a report. Flagged reports remain fully visible and triage-able — the badge simply alerts your team that the content may warrant extra scrutiny. Your team always makes the final call.

Assessing Severity

Open a report and click Assess to score it using CVSS v3.1. The embedded calculator walks you through eight metrics:

Metric	Options
Attack Vector	Network, Adjacent, Local, Physical
Attack Complexity	Low, High
Privileges Required	None, Low, High
User Interaction	None, Required
Scope	Unchanged, Changed
Confidentiality Impact	None, Low, High
Integrity Impact	None, Low, High
Availability Impact	None, Low, High

The system automatically computes the base score and maps it to a severity tier:

Tier	CVSS Range
Super Critical	10.0
Critical	9.0–9.9
High	7.0–8.9
Medium	4.0–6.9
Low	0.1–3.9
Informational	0.0

Once assessed, the severity tier unlocks a suggested bounty range from your bounty matrix. The CVSS vector string is stored on the report and shown in the audit trail. If the severity is Critical or Super Critical, an escalation notification is sent to your configured escalation contacts.

Dismissing Reports

Open a report and click Dismiss to close it without a fix. You must select a reason:

Reason	When to Use
Out of Scope	The target is not covered by your scope configuration
Duplicate	The same vulnerability was already reported — link to the original
Not Reproducible	Your team could not reproduce the issue with the provided steps
Informational	No exploitable vulnerability; the reporter is sharing a general finding
Spam	Automated or clearly low-effort submission
AI Slop	AI-generated content with fabricated or hallucinated details

Add an optional note to explain the decision. The researcher receives an email using your configured dismissal template with the reason and note included. The dismissal reason is permanently logged in the audit trail and cannot be edited after saving.

Dismissing a Report with an Approved Bounty

If the report has an approved bounty, dismissing it also revokes the bounty. The dismissal modal shows an amber warning with the amount, who approved it, and when, and the submit button changes to Dismiss & revoke $X bounty. The revocation is recorded as a bounty_revoked entry in the immutable ledger, and the dismissal email tells the researcher the bounty has been withdrawn and will not be paid — the standard appeal flow remains their recourse. See Bounties and Payouts for details.

Two safeguards apply:

A bounty whose disbursement is Completed (paid) can never be revoked.
A payout in flight (disbursement Pending or Processing) blocks dismissal — mark the disbursement as failed first, or let it complete.

Dragging a card into the Dismissed column on the board opens this same dismissal modal — reason picker and, when a bounty is approved, the revocation warning — so a board drag never dismisses a report (or revokes a bounty) without that context. It is the same flow as the Dismiss button on the report page.

If a dismissal was made in error, you can reopen the report from the Dismissed column, which returns it to Submitted status. Reopening does not reinstate a revoked bounty — approve a new one manually once the report is validated again.

Resolving Appeals

When a researcher appeals a decision (see The Researcher Portal), a Researcher appeal panel appears on the report page with the researcher’s justification, and the on-call responder is paged with an alert that links straight to it.

From the panel, an admin resolves the appeal:

Accept — you agree with the researcher. If the report was dismissed, accepting reopens it and returns it to Submitted (triage) through the same audited reopen path described above. The researcher is emailed that the appeal was accepted.
Reject — you uphold the original decision. The researcher is emailed that the decision stands.

The decision, the reviewer, and the timestamp are recorded on the report and added to its timeline. As with reopening, accepting an appeal does not reinstate a revoked bounty — approve a new one once the report is validated again.

Assigning Reports

Click the assignee avatar (or “Assign”) on any report card or detail view to assign a team member. The assignee receives an in-app notification and an email.

When auto-assign is enabled, incoming reports are automatically assigned to the on-call person. If no one is on-call, the default assignee is used as a fallback. See On-Call Rotation for details on configuring shifts and schedules.

For bulk assignment, select multiple report cards using their checkboxes and choose Assign from the bulk actions bar that appears at the bottom of the board.

Critical and Super Critical reports automatically send an escalation email to your configured escalation contacts, regardless of assignment. Configure escalation contacts in VDP > Program Settings > Triage.

Bulk Operations

Select multiple report cards using their checkboxes to enter bulk-select mode. A floating action bar appears at the bottom of the board with three options:

Action	Description
Assign	Assign all selected reports to a team member
Dismiss	Dismiss all selected reports with a shared reason
Change Severity	Update the severity tier on all selected reports

Bulk dismiss requires you to pick a single reason that applies to all selected reports. Reports with an approved bounty are skipped — the confirmation notice shows how many were skipped — because revoking a bounty requires the Dismiss modal on the individual report page. Each bulk operation is logged individually in every affected report’s audit trail.

Quick Checklist

Review the Triage Board daily for new submissions
Check the “Breached” SLA filter for any overdue reports
Assess severity (CVSS) on every validated report
Assign reports to team members with domain expertise
Dismiss clearly invalid reports promptly to keep the queue clean
Use “Needs Clarification” when reproduction steps are insufficient
Review AI-flagged reports with extra scrutiny before dismissing or validating

Next Steps

Communicating with Researchers — message threads, email templates, Slack notifications, and asking @KitBot about reports
Bounties and Payouts — awarding bounties, tax documents, and the financial ledger