Vulnerability disclosure – what is it, why you need it, and how to build it

Someone has just found a security issue or vulnerability in your product/software/website. What happens next? In this article, we give an overview of what you need to know about vulnerability disclosure. From the basics of what vulnerability disclosure is, to creating a vulnerability disclosure policy, and developing an effective response process. We also share our vulnerability disclosure process template so you can get your own program up and running in less than 10 minutes.

What is vulnerability disclosure?

Vulnerability disclosure is the practice of allowing people to report security flaws in a product or service. Simply put, it allows other people to tell you about security issues they have found in your product.

Why do I need a vulnerability disclosure program?

One of the main ideas behind a vulnerability disclosure program is that it provides a mechanism for security issues to be disclosed while allowing a company to fix or mitigate that issue before that vulnerability is made public.

Without a vulnerability disclosure program in place, disclosing security issues can be a difficult and risky thing to do for anyone who comes across such issues because:

  • There is uncertainty on who to contact and how to contact them to actually report the issue
  • There is uncertainty about how you may react. For example, will you threaten legal action against them because they were doing something they should not be doing?
  • There is uncertainty about whether you will actually do anything at all. Should they even give you a chance to fix the problem before making it public?

You can think of a vulnerability disclosure program as disclosing the terms of a deal between the person who finds the security issue, and the owner of the product with the security issue. In exchange for discovering a security issue,  disclosing it to you and giving you the chance to fix the issue before it goes public, you give the person who discovered the security issue certain reassurances about how that security issue will be handled, as well as some kind of recognition or reward. The result should be a win-win situation where security issues get found, disclosed in confidence and quickly fixed without resorting to publicly reveal the security issue for any action to be taken.

Having a formal vulnerability disclosure process and policy provides the framework so that both the person who finds the security issue, and the owner of the product with the security issue, can manage their interactions with confidence and trust. Without a vulnerability disclosure program, you risk having security issues going unreported, or security issues simple being publicly without giving you a chance to fix them first. This may result in damage to your brand, image, and reputation, and may attract malicious actors who will exploit the vulnerability while you frantically race to try and fix it.

Vulnerability disclosure policy and guidelines

A Vulnerability Disclosure Policy (VDP) provides the formal guidelines for how security vulnerabilities can be reported and how they will be handled once reported. A VDP should include:

  • A brand statement or commitment to security. This is where you confirm that you take security issues seriously and would like the chance to fix an issue before it is made public.
  • Program and scope that indicates what systems and features will be considered in the VDP and what issues will be considered out of scope. For example, a VDP may exclude any customer websites hosted on its infrastructure.
  • Waiver of legal action, which essentially outlines the actions and activities where you will not take any legal action against any person who discloses a vulnerability.
  • Communication and process details, specifying how the company will communicate with the researcher and how vulnerabilities will be handled
  • Prioritization process which sets out the criteria for how reported vulnerabilities may be prioritized in terms of their importance and urgency.

As stated earlier, one of the main benefits behind operating a vulnerability disclosure program is to provide you with an opportunity to fix or address an issue before that issue is made public. VDPs will therefore also specify when a researcher can publicly disclose a vulnerability. Typically, this will come in the form of:

  • Don’t disclose until its fixed
  • Don’t disclose until a certain number of days after the vulnerability was submitted (e.g. 90 days)
  • Don’t disclose until an agreed upon date

There are some great open source documents and resources out there. Examples can be found from Bugcrowd and the disclose.io project who have developed some great templates for a Vulnerability Disclosure Policy which can be found using the links below.

https://github.com/bugcrowd/disclosure-policy

https://github.com/disclose/dioterms

What happens once a vulnerability is disclosed?

There’s no formal industry standard when it comes to how to handle vulnerability disclosures. However, it will typically follow this process:

  • Discovery: someone discovers a vulnerability
  • Reporting: the vulnerability is reported with all the necessary information
  • Assessment: the company who owns the product or service with the vulnerability reviews the disclosure to determine whether it is in scope
  • Action: if the issue is determined to be in scope, the company notifies the discloser and begins to fix or mitigate the issue. If it is out of scope, the discloser is informed accordingly.
  • Notification: when the issue is resolved, the discloser may be further notified.
  • Disclosure: the vulnerability may be publicly disclosed per the terms of the VDP. This may be either upon resolution of the issue, or after the waiting period has expired.

Set up and run a vulnerability disclosure program in 10 minutes

We recently set up our own Vulnerability Disclosure Process 👉here, using Workflow86 to manage the entire process. The workflow we built covers both a page to display your Vulnerability Disclosure Policy (using the disclose.io template) and an online form as the method for security issues to be reported. Once reported, the workflow will track and manage that issue using a database, assign tasks for reviewing the disclosure (whether it is in or out of scope) and send out automated emails to the person who reported the issue along the way.

Now we are sharing the template so you can set up your own vulnerability disclosure program in less than 10 minutes. Simply download the workflow, read the set up instructions in the read me, and you will be good to go.

Get your productivity superpowers today