Reports
      Back to home
      1. Knowledge Base
      2. Hunters
      3. Reports

      Vulnerability Reports Workflow

      Learn more about the different stages your reports are going through on the YesWeHack platform

      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:

       workflow_new_points

      The numbers in green or red circles represent the number of points respectively gained or lost by the Hunters, depending on the report status.

      Statuses' Definition

      Invalid Reports

      • “Duplicate”: the vulnerability exists but has already been reported, either internally or within the bug bounty program.

      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.

      • “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 occasions 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 have 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

      • A report might be valid but closed as “Informative” because of the minor impact. However, a reward 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:

       Workflow_1

      • “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:

       Workflow_2

      • “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

      • “Done”: The organisation has accepted the report and the triage process ends

      Where can I see the current Report & Triage statuses?

      • Open the Vulnerability Report of your choice

      • Check the right-side menu for information on the different statuses

         

        workflow_5