Accessing the report management view
Open Reports → My Program Reports and select a report title. The management page shows the submission, pre-validation assessment, CVSS scorer, comments, evidence, and the actions available to your role.You must have a SuperAdmin or StandardAdmin role for the relevant programme or organisation to triage reports. Read-Only and Analytics roles can view reports but cannot take triage actions such as changing status, adding comments, or awarding bounties.
Step-by-step triage workflow
The Pre-validation card highlights signals that may need manual review. It does not determine whether a finding is valid or set the report’s severity.Review the report header
At the top of the management view you will see three summary cards showing the current Status (with its Open/Closed type), the Target (with its tier), and the Severity the researcher assigned. These give you an immediate at-a-glance orientation before you read the full submission. Also check:- Program — confirms which of your programmes this report belongs to
- Target — the specific asset the researcher tested; verify it is in-scope for your programme
- Reporter — the researcher’s alias; useful context if you have prior interactions with this person
- VDP flag — if the report arrived via an embedded/VDP form, this will be indicated on the report
Review the pre-validation assessment
The card shows a Risk score from 0 to 100. A higher score means the submission contains more suspicious, speculative, or incomplete content; it is not a CVSS score. The card can also show an Assessment, Matched indicators, Positive signals, and suggested Triage checks. Use the suggested checks to guide your review. Confirm the target is in scope, reproduce the reported behavior, examine the evidence, and verify the claimed impact. A missing attachment or a short summary does not automatically make a report invalid.Read the full report content
Scroll through the Details section to read:- Summary — the researcher’s concise description of the issue
- Description — the full technical write-up, including steps to reproduce
- Impact — the researcher’s assessment of business risk
- CVSS — the submitted CVSS vector; you can view and recalculate it interactively on the management page using the built-in CVSS scorer
- Vulnerability type (CAPEC/CWE) — the classification the researcher selected
Assess and adjust severity
The severity the researcher assigned may not match your assessment. If you disagree, you can change it directly from the management view. Severity affects the bounty calculation (if your programme uses a bounty table), so setting it accurately before awarding a payout is important. Severity levels available are: Critical, High, Medium, Low, and None. You can also update the vulnerability type (CAPEC classification) and the CWE type if the researcher’s original selection was imprecise.Assign the report to a team member
If your organisation has multiple admins, assign the report to the team member best placed to investigate it — for example, the engineer who owns the affected system, or the security analyst specialising in the relevant vulnerability class. Use the Assign control on the management page to select from your programme’s admin users. Assigning a report creates clear ownership, prevents reports from falling through the cracks when multiple people are in the inbox, and makes the Assigned To column meaningful in CSV exports.Communicate with the researcher
The management view has a comment system with two distinct modes:- Public comment
- Internal comment
Visible to both your team and the researcher. Use public comments to:
- Ask for clarification or additional evidence
- Confirm that you have reproduced the issue
- Update the researcher on remediation progress
- Explain the rationale for a triage decision
Make the triage decision
Once you have reviewed the evidence, assessed severity, and (if needed) gathered additional information from the researcher, change the report’s status to reflect your decision. The full set of available statuses is described in the Report Statuses reference, but the most common triage actions are:
Always leave a public comment when closing a report, especially with a rejection. A brief, specific explanation dramatically improves researcher experience and reduces disputes.
Mark duplicates correctly
When closing a report as Duplicate or Good quality duplicate, use Duplicate Of to link the original report describing the same vulnerability. Search the dropdown in the duplicate modal for the earlier report, then confirm the affected asset and root cause before selecting it. The report details also show reports already linked as duplicates of the current finding. Review that list before choosing an original report.Award a bounty (if applicable)
If the report is valid and your programme is a paid bug bounty programme, you can award a bounty directly from the management view. See Bounty Rewards for full details on how bounty amounts are determined and how to record the payment. You can also award a bonus on top of the standard bounty for exceptional quality, unique impact, or particularly thorough documentation.Integrations available from the report view
The report management page provides direct access to two external integrations that help bridge your security triage workflow with your engineering and development processes.GitHub Issues
Create a GitHub issue directly from the report. The issue is pre-populated with the report’s title, summary, description, impact, and severity label. Once created, the issue is linked to the report and its current state (open/closed) is shown on the management page.
GitHub Security Advisory
Draft a GitHub Security Advisory from the report. Automatically populated with the report summary, description, impact, affected package/target, and the researcher’s GitHub login (if provided). Advisories are created as private drafts, giving your team time to review before any public disclosure.