How to Triage Vulnerability Reports as a Company Admin
Step-by-step guidance for reviewing evidence, validating severity, assigning reports, communicating with researchers, and reaching a final triage decision.
Triaging is the process of turning a raw researcher submission into a clear, actionable decision — whether that means accepting a valid vulnerability, requesting more information, marking a duplicate, or closing the report with a rejection. Done well, triaging protects your organisation, builds trust with the research community, and keeps your programme running efficiently. This guide walks you through everything you need to do from the moment a new report lands in your inbox to the moment you set a final status.
Every report has a dedicated management page that only company admins can access. You reach it from Reports → My Program Reports by clicking the report title in the inbox table. The management view shows the full report contents, a pre-validation checklist, the CVSS scorer, all comments, attached evidence files, and all available triage actions.
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.
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.
If your programme has a Jira integration configured, a Jira issue creation shortcut will also be available on the management page, pre-filled with the report data.
Once a report is resolved, you may choose to publish it to the Hacktivity feed — Hackrate’s public disclosure mechanism. Disclosing a report to Hacktivity increases programme transparency, rewards the researcher with public recognition, and contributes to the wider security community’s knowledge base.The Hacktivity disclosure option is available from the report management view for admins with SuperAdmin or StandardAdmin access. You control exactly when (and whether) to publish, so disclosure always happens on your terms and timeline.
If new information emerges after you have closed a report — for example, a researcher provides a compelling additional proof of concept after an Invalid rejection, or a Resolved vulnerability reappears in a new release — you can reopen the report using the Reopen action on the management page. This moves the report back to an open status and allows the triage process to continue.
