# Creating Your VDP

A program policy is essential for any VDP and needs to be crafted carefully.
The program policy is the first thing security researchers see when
participating in a VDP. It sets the tone for the program, defines expectations,
and defines your commitment to researchers that choose to participate.

## How to create and host your program policy

Use the guidelines below to draft the program policy for your VDP. Program
policies are usually only 1-3 pages long and typically include the following
topics:

- A researcher promise
- Testing guidelines
- The scope of the program

The program policy needs to be available to all potential researchers. If you
plan on privately launching the VDP to only a few invited researchers, then the
program policy needs some kind of access control to make it available to the
researchers you've invited, but restricted to everyone else. Researchers also
need a way to submit reports, such as a web form or email alias connected to a
ticketing system for tracking the reports. Consider this while setting up the
VDP's online resources.

Third party vulnerability disclosure and bug bounty platforms generally offer
capabilities such as:

- A way for you to create, edit, and publish a policy
- Access controls to create a private program
- Automatically inviting hackers at a comfortable pace
- Inbox functionality to facilitate processing incoming reports

Third party platforms also offer a variety of consulting services to help
ease the process of creating and launching a VDP. Typically third party
platforms and consulting services come at a cost. Consider the costs and
benefits of using a third party vs. building and managing your program in-house
to determine the best path forward for your organization.

For additional inspiration on what to include in your program policy, read
the United States Department of Justice's "[A
Framework for a Vulnerability Disclosure Program for Online
Systems](https://www.justice.gov/criminal-ccips/page/file/983996/download)".

## Program policy stakeholders

As you draft your program policy, consider how to work with your
stakeholders. Various teams may provide input on considerations to build into
your policy.

| Stakeholder | Considerations |
|---|---|
| Legal | - Work with your legal team to draft your program policy and terms under which hackers will participate. - Researchers aren't compensated, so there is no good reason to subject themselves to extensive onboarding requirements or burdensome terms. |
| IT | - Work with your IT team to help develop testing requirements and scope, such as not creating denial of service conditions. |
| Engineering | - Engineering may have input on testing requirements and scope, including what types of vulnerabilities are the most or least interesting. |
| PR | - Work with your PR team to review policy language on disclosure. |
| Security | - Security team typically leads the creation of the policy. - Security team will likely receive feedback from hackers and iterate on the policy over time with other stakeholders. |

## Researcher promise

The researcher promise explains the organization's commitments to
participating researchers who act in good faith by following the testing
guidelines outlined in the policy. For example, a commitment to respond to all
incoming security reports within a specific timeframe, as well as communicating
decisions on which vulnerability reports are accepted and fixed.

Example:
*\<Name of your organization\> is committed to working with
security researchers to help identify and fix vulnerabilities in our systems and
services. As long as you act in good faith and abide by the guidelines outlined
in this policy, we will make our best effort to commit to the
following:*

- *Provide an initial response to your vulnerability report within
  three business days*
- *Determine if we will accept (intend to fix) or reject (identify your
  report as a false positive or acceptable risk) your vulnerability report within
  ten business days*
- *Keep you up to date on progress towards remediation of reports we accept
  from you*

Adopting language in your program policy helps assure researchers
that legal action will not be taken against them for testing against your
systems, as long as they act in good faith and follow all the guidelines
explained in the policy.

> [!NOTE]
> **Note:** [disclose.io](https://disclose.io) provides templates with [safe harbor language](https://github.com/disclose/disclose/blob/master/terms/simple-safe-harbor/simple-safe-harbor.md) you can use while drafting your policy. Work with your legal team to evaluate this language and adapt it to your needs.

## Testing guidelines

The testing guidelines describe the security testing that is in scope of the
VDP, as well as testing that isn't in scope and should be avoided by
researchers. If there are specific types of vulnerabilities you'd like
researchers to focus on, this section is a good place to highlight them.

Example:  

*When performing security testing, please adhere to the following
guidelines:*

- *Only test against your own accounts and data (e.g. create test
  accounts). If you identify a vulnerability that may result in access to other
  users' data, please check with us first before testing further.*
- *If you inadvertently access other users' data in your testing, please
  let us know, and do not store any such user data.*
- *Do not perform testing that results in denial of service conditions or
  degradation of our production services.*
- *Social engineering is out of scope for this program; do not attempt to
  socially engineer our organization or our users.*

<br />


*We're particularly interested in the following types of vulnerabilities
and impacts:*

- *Remote code execution*
- *XSS resulting in access to sensitive data (e.g. session info)*
- *SQL injection resulting in access to sensitive data or
  functionality*
- *Business logic flaws that result in access to sensitive data or
  functionality*

<br />


*We are less interested in the following types of vulnerabilities, which
are more likely to*   

*get rejected as false positives or accepted risks:*

- *Lack of the X-Frame-Options header on pages without state-changing
  functionality*
- *Unverified automated scanner results*
- *Issues that are unlikely to be exploitable and/or that do not have
  realistic security impact*

## Scope

The scope defines the assets that researchers can test against, as well as
which assets aren't considered part of the VDP. The scope needs to be carefully
considered and be as expansive as possible without overloading your team. The
more you're willing to put in scope, the more likely you'll get engagement from
security researchers. However, don't make the scope so expansive that your team
won't be able to keep up with the incoming reports. Start with a few assets in
scope. Expand scope as you get a better idea of what report volume you'll
receive. Before opening your VDP to the public over time, aim to have everything
in scope.

In terms of how to define your scope within your program policy, adding
detail about each asset or area will help security researchers know what's
important to you and where to focus their efforts. You can also include tips on
how to safely test against your assets. Here's an example:

| **Asset** | mail.example.com |
| Description | Primary domain for users to access their email. |
| Interesting Vulnerabilities and Impacts | - Vulnerabilities that result in unauthorized access to other users' email. - Ability to irrecoverably delete another user's email or entire account. |
| Issues Likely to be Rejected | - SPF - Phishing or issues that facilitate phishing - Ability to send potentially malicious attachments |
| Testing Guidelines | Only test against accounts you own or have express consent to test against. When creating test accounts, please include "vdptest" somewhere in the username. You can create test accounts at mail.example.com/new. |
|---|---|

This is a fairly detailed breakdown. Alternatively, you could include a
simple list of in scope and out of scope assets:

*In Scope*

- *mail.example.com*
- *example.com*

*Out of Scope*

- *blog.example.com*

## Resourcing your VDP

You'll need certain resources in place before launching a VDP. You'll need
resources for:

- Reviewing incoming vulnerability reports
- Communicating with hackers
- Finding asset owners and filing bugs
- Fixing bugs
- Vulnerability management / following up on remediation

## Revisit key stakeholders

If you haven't already, revisit conversations with key stakeholders you
discussed your VDP with earlier to ensure they're aligned on the timeline of
launching your VDP, as well as queuing up any necessary resources for the
launch. For example, you may want to work with engineering leadership to ensure
their teams are ready for a potential influx of security bugs to work on in the
first few weeks after launch. Within your security team, make sure those that
triage alerts in your detection and response systems are aware of the VDP launch
date, and consider allocating more time and resources for when testing begins.
You'll also need to build a team to help support daily operations of your
VDP.

## Build your team

Running a VDP requires a decent amount of operational, interrupt-driven work.
If you try to review, technically validate, and respond to every vulnerability
report that comes in, as well as file every bug, keep track of statuses, and
communicate updates to researchers all by yourself, you might burn out. Even if
you don't have a large security team, find security-minded volunteers to help
build a team to help operationalize and run your VDP. You'll still want a
defined "owner" or "leader" of your VDP that's ultimately responsible for your
VDP's success, but you'll also need a team to support that leader.

## Build an on-duty schedule

Once you've got resources on board and willing to help with your VDP, put
some structure behind it by setting up an on-duty schedule. You can create this
however you like, but a weekly rotation is fairly common practice. When you're
on duty for the week, it's your responsibility to:

- **Triage** - review incoming vulnerability reports
  - Technically validate the report and make an "accept" or "reject" decision
  - Communicate your decision to the hacker that reported the issue
  - If necessary, ask for more information from the hacker if you're unable to reproduce the issue
  - If the vulnerability is valid, file a [groomed
    bug](https://developers.google.com/android/play-protect/starting-a-vdp/docs/preparation#grooming-bugs) with the right [owner](https://developers.google.com/android/play-protect/starting-a-vdp/docs/preparation#finding-owners)
- **Vulnerability management** - push forward existing vulnerabilities
  - Review bugs filed from past on-duty weeks to ensure remediation is progressing based on your [severity
    standards and remediation timelines](https://developers.google.com/android/play-protect/starting-a-vdp/docs/preparation#severity-standards).
  - Use the tips from [finding
    owners](https://developers.google.com/android/play-protect/starting-a-vdp/docs/preparation#finding-owners) to help persuade owners to work on these bugs
- **Communicate** - provide updates to security researchers on existing reports
  - Researchers may proactively ask for updates on existing reports; check for this and respond as needed
  - If a vulnerability is fixed, communicate this back to the researcher so they know their hard work resulted in positive change at your organization. You can even include template language that asks the researcher to let you know if you've missed anything in your fix, or if your fix could be bypassed in some way.

Depending on how many reports you receive, the complexity of these reports,
and the skills and knowledge of the individual on-duty, being on-duty could take
anywhere from a few hours to your entire week. Tips for a successful on-duty
rotation include:

- Ensure your team is ready to step in and help support the on-duty on particularly heavy weeks.
- Have a good handoff process in place; if there are issues that might require immediate attention from the next person on-duty, write up some handoff notes or have a live conversation at the end of the week.
- Create automated scheduling to ensure everyone knows when they are on-duty. This can be as simple as creating recurring calendar entries for each individual.
- Especially towards the start of your VDP, double check with the person on-duty to make sure they remember it's their week, as well as to see if they need any help. If you have more junior resources on the rotation, have more senior resources work with them to ensure they feel comfortable and can ask questions as they ramp up.
- Have a flexible process for swapping weeks. Inevitably someone will have an emergency and need to take time off during their week, or someone will take vacation, etc. When this happens, encourage the team to swap weeks as needed to accommodate everyone's schedules.
- Create an on duty "cheat sheet" that outlines what duties must be covered, including documentation on how to do it.

## Decide on in-house vs. third party

Most of the guidance thus far has been based on you building and running your
VDP in-house. There are a variety of consulting services and platforms available
that can assist you with creating and running a VDP. These third parties
typically come with a cost, but can be useful in guiding you on how to create,
launch, and run your VDP. Some even offer triage services to help review
incoming vulnerability reports for you, helping handle communication with
hackers, and only escalating valid reports to your team. Deciding on whether you
build this process in-house or use a third party platform will depend on your
requirements and available resources. If you have a large budget but not a lot
of headcount, leveraging a third party to help run your program can make
sense. If it's the other way around, it may be worth investing the time to
build your program yourself.

## Receiving reports

If you decide to use a third party platform, they should have a way for hackers
to submit reports directly to you. If you build your program in-house, you'll
need to build this yourself. This could be an email address that automatically
creates a ticket or bug in your issue tracker (e.g. security@example.com), or it
could be a web form with required form fields that's either linked from or on
the same page as your program policy. Whatever form it takes, this is your best
chance to inform hackers of the format you'd like to receive your reports in.
Keep in mind asking hackers to submit reports in a certain format does not
always guarantee they will, but it doesn't hurt to ask. Here's an example of
what you might ask for in a report submission form:

*Title: \[Please add a one line description of the issue, e.g. "XSS in
mail.example.com*   

*results in session theft"\]*
*Summary: \[Please add a brief description of the vulnerability
and why it matters, e.g. Due to a lack of escaping, you can send an email to
another user containing an XSS payload that would enable an attacker to steal
another user's cookies containing session information. This would allow the
attacker to login to the victim's account.\]* *Reproduction Steps: \[Please add step by step instructions on how
to reproduce the vulnerability.\]*   
*1.*   
*2.*   
*3.*

*Attack Scenario and Impact: \[How could this be exploited? What security
impact does this*   

*issue have?\]*
*Remediation Advice: \[Optionally, if you have any advice on how
this issue could be fixed or remediated, add it here.\]*