We take the security research community seriously and appreciate the valuable time spent participating in Bugcrowd programs. Each submission is reviewed with the respect that it deserves, and we have a commitment to set researchers up for success as reports move through the review process. This entails understanding the submission review process, respecting bounty guidelines, and effectively communicating with program owners and the Bugcrowd Application Security Engineering (ASE) team.
Submission Review Process: Time to Triage
It is our expectation that once a submission is made, the average time to triage is less than 7 business days on a Bugcrowd managed program. Depending on how complex a submission is, this process may take less time to complete. As a researcher, you can help minimize processing time by providing clear, concise and informative reports. We have some great resources to familiarize yourself with here and here on how to write the best, most actionable reports possible. Another great resource on how to show scenario and impact can be found in the Bugcrowd Forum here.
In the event that this process is not followed as planned, we encourage researchers to take the following actions, avoiding a breakdown in communication during the review period:
- If a submission has not changed state (Triaged/Duplicate/Out of Scope/Not Applicable/Not Reproducible) or has received no reply to by the 7th business day after reporting, we recommend making a polite inquiry on the submission asking for an update to the status of the report: “Can I provide any additional information to help with triage?” or “Hey guys, could I get a status on this report?”
When communicating with the Bugcrowd ASE team, or with program owners, always remember to put your best foot forward and interact with respect. Please do not repeatedly message on a daily/every other day cadence. This takes away valuable time on the triage side from replicating and validating submissions.
Submission Review Process: Triage to Finalized Status
From the ‘triaged’ state, we encourage our program owners to move a submission to a finalized status (Unresolved/Resolved/Not Applicable/Duplicate/Won’t Fix) within 14 days.
Again, in the event that this does not occur as expected, take the following action:
- If the submission is not finalized by the 14th business day after moving to ‘triaged,’ please comment in the submission asking for a status update; ask if additional information would be useful, and also send email to support@bugcrowd.com with the Bug ID number so our support team can assist.
Occasionally, you may disagree with how a report has been classified. The following escalation path will keep your interactions professional and headed towards a positive resolution. If a submission is marked as ‘Won’t Fix:’
- Begin with a response/report as to why you feel it’s important to fix. Keep it professional. Highlight the technical vs business impact. Allow the program owner a chance to respond to your report. Please keep in mind that the final decision on whether or not to fix an issue is the customer’s, and that all submissions including those marked as Won’t Fix are subject to Bugcrowd’s Standard Disclosure Terms.
- If the program owner does not respond within 14 days, please escalate the issue to support@bugcrowd.com. Don’t forget to include the submission ID in your message for easy tracking.
Communication Considerations:
Throughout the submission review, triage and closing processes, we expect researchers to adhere to best practices, avoiding these unproductive communication behaviors:
- Tweeting your frustrations
- While tweeting can be a way to get a company’s attention, it’s unnecessary and potentially inflammatory when Bugcrowd’s established support channel exists for you. Bugcrowd’s support team is ready to help researchers and customers navigate disagreements in a fair and professional manner.
- Attacking, berating or belittling ASEs or program owner(s) in the submission dialogue
- We understand that it can be very frustrating to have your work go unrewarded, but abusive communication will not be tolerated and may result in your Bugcrowd researcher profile being disabled. Disagreements may occur, but handling them professionally is important to establishing and maintaining a healthy long term working relationship.
- Public disclosure threatening
- This automatically makes the interaction appear aggressive, and places everyone involved on the defensive and can shatter the initially fragile trust relationship that exists between a researcher and program owner.
- Requesting disclosure may be possible if the program’s terms allow it. If you aren’t sure what type of disclosure a program has, compare the wording on the program brief to this breakdown. Bugcrowd can help you responsibly disclose a finding as well – just reach out to Support@bugcrowd.com and we can help connect your report to the correct folks.
In general, it’s important to remember that there is a human on the other side of the keyboard, and for a variety of reasons, all communications should be handled reasonably and respectfully.
We are always available through our designated support channels to facilitate fair and respectful mediation and communication. If you have any further questions, don’t hesitate to reach out to support@bugcrowd.com.
