Start small
While this has been mentioned before, it's worth revisiting. It may be tempting to launch your program "publicly" by announcing it to the world, and in the case of an in-house program, making your program policy and report submission form publicly accessible. This can be risky, as it does not give you a chance to start small and scale up. No matter how much you prepare, there will always be surprises when you launch a VDP. You might receive more vulnerabilities than expected and not be able to keep up. Maybe half of your team comes down sick and is unable to help triage bugs. Perhaps you forgot to try running authenticated scans, and when a researcher does, it accidentally floods your system by creating 100,000 new accounts! Whatever the surprises may be, it's better to start small and slowly scale your program up over time. You will run into issues, which is totally normal, but it's best to have the bandwidth to handle these issues one at a time.
If you've decided to build your program in-house, you'll still want to stand up your program policy and report submission form on your website, but you may want to require hackers to login before being able to see it. If you're using a third party platform, they will automatically handle inviting a small set of security researchers for you. In either case, you can create an invitation template to use for inviting hackers to your private VDP, like this:
Hello, <Your organization name> would like to invite you to participate in our private VDP. We're starting small in private mode so we can build upon our VDP processes to provide the best experience possible for security researchers. Please check out our program policy for testing guidelines and scope. If you have any feedback for us in the early stages of our VDP, please let us know.After your first set of researchers have been invited and given access to your program, reports will start to come in. Or, you may not receive any reports, but that's okay. Let's say you invite five security researchers. It's possible two of them are too busy and decide not to look at your program at all. Another one may be on vacation and entirely miss your invite message. The fourth and fifth hackers might take a look and do some testing for a day or two, but not find any vulnerabilities. They may come back to it a few weeks later and report something then, but it can still be shocking to go through all of this work, send out invites, and not receive any reports. If this happens, don't worry. This is totally normal, and why you want to start small and scale up. If you send out five invites and aren't seeing much report volume, send out five more, then another five, or ten, or even twenty. If you're using a third party platform, they have automated mechanisms that will invite hackers slowly over time based on desired report volume. On the other hand, if you get a huge number of vulnerability reports after only inviting five security researchers, you might want to hold off on inviting more until your report volume slows down.
Triage and iterate
For your first week or two after launching your VDP, you may want to have two or more people on duty at the same time to help with triaging incoming vulnerability reports, filing bugs, and communicating with researchers. Usually there's a large spike of reports at the launch of a program, then it settles down over time. As you triage incoming vulnerability reports, you might receive feedback from hackers and identify gaps or misunderstandings in your program policy. You might also find issues in your processes and tooling. As you start small and have a lot of attention and energy from your team in these first couple of weeks, use this time to quickly iterate and improve upon your program. After a month or two, things will die down, and running your program smoothly will become second nature.
Scale up, launch publicly
As your team gets used to running your program, you'll invite more and more hackers to participate. You've expanded your scope to include everything you know about (and even assets you perhaps didn't realize existed). Eventually, you may get to a point where you've invited one hundred, or even a few hundred hackers, but report volume seems to be dwindling. The reports being sent in all seem to be low or medium severity. On duty rotation seems to be fairly light, and your team is well versed in triaging vulnerability reports, pushing them to resolution, and communicating with hackers. At this point, you're likely ready to launch your program publicly. Before you do so, reconnect with all of your stakeholders to ensure they're aware of and bought into your public launch. Similar to your initial, private launch, get your team ready for another potential spike in report volume for your public launch. One key difference when launching publicly is that anyone can submit a vulnerability report to you. Keep in mind this can generate a lot of noise. For example, users that are confused about how to login to their account, or even spam bots filling out forms and sending emails automatically might submit reports to your VDP. It's valuable to have templates in place for quickly closing out common non-security related reports, or even pre-empting this by adjusting your form to redirect users to the right place (for example, your support staff for things like forgotten passwords). On the bright side, by opening your program up to the public, skilled hackers that had no way of contacting you before will now be able to do so. This might help you uncover high or critical severity vulnerabilities you didn't know existed. It also comes with all the benefits mentioned earlier in this guide, including having a standardized channel for the global hacking community to disclose vulnerabilities directly to you, reducing the risk of breaches and negative PR.
Celebrate
Congratulations, You've come a long way, and you now have a public VDP. Don't forget to celebrate with your team and all the stakeholders that helped you along the way. It's important to express your gratitude and find a way to celebrate your success together. Beyond celebrating the public launch of your VDP, don't forget to celebrate milestones along the way, such as the year anniversary of your public launch, or by highlighting particularly interesting and critical bugs that were found and fixed via your VDP. Gathering metrics along the way can help demonstrate the success of your program and highlight the accomplishments of you and your team.