All Projects → bugcrowd → Vulnerability Rating Taxonomy

bugcrowd / Vulnerability Rating Taxonomy

Licence: apache-2.0
Bugcrowd’s baseline priority ratings for common security vulnerabilities

Programming Languages

python
139335 projects - #7 most used programming language

Projects that are alternatives of or similar to Vulnerability Rating Taxonomy

Rateit.js
Rating plugin for jQuery. Fast, Progressive enhancement, touch support, icon-font support, highly customizable, unobtrusive JavaScript (using HTML5 data-* attributes), RTL support, supports as many stars as you'd like, and also any step size.
Stars: ✭ 146 (-35.68%)
Mutual labels:  rating
React Native In App Review
The Google Play In-App Review API, App store rating API lets you prompt users to submit Play Store or App store ratings and reviews without the inconvenience of leaving your app or game.
Stars: ✭ 175 (-22.91%)
Mutual labels:  rating
Raty
🌟 Raty - A Star Rating Plugin
Stars: ✭ 2,292 (+909.69%)
Mutual labels:  rating
Structured Data Json Ld
Collection of structured data snippets in Google preferred JSON-LD format.
Stars: ✭ 157 (-30.84%)
Mutual labels:  rating
Dasp
The Decentralized Application Security Project
Stars: ✭ 166 (-26.87%)
Mutual labels:  vulnerabilities
Linux Soft Exploit Suggester
Search Exploitable Software on Linux
Stars: ✭ 187 (-17.62%)
Mutual labels:  vulnerabilities
Vulncost
Find security vulnerabilities in open source npm packages while you code
Stars: ✭ 146 (-35.68%)
Mutual labels:  vulnerabilities
App review
App Review - Request and Write Reviews and Open Store Listing for Android and iOS in Flutter. Maintainer: @rodydavis
Stars: ✭ 213 (-6.17%)
Mutual labels:  rating
Rating
Laravel Eloquent Rating allows you to assign ratings to any model.
Stars: ✭ 175 (-22.91%)
Mutual labels:  rating
Vulnerable Kext
A WIP "Vulnerable by Design" kext for iOS/macOS to play & learn *OS kernel exploitation
Stars: ✭ 188 (-17.18%)
Mutual labels:  vulnerabilities
Vulnix
Vulnerability (CVE) scanner for Nix/NixOS.
Stars: ✭ 161 (-29.07%)
Mutual labels:  vulnerabilities
Mysapadventures
A quick methodology on testing / hacking SAP Applications for n00bz and bug bounty hunters
Stars: ✭ 164 (-27.75%)
Mutual labels:  vulnerabilities
Sbt Dependency Check
SBT Plugin for OWASP DependencyCheck. Monitor your dependencies and report if there are any publicly known vulnerabilities (e.g. CVEs). 🌈
Stars: ✭ 187 (-17.62%)
Mutual labels:  vulnerabilities
0days In The Wild
Repository for information about 0-days exploited in-the-wild.
Stars: ✭ 149 (-34.36%)
Mutual labels:  vulnerabilities
Vulny Code Static Analysis
Python script to detect vulnerabilities inside PHP source code using static analysis, based on regex
Stars: ✭ 207 (-8.81%)
Mutual labels:  vulnerabilities
Ngx Bar Rating
Angular Bar Rating
Stars: ✭ 146 (-35.68%)
Mutual labels:  rating
Vulnerable Apps
Stars: ✭ 179 (-21.15%)
Mutual labels:  vulnerabilities
Flutter rating bar
A simple ratingbar for flutter which also include a rating bar indicator, supporting any fraction of rating.
Stars: ✭ 211 (-7.05%)
Mutual labels:  rating
Cve Bin Tool
This tool scans for a number of common, vulnerable components (openssl, libpng, libxml2, expat and a few others) to let you know if your system includes common libraries with known vulnerabilities.
Stars: ✭ 211 (-7.05%)
Mutual labels:  vulnerabilities
Easybuggy
Too buggy web application
Stars: ✭ 189 (-16.74%)
Mutual labels:  vulnerabilities

Bugcrowd VRT

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.

Background

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 decided to open source our taxonomy and published formal contributor guidelines for the VRT, allowing us to gain additional insight from the public and transparently communicate about any feedback.

VRT Council

Each week several members of the Bugcrowd team hold a meeting where they discuss vulnerability edge cases, improving vulnerability classification and all external VRT feedback. When the team comes to a consensus regarding each change proposed to the VRT, it is committed to this repository. We have decided to publish minutes from the VRT Council meeting to allow even more transparency and will be sharing those here.

Description

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.

It is important to remember that while the recommended priority, from P1 to P5 might apply without context, it’s possible that application complexity, bounty brief restrictions or unusual impact could result in a different rating.

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.

Anatomy of VRT Entries

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.

Types of VRT Entries

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.

Category

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

example: Server-Side Injection

Sub-Categories

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

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

Variants

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

example: Server-Side Injection > SQL Injection > Blind

Data within an Entry

Within each entry is a set of data outlined below.

ID

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.

Name

The human-readable name of the vulnerability.

Priority

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 "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.

Children

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

Example

{
  "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
        }
      ]
    }
  ]
}

Deprecated Node Mapping

When breaking changes such as deletion/collapsing of IDs or moving to a different parent occur, the deprecated-node-mapping.json will serve as a reference to find the latest mapped ids so that deprecated nodes are not lost.

Example

2 nodes being collapsed into 1

{
  "unvalidated_redirects_and_forwards.open_redirect.get_based_all_users": {
    "2.1": "unvalidated_redirects_and_forwards.open_redirect.get_based"
  },
  "unvalidated_redirects_and_forwards.open_redirect.get_based_authenticated": {
    "2.1": "unvalidated_redirects_and_forwards.open_redirect.get_based"
  }
}

Mapping to Other Systems

Sometimes it is useful to convert VRT IDs to other vulnerability classification systems, eg CVSS. Such mappings are supported by adding a mapping folder/files to the mappings directory. These files have a similar structure to the main VRT file but only include the id and children attributes, plus an additional mapping attribute with the same name as the file.

For example, suppose we wish to map to a traffic light system which maps all vulnerabilities to red, green or yellow. We would add a mapping file called mappings/traffic_light/traffic_light.json with contents like:

{
  "metadata": {
    "default": "green"
  },
  "content": [
    ...
    {
      "id": "server_side_injection",
      "traffic_light": "red",
      "children": [
        {
          "id": "content_spoofing",
          "children": [
            {
              "id": "iframe_injection",
              "traffic_light": "yellow"
            }
          ]
        }
      ]
    },
    ...
  ]
}

This would map the other category and any unknown IDs to the metadata.default value of green. All VRT IDs nested below server_side_injection would map to red, except for server_side_injection.content_spoofing.iframe_injection which would map to yellow.

Each mapping should be setup in the following structure:

.
├── ...
├── mappings
│   ├── new_mapping
|   |     ├── new_mapping.schema.json # Following JSON Schema (https://json-schema.org/), to be run in CI
|   |     ├── new_mapping.json        # Actual VRT mapping file as described above
│   └── ...              
└── ...

Supported Mappings

Third-Party Managed Mappings

Supported Libraries

License

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.

Note that the project description data, including the texts, logos, images, and/or trademarks, for each open source project belongs to its rightful owner. If you wish to add or remove any projects, please contact us at [email protected].