The current VRT release is located at https://bugcrowd.com/vrt as both a searchable page and downloadable PDF.

The VRT is also available via our API. Documentation and examples of VRT API usage may be found here.

At the beginning 2016, we released the Bugcrowd Vulnerability Rating Taxonomy (VRT) to provide a baseline vulnerability priority scale for bug hunters and organizations. Over the past year and a half this document has evolved to be a dynamic and valuable resource for the bug bounty community.

In April 2017, we published formal contributor guidelines for the VRT, allowing us to more easily receive and transparently communicate about public feedback.

Bugcrowd's VRT outlines Bugcrowd's baseline technical severity rating – taking into account potential differences among edge cases – for common vulnerability classes. To arrive at this baseline technical severity rating for a given vulnerability, Bugcrowd's application security engineers started with the generally-accepted industry guideline and further considered the vulnerability's average acceptance rate, average priority, and frequency on business use case specific exclusions lists across all of Bugcrowd's programs.

Bugcrowd welcomes community feedback and direct contributions to the Bugcrowd VRT. We accept comments for public discussion via GitHub Issues, but can also accommodate comments made via email to [email protected]. For more details see, CONTRIBUTING.

Each top-level category entry contains one or more subcategory entries, and each subcategory entry may contain one or more variant entries used to differentiate subcases with different priority values. Some entries may have a null priority value – this represents that the priority varies based on context information.

A VRT entry can be classified at up to three levels, including Category, Sub-Category, and Variant. Each classification level is nested within its parent and contains a set of definitions exclusive to its level.

These comprise the top level of the VRT. They describe entire classes of vulnerabilities.

example: Server-Side Injection

Many Sub-Categories are nested within a Category. They describe individual vulnerabilities.

example: Server-Side Injection > Remote Code Execution (RCE)

Many Variants are nested within a Sub-Category. They describe specific sub-cases of an individual vulnerability.

example: Server-Side Injection > SQL Injection > Blind

Within each entry is a set of data outlined below.

Each ID – often the lowercase version of its name joined by _ –  is unique among the children of its own parent. This is how VRT ID's can map between versions, such that an ID is only changed if it should not be identified with previous versions of that entry.

The human-readable name of the vulnerability.

The priority represents Bugcrowd's suggested baseline technical severity of the vulnerability on a P1 (Critical) to P5 (Informational) scale.

• P1: Critical
• P2: High
• P3: Medium
• P4: Low
• P5: Informational

The technical severity of some vulnerabilities – as denoted in the taxonomy as "N/A" or "Varies" – is context-dependent. For example, the technical severity of an Insecure Direct Object Reference vulnerability is heavily dependent on the capabilities of the vulnerable function and other context information. Valid Insecure Direct Object Reference vulnerabilities can vary in priority from P4 to P1.

Entries that are nested within another Entry. Only Categories or Sub-Categories can have children.

{
  "id": "server_security_misconfiguration",
  "name": "Server Security Misconfiguration",
  "type": "category",
  "children": [
    {
      "id": "directory_listing_enabled",
      "name": "Directory Listing Enabled",
      "type": "subcategory",
      "children": [
        {
          "id": "non_sensitive_data_exposure",
          "name": "Non-Sensitive Data Exposure",
          "type": "variant",
          "priority": 5
        }
      ]
    }
  ]
}

Copyright 2017 Bugcrowd, Inc. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.