Introduction to Reports' Statuses & Stakeholders

A vulnerability report goes through multiple stages of processing, involving several stakeholders who may need to take action depending on the report’s status.

The key stakeholders include:

The Hunter who submitted the report
The YesWeHack Triage team (or your internal triage team), responsible for the bug reproduction & assessment
The Organisation, which ultimately accepts reports and issues rewards

At the end of the workflow, reports will either be deemed as Valid or Invalid:

Statuses' Definition

Invalid Reports

“Duplicate”: the vulnerability exists but has already been reported, either internally or within your bug bounty program. When you select this option, you can select another report ID or select “Internally tracked”.

ℹ️ Duplicate reports will still give ranking points to the hunter.

“Not Applicable” or “Invalid”: the report does not demonstrate a vulnerability.

“Out of Scope”: the vulnerability exists but is outside of the program’s scopes.

ℹ️ Those statuses will give negative points to the bug bounty hunter and should be used if the hunter already submitted a RTFS or Informative report.
It helps to give a warning to the hunter to focus on what’s in scope or rewarded within the bug bounty program.

Those statuses will give negative points to the bug bounty hunter and should be used if the hunter already submitted a RTFS or Informative report.
It helps to give a warning to the hunter to focus on what’s in scope or rewarded within the bug bounty program.

“Spam”: the report is not relevant, does not contain a PoC, or a Hunter submitted the same one several times.

ℹ️ Spam should not be used on a regular basis. It should be only used in rare occasion as it could be considered quite extreme.

“RTFS” (Read The Fine Scope): the report does not follow the program rules, qualifying & non qualifying vulnerabilities.

Examples:

A captcha bypass has been defined as “Non qualifying vulnerability”. A report with such vulnerability will be closed as “RTFS”.

A vulnerability can be found, but out of the program’s scopes. The report will be closed as “Out of scope”. A report will be closed as “RTFS” if it is the first time the vulnerability is reported by the Hunter. Subsequent reports of the same issue will be closed as “Out of Scope.”

Valid Reports

“Won’t fix”: the vulnerability exists but the Program Managers has indicated that a patch will not be deployed.
- Example: the cost of remediation is too high for the organisation and the risk has been accepted.

“Informative”: the report shows a potential issue, but not impactful enough to be fixed and rewarded.

“Accepted”: the report has been accepted and the patch is upcoming.

“Resolved”: the vulnerability has been fixed and retested.

⚠️ Status management

A report might be valid but closed as "Informative" because of a minor impact. However, a report can still be given to the Hunter.

A report cannot be set as "Duplicate" if it has been set as "Resolved".

Reports and Triage’s Workflows

Let’s take a closer look at what happens when a report is submitted and which stakeholders are involved at each stage of the process.

Here’s what a typical workflow looks like for a report:

“New”: a Hunter submits a report on the platform

“Under Review”: The Triage team starts assessing the bug

“Need More Info (NMI)”: The Triage team requires additional information from the Hunter to correctly estimate the bug

“Accepted”: The Organisation accepts the report & pay the reward

“Resolved”: The Organisation closes the accepted report

“Not Valid”: the Triage team discards the report as invalid

Alongside the report workflow, the Triage team follows a separate, but complementary track:

“In progress”: When a report status is set to “Under Review” or “Need More Info”, the triage moves to “In progress”.

“Awaiting info”: This stage refers to information missing from the organisation (e.g., dedicated credentials), as opposed to “Need More Info” which is missing information from the Hunter.

“Assessed”: The triage team has evaluated and reproduced the bug. They provided the organisation with an Assessment and suggestions around report’s statuses, vulnerability CVSS, and reward.