Bugcrowd’s Vulnerability Rating Taxonomy

Bugcrowd’s Vulnerability Rating Taxonomy is a resource outlining Bugcrowd’s baseline priority rating, including certain edge cases, for common vulnerabilities. Have a suggestion to improve the VRT? Join the conversation on GitHub.

Vulnerability Rating Taxonomy

Version 1.12 (current) last updated on 18 Dec 2023

The methodology

At the beginning of 2016, we released the Bugcrowd Vulnerability Rating Taxonomy (VRT) in an effort to further bolster transparency and communication, as well as to contribute valuable and actionable content to the crowdsourced security community.

Bugcrowd’s VRT is a resource outlining Bugcrowd’s baseline priority rating, including certain edge cases, for vulnerabilities that we see often. To arrive at this baseline priority, Bugcrowd’s security engineers started with generally accepted industry impact and further considered the average acceptance rate, average priority, and commonly requested program-specific exclusions (based on business use cases) across all of Bugcrowd’s programs.

Implications for hackers

Bugcrowd’s VRT is an invaluable resource for hackers as it outlines the types of issues that are normally seen and accepted by bug bounty and other crowdsourced security programs. We hope that being transparent about the typical priority level for various vulnerability types will help program participants save valuable time and effort in their quest to make targets more secure. The VRT can also help researchers identify which types of high-value bugs they have overlooked, and when to provide exploitation information (POC info) in a report where it might impact priority.

Implications for customers

The VRT helps customers gain a more comprehensive understanding of reported vulnerabilities. Not only will our customers be better able to understand priorities and their impact better, but this also helps them write better bounty briefs, adjust bounty scope, and communicate more clearly about bugs. In the fixing stage, the VRT will help business units across the board in communicating about and remediating the identified security issues.

Priority is a baseline

The recommended priority, from Priority 1 (P1) to Priority 5 (P5), is a baseline. That said, while this baseline priority might apply without context, it’s possible that application complexity, bounty brief restrictions, or unusual impact could result in a different rating. As a customer, it’s important to weigh the VRT alongside your internal application security ratings.

For hackers, if you think a vulnerability's impact warrants reporting despite the VRT’s guidelines, or that the customer has misunderstood the threat scenario, we encourage you to submit the issue regardless and clearly communicate your reasoning

Low priority does not imply insignificance

For customers, it’s important to recognize that base priority does not equate to “industry accepted impact.” Base priority is defined by our Technical Operations Team and our VRT is a living document - see the following point about a “Vulnerability Roundtable.” Your internal teams or engineers might assess certain vulnerabilities – especially those designated P4 or P5 within the VRT – differently. As a hacker, it’s important to not discount lower priority bugs, as many hackers have used such vulnerabilities within “exploit chains” consisting of two or three vulns resulting in creative, valid, and high-impact submissions

Importance of a vulnerability roundtable

Bugcrowd reviews proposed changes to the VRT every week at an operations meeting called the “Vulnerability Roundtable.” We use this one-hour meeting to discuss new vulnerabilities, edge cases for existing vulnerabilities, priority level adjustments, and to share general validation knowledge. When the team comes to a consensus regarding each proposed change, it is committed to the master version. Members of the Technical Operations team look forward to this meeting each week, as examining some of the most difficult to validate bugs serves as a unique learning exercise.

Communication is king

Having cut-and-dry baseline ratings as defined by our VRT, makes rating vulnerabilities a faster and less difficult process. We have to remember, however, that strong communication is the most powerful tool for anyone running or participating in a bug bounty or other crowdsourced security test.

Both sides of the bug bounty equation must exist in balance. When in doubt, ask dumb questions, be verbose, and more generally, behave in a way that allows you and your bounty opposite to foster a respectful relationship. As a customer, keep in mind that every bug takes time and effort to find. As a bounty hunter, try to remember that every bug’s impact is ultimately determined by the customer’s environment and use cases.

One size doesn’t fit all

As the version of the VRT we have released only covers some web and mobile application vulnerabilities, it should be viewed as a foundation. Any vulnerability taxonomy would look much more robust with the addition of IoT, reverse engineering, network level, and other vulnerability categories – most of which have been validated and triaged by Bugcrowd in the past

In addition, while this taxonomy maps bugs to the OWASP Top Ten and the OWASP Mobile Top Ten to add more contextual information, additional metadata could include CWE or WASC, among others. As always, the program owner retains all rights to choose final vulnerability prioritization levels.

Version history

VRT version actions
Version 1.12
Last updated
Version 1.11
Last updated
Version 1.10
Last updated
Version 1.9
Last updated
Version 1.8
Last updated
Version 1.7
Last updated
Version 1.6
Last updated
Version 1.5
Last updated
Version 1.4
Last updated
Version 1.3
Last updated
Version 1.2
Last updated
Version 1.1
Last updated
Version 1.0
Last updated