- Receiving Request for Retest
- Starting Retest
- Submitting Retest Results
- Rejecting Retest Request
- Retesting Duplicate Submission
- Retesting Collaborative Submission
In Beta: Retesting submissions through the following workflow is in a Beta phase and thus limited to a subset of programs. Hence, only a subset of researchers are rewarded for completing retests today. For more information, submit a support ticket through the Bugcrowd Support Portal.
When the customers request a retest for the issues they have mitigated, fixed a vulnerability, or chain of vulnerabilities, researchers perform retest on submissions to make sure they are patched successfully. Researchers will perform a retest to check whether the same vulnerability still exists or if there is a modified variant of that vulnerability. A retest may also be required when a new release of an application is pending, and the customer wants to make sure that there are no regressions.
Usually, the following individuals receive the retest request for submissions:
- Researcher who has submitted the vulnerability
- Researcher who has submitted a similar submission (Duplicate Submission)
- Collaborators of a submission (if any)
Receiving Request for Retest
When a customer requests for retesting a submission, the researcher receives an email notification. The researcher can either access the submission from the email notification or from the Submissions tab.
The notification message includes the reward amount that the researcher will be paid for submitting the retest results and the date by when the retest must be completed.
A sample email notification is as shown.
Researcher can view the retest option on the Submission Details page.
Starting Retest
When the customer requests the retest, the researcher can either accept and start the retest or reject the retest.
To start the retest, go to the Submission Details page and click Start retest.
Submitting Retest Results
You can submit the test results based on the following:
- Whether you were able to reproduce this vulnerability exactly as described in the original submission
- If you found a workaround or new related vulnerability, excluding the vulnerability described in the exact steps in the original submission
- Summary of how you retested this vulnerability. You can style your text using the Markdown syntax. For more information, see using markdown for formatting content.
After answering the questions, click Complete retest.
If you want to complete the retest later, then click Maybe later. However, if you have answered any of the retest questions, then they will not be saved.
The retest results are submitted to the customer.
If the researchers do not complete the retest within a defined period of time, then the submission is reassigned for retest to the next researcher in the responsibility chain who does not have a pending retest. A notification is sent to the researcher indicating that the retest has expired and the submission will be assigned to another researcher (or a Bugcrowd ASE).
In the Activity Feed, a researcher can view the retest history performed by themselves or collaborators but cannot view the activity for the retest assigned to the second researcher or their collaborators.
Rejecting Retest Request
If you do not want to perform the retest, click Reject retest.
A retest rejection message is displayed and a notification is sent to the customer that the researcher has declined the retest request.
Retesting Duplicate Submission
If there is a duplicate submission, then the retest request can be sent only for the parent submission and not for the duplicate submission. The researcher who submitted the parent submission and the researcher who submitted the duplicate submission receives the retest request.
Retesting Collaborative Submission
In case of collaborative submission, depending on the defined reward split percentage only two researchers will receive the retest request. For example, if the reward percentage for the researchers is defined as 50%, 30%, and 20%, then the researchers with 50% and 30% will receive the retest request. If one of the collaborator does not accept the request, then the next collaborator in the queue will receive the retest request.
