Vulnerability Rating Taxonomy 1.0
last updated on 02/17/17
view the current version: VRT version 1.2
Bugcrowd’s VRT is a resource outlining Bugcrowd’s baseline priority rating, including certain edge cases, for vulnerabilities that we often see. Have a suggestion, please join the conversation on Github.
At the beginning 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 bug bounty 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 Bug Hunters
Bugcrowd’s VRT is an invaluable resource for bug hunters as it outlines the types of issues that are normally seen and accepted by bug bounty programs. We hope that being transparent about the typical priority level for various bug types will help program participants save valuable time and effort in their quest to make bounty 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.
Interested in becoming a Bugcrowd researcher? Join the crowd.
Implications For Customers
The VRT helps customers gain a more comprehensive understanding of bug bounties. 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. For more information on our priority rating and worth of a bug, read our recently launched guide "What’s A Bug Worth".
The VRT is intended to provide valuable information for bug bounty stakeholders. It is important that we identify the ways in which we use it successfully, and what considerations should be kept in mind.
Priority is a Baseline
The recommended priority, from Priority 1 (P1) to Priority 5 (P5) , is a baseline. That having been 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 bug hunters, if you think a bug’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 use the Bugcrowd Crowdcontrol commenting system to 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 bugs – especially those designated P4 or P5 within the VRT – differently. Read more about our vulnerability prioritization. As a bug hunter, it’s important to not discount lower priority bugs, as many bug hunters have used such bugs within “exploit chains” consisting of two or three bugs 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 bug 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 bugs 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.
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 bug prioritization levels.