Vulnerability Disclosure

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 Triage dropdown on the report detail page to advance its status.

                                ┌─────────────┐
                           ┌───>│   Dismissed  │
                           │    └─────────────┘
                           │  (from any active status)
                           │
┌───────────┐  ┌─────────┐│  ┌───────────────────┐  ┌───────────┐
│ 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 any active status

Two special transitions to note:

Dismissed can be reached from any active status. The researcher is always notified with a reason.
Dismissed > Submitted reopens a report if the dismissal was made in error.

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. Resolution SLA starts when a report reaches “Validated.”

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	9.5–10.0
Critical	9.0–9.4
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.

If a dismissal was made in error, you can reopen the report from the Dismissed column, which returns it to Submitted status.

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.

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. 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, and Slack notifications
Bounties and Payouts — awarding bounties, tax documents, and the financial ledger