We take the security research community seriously and appreciate the valuable time spent participating in Bugcrowd engagements. As each submission is thoroughly reviewed, we maintain our commitment to set hackers up for success as reports move through the review process. This entails understanding the submission review process, respecting bounty guidelines, and effectively communicating with engagement owners and the Bugcrowd Application Security Engineering (ASE) team.

Submission Review Process: Time to Triage

Our standard is that submissions are typically triaged within 7 business days on Bugcrowd-managed engagements. Depending on complexity, this process may take less time. As a hacker, you can help minimize processing time by providing clear, concise and informative reports. Check out our Submission Templates as an option to aid in writing the most actionable reports possible. 

In the event that this process is taking longer than expected and to avoid a breakdown in communication, we encourage hackers to take the following actions:  

  • If a submission has not changed state (Triaged/Duplicate/Out of Scope/Not Applicable/Not Reproducible) or has received no reply 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 using Request a Response. 

When communicating with the Bugcrowd ASE team, or with engagement 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 engagement owners to move the submission to a finalized status (Unresolved/Resolved/Not Applicable/Duplicate) 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 refer to our Request a Response feature. You can request a status update or ask if additional information would be useful. 
  • Allow for a response using Request a Response, but if that doesn’t come through, then you can send an email to support@bugcrowd.com with the Sub ID number and 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 ‘Not Applicable:’

  • Again, begin with Bugcrowd’s Request a Response feature. However, in the Not Applicable state, Request a Response can only be placed on Bugcrowd, NOT the customer. 
  • Keep it professional. Highlight the technical vs business impact. Allow the engagement 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 Not Applicable are subject to Bugcrowd’s Standard Disclosure Terms.
  • If the engagement owner does not respond within 7 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 hackers 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. Bugcrowd’s support team is ready to help hackers and customers navigate disagreements in a fair and professional manner.
  • Attacking, berating or belittling ASEs or engagement 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 hacker profile being disabled. Please see our Platform Behaviour Standards for more detail. 
  • Public disclosure threatening
    • This is considered aggressive and places everyone involved on the defensive. It can shatter the initially fragile trust relationship that exists between a hacker and engagement owner.
    • Requesting disclosure may be possible if the engagement’s terms allow it. If you aren’t sure what type of disclosure an engagement has, compare the wording on the engagement brief to our Vulnerability Disclosure Policy. 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.