OWASP Secure Coding Cheat Sheets: Vulnerability Disclosure Cheat Sheet

# Vulnerability Disclosure Cheat Sheet

## Introduction

This cheat sheet is intended to provide guidance on the vulnerability disclosure process for both security researchers and organizations. This is an area where collaboration is extremely important, but that can often result in conflict between the two parties.

**[Researchers](#reporting-vulnerabilities) should:**

- Ensure that any testing is legal and authorized.
- Respect the privacy of others.
- Make reasonable efforts to contact the security team of the organization.
- Provide sufficient details to allow the vulnerabilities to be verified and reproduced.
- Not demand payment or rewards for reporting vulnerabilities outside of an established bug bounty program.

**[Organizations](#receiving-vulnerability-reports) should:**

- Provide a clear method for researchers to securely report vulnerabilities.
- Clearly establish the scope and terms of any bug bounty programs.
- Respond to reports in a reasonable timeline.
- Communicate openly with researchers.
- Not threaten legal action against researchers.
- Request CVEs where appropriate.
- Publish clear security advisories and changelogs.
- Offer rewards and credit.

## Methods of Disclosure

There are a number of different models that can be followed when disclosing vulnerabilities, which are listed in the sections below.

### Private Disclosure

In the private disclosure model, the vulnerability is reported privately to the organization. The organization may choose to publish the details of the vulnerabilities, but this is done at the discretion of the organization, not the researcher, meaning that many vulnerabilities may never be made public. The majority of bug bounty programs require that the researcher follows this model.

The main problem with this model is that if the vendor is unresponsive, or decides not to fix the vulnerability, then the details may never be made public. Historically this has lead to researchers getting fed up with companies ignoring and trying to hide vulnerabilities, leading them to the full disclosure approach.

### Full Disclosure

With the full disclosure approach, the full details of the vulnerability are made public as soon as they are identified. This means that the full details (sometimes including exploit code) are available to attackers, often before a patch is available. The full disclosure approach is primarily used in response or organizations ignoring reported vulnerabilities, in order to put pressure on them to develop and publish a fix.

This makes the full disclosure approach very controversial, and it is seen as irresponsible by many people. Generally it should only be considered as a last resort, when all other methods have failed, or when exploit code is already publicly available.

### Responsible or Coordinated Disclosure

Responsible disclosure attempts to find a reasonable middle ground between these two approaches. With responsible disclosure, the initial report is made privately, but with the full details being published once a patch has been made available (sometimes with a delay to allow more time for the patches to be installed).

In many cases, the researcher also provides a deadline for the organization to respond to the report, or to provide a patch. If this deadline is not met, then the researcher may adopt the full disclosure approach, and publish the full details.

Google's [Project Zero](https://googleprojectzero.blogspot.com/2020/01/policy-and-disclosure-2020-edition.html) adopts a similar approach, where the full details of the vulnerability are published after 90 days regardless of whether or not the organization has published a patch.

## Reporting Vulnerabilities

This section is intended to provide guidance for security researchers on how to report vulnerabilities to organizations.

### Warnings and Legality

Before carrying out any security research or reporting vulnerabilities, **ensure that you know and understand the laws in your jurisdiction**. This cheat sheet **does not constitute legal advice, and should not be taken as such.**.

The following points highlight a number of areas that should be considered:

- If you are carrying out testing under a bug bounty or similar program, the organization may have established [safe harbor](https://disclose.io) policies, that allow you to legally carry out testing, **as long as you stay within the scope and rules of their program**. Make sure that you read the scope carefully - stepping outside of the scope and rules may be a criminal offense.
- Some countries have laws restricting reverse engineering, so testing against locally installed software may not be permitted.
- Do not demand payment or other rewards as a condition of providing information on security vulnerabilities, or in exchange for not publishing the details or reporting them to industry regulators, as this may constitute extortion.
- If you receive bug bounty payments, these are generally considered as income, meaning that they may be taxable. Reporting this income and ensuring that you pay the appropriate tax on it is **your** responsibility.
- If you find vulnerabilities as part of your work, or on equipment owned by your employer, your employer may prevent you from reporting these or claiming a bug bounty. Read your contract carefully and consider taking legal advice before doing so.

### Finding Contact Details

The first step in reporting a vulnerability is finding the appropriate person to report it to. Although some organizations have clearly published disclosure policies, many do not, so it can be difficult to find the correct place to report the issue.

Where there is no clear disclosure policy, the following areas may provide contact details:

- Bug bounty programs such as [BugCrowd](https://bugcrowd.com/programs), [HackerOne](https://hackerone.com/directory/programs), [huntr.dev](https://huntr.dev/bounties), [Open Bug Bounty](https://www.openbugbounty.org) or [Standoff](https://bugbounty.standoff365.com).
- A [security.txt](https://securitytxt.org) file on the website at `/.well-known/security.txt` as per [RFC 9116](https://www.rfc-editor.org/rfc/rfc9116.html#name-location-of-the-securitytxt).
- An existing issue tracking system.
- Generic email addresses such as `security@` or `abuse@`.
- The generic "Contact Us" page on the website.
- Social media platforms.
- Phoning the organization.
- Reaching out to the community.

When reaching out to people who are not dedicated security contacts, request the details for a relevant member of staff, rather than disclosing the vulnerability details to whoever accepts the initial contact (especially over social media).

If it is not possible to contact the organization directly, a national or sector-based  [CERT](https://en.wikipedia.org/wiki/Computer_emergency_response_team) may be able to assist.

### Initial Report

Once a security contact has been identified, an initial report should be made of the details of the vulnerability. Id