Vulnerability Disclosure Policy: How to create one for your business?

Vulnerability disclosure programs and policies are often compared to neighborhood surveillance or a whistleblower program, where website visitors, customers, researchers, and security professionals report security lapses as and when they discover them.

White-hat hackers, researchers, and ethical hackers can be  strong aid to your vulnerability tracking efforts. And it helps to have a formal, well-structured vulnerability disclosure policy (VDP) and program in place to maintain this. Without a formal program,, these actors may publicly disclose the vulnerabilities in a manner that is not transparent and legal and might not be in the best interest of the company and the researcher.

This blog is your guide to the Vulnerabilities Disclosure Policy and Process with real-world examples for a better understanding.

What is vulnerability disclosure?

Vulnerability disclosure is the process of reporting security vulnerabilities in a company’s software, networks, devices, and systems directly to the organization. It enables security researchers, ethical hackers, IT teams, etc., to report vulnerabilities before they flare up and in a way that is legal, transparent and in the best interest of everyone.

Security-conscious organizations publish Vulnerability Disclosure Policies containing clear steps and measures for reporting security vulnerabilities, including the information that must be included, the contact parties, and so on.
Many companies also maintain  bug bounty programs, although there is a slight difference between the two.

How does Vulnerability Disclosure work?

A vulnerability disclosure process begins with an investigation of vulnerabilities by a researcher followed by establishing communication with the organization. Once the company mitigates the vulnerability, a public disclosure is made.

Following are the steps in the Vulnerability Disclosure Process:

• Discovery of flaws
• Communication with the organization
• Internal investigation and mitigation
• Public disclosure

1. Discovery of flaws

Researchers or ethical hackers discover vulnerabilities through manual testing or automated scanning tools. They try to understand the exploitability and impact of the vulnerability by verifying it in a controlled environment. Based on their investigation,  researchers prepare a report and communicate the vulnerability to the organization.

2. Communication with the organization

To disclose a vulnerability, a researcher would look to see if there is a VDP or a bug bounty program in place, to avoid any legal repercussions. In other cases, communication can be established through intermediaries.

3. Internal investigation and mitigation

The organization then conducts an internal investigation to confirm the vulnerability and understand its business impact. A patch or fix is prioritized and developed to mitigate the vulnerability and the researcher is contacted to negotiate the time for mitigation.

4. Public Disclosure

Once the patch or fix is deployed, the organization may release the details to the public,  in coordination with the researcher. The discoverer may also be publicly recognized and compensated based on the agreed-upon terms.

How to create your own Vulnerability Disclosure Program/Policy? 

To create a Vulnerability Disclosure Policy (VDP) follow a standard, structured format with certain key components. The VDP itself is publicly shared, often on the main company website, to enhance trust among stakeholders and enable security researchers/ethical hackers to report vulnerabilities.

“You definitely want a mechanism that if somebody notices something wrong with your site, and to receive a vulnerability report from the outside” –Katie Moussouris (CEO Luta Security)

Following are the 6 Key Components of a Vulnerability Disclosure Policy:

Commitment or Promise

A VDP starts with a commitment or promise made to the company’s customers, investors, partners, and other key stakeholders. The promise statement covers the purpose of creating the policy, how its in good faith, and assures those impacted by the vulnerabilities. It also addresses the researchers to value the policy’s intent and reciprocate the commitment.

For example, read this snippet from HHS VDP:

“The Department of Health and Human Services (HHS) is committed to ensuring the security of the American public by protecting their information from unwarranted disclosure. This policy is intended to give security researchers clear guidelines for conducting vulnerability discovery activities and to convey our preferences in how to submit discovered vulnerabilities to us.”

Safe Harbor

This section reassures the researchers and ethical hackers that if they discover and report vulnerabilities in good faith, the organization will not file a lawsuit against them. The goal is to create a safe practice space for the vulnerability reporters and minimize risks of legal action on both ends.

Here’s an example snippet from the US Department of Treasury VDP:

“If you make a good faith effort to comply with this policy during your security research, Treasury will consider your research to be authorized, work with you to understand and resolve the issue quickly, and will not recommend or pursue legal action related to your research.”

Scope

The scope identifies which assets are covered under the policy, including products, systems, applications, and networks, and the types of applicable vulnerabilities. It also defines what types of vulnerabilities must be reported or ignored, depending on their severity.

Take this example of the US Department of Interior VDP:

“This policy applies to the following systems and services:

*.doi.gov

Any service not expressly listed above, such as connected services, is excluded from the scope and is not authorized for testing. Additionally, vulnerabilities found in systems from our vendors fall outside of this policy’s scope and should be reported directly to the vendor according to their Disclosure Policy (if any).

Reporting Process

The reporting process details the steps a researcher is expected to take following the discovery of a vulnerability. It explicitly lays out which vulnerability qualifies for reporting and how to report one such as through an email, form submission and any other means. Additionally, it spells out the details that must be included along with the tools and techniques used to discover the vulnerabilities.

Read how Zoom wants vulnerabilities to be reported:

We accept potential security vulnerability reports through our public Vulnerability Disclosure form Here. We will acknowledge receipt of your report within one business day.

What we would like to see from you

To help us triage and remediate potential findings, a good vulnerability report should:

• Describe the vulnerability, precisely where it was discovered, and the real-world impact.
• Offer a detailed description of the steps needed to reproduce the vulnerability (POCs, screenshots, and videos are helpful).
• Please include one vulnerability per report (unless in an attack chain).
• Don’t report automated scanner results without proof of exploitability.

Preferences

The section covers how a company will handle the vulnerability including how they will prioritize all incoming reports. It also indicates if and when public disclosure of vulnerabilities will be made. Some policies also include provisions that allow researchers to specify how they would like to be acknowledged for their work. 

Take a look at Consumer Financial Protection Bureau’s VDP snippet:

The CFPB is committed to correcting reported vulnerabilities in a timely manner. However, depending on the nature of your discovery, it may take time to validate and implement corrective actions. Therefore, we require that you refrain from sharing information about discovered vulnerabilities for 180 calendar days after your submission. If you believe others should be informed of the vulnerability prior to our implementation of corrective actions, we require that you coordinate in advance with us at security@cfpb.gov. 

Important guidelines

Some vulnerability disclosure policies have ‘detailed guidelines’ on rules of engagement to set boundaries with researchers. These can include notification rules after vulnerability discovery and a clause stating that exploits should not be used for any kind of data compromise.

Also, check out: The best vulnerability scanning tools

Bonus: Want to strengthen your network defences? Get our External Network VAPT Report and discover critical insights.

How are VDPs different from bug bounty programs?

The key difference between VDPs and bug bounty programs is that a VDP does not reward researchers for reporting a vulnerability, while bug bounty programs pay for discovering and reporting every bug or vulnerability. 

Bug bounty programs enable companies to leverage the expertise of ethical hackers around the globe. VDP, on the other hand, is more of a demonstration of the commitment to protect data by both researchers and vendors.
For a reporter, while a bug bounty is more lucrative, VDP is helpful in ensuring they deal with the discovery in a way that does not get them into trouble. And for a company, both bug bounty and VDP are ways of leveraging outside experts with security maintenance and upkeep.

Here are some examples of vulnerability disclosure policies and bug bounty programs:

HHS: https://www.hhs.gov/vulnerability-disclosure-policy/index.html

Coca Cola: https://www.coca-colacompany.com/policies-and-practices/vulnerability-disclosure

Netflix bug bounty program: https://bugcrowd.com/netflix

What are the types of vulnerability disclosure?

Depending on how the vulnerabilities are disclosed and who is disclosing them, there can be two bases of classification. Let’s look at the types of vulnerability disclosures based on the two classifications:

Based on how Vulnerabilities are released:

Private or responsible disclosures

Private or responsible vulnerability disclosure is the process of privately reporting the identified vulnerabilities to the organization or vendor and giving them sufficient time for patching and remediation. The vulnerability is publicly disclosed after it is fixed or the patch is developed or released. It is one of the most preferred types of vulnerability disclosures as it allows for mitigating the risk of exploitation by attackers before the fix is available.

The researcher and the organization or vendor mutually decide the period to fix the vulnerability.

Coordinated Vulnerability disclosures

Coordinated vulnerability disclosure involves a coordinated response from multiple parties to identify, patch, and disclose vulnerabilities. Once the vulnerability is disclosed to the organization or vendor, several parties, including the researcher, hardware and software developers, third-party vendors, etc., coordinate to fix it within a stipulated time. Once it is fixed, the vulnerability is publicly disclosed.

In certain cases, the communication with the organization or vendor may not be direct. The researcher in such cases discloses the vulnerabilities to US Computer Emergency Readiness Team (CERT) or private third-party providers who then coordinate with the vendors for vulnerability disclosure.

Full Disclosure

Full disclosure is the process of releasing the details of the security vulnerability in a public setting along with all technical details and exploitation code/proof-of-concept code. The public display of vulnerability details creates pressure on the organization or vendor to fix the vulnerability before its exploitation quickly.

Full disclosure comes with risks, such as the vendor or company’s bad reputation and the availability of exploitation code to malicious actors. It is, therefore, not a preferred type of vulnerability disclosure and is adopted when the researcher is not able to contact the relevant shareholders or wants a quick fix and is unsure of the disclosure method.

Based on who discloses the vulnerabilities:

Self-disclosure

Self-disclosure of vulnerabilities is a scenario in which product manufacturers or software developers discover a vulnerability in their offering and release the vulnerability details publicly along with the patch. This demonstrates a sense of ownership and responsibility while making it easier to solve the issues.

Third-party disclosure

Third-party disclosures involve the disclosure of vulnerabilities by external parties who are not the product owners or the software developers. In these cases, the external party acts as an intermediary and the security researchers who publish third-party reports inform the organization or manufacturing vendor about the vulnerability.

Vendor disclosures

Vendor disclosures occur when there is direct communication between the security researcher and the vendor. The vulnerabilities are directly reported to the vendor who then fixes the vulnerabilities and there is no involvement of CERT or third parties

How Sprinto can complement your vulnerability management efforts?

A Vulnerability disclosure policy is an essential marker of the security consciousness of the company. However, it’s only a starting point and you need better vulnerability management to ensure top-notch security and compliance. That’s where Sprinto comes in.

GRC automation tools like Sprinto can monitor controls tagged to the vulnerability management software you use or even JIRA. Sprinto ensures that vulnerability handling happens in a way that is in line with the security best practices and does not disrupt compliance or risk posture in any adverse way.

Vulnerabilities are things that auditors will see and review during your audit. Sprinto helps you show how vulnerabilities are dealt with and provides clear evidence or audit trail of the process in place. In that way it is complementary to vulnerability management and takes it to the next level.

Sprinto helps you show how vulnerabilities are dealt with and provides clear evidence or audit trail of the process in place. In that way it is complementary to vulnerability management and takes it to the next level.

Sprinto ensures that you adhere to security policies and SLAs and sends time-bound alerts whenever things are off-track. Monitored workflows, automation and centralization makes everything easy to track and manage. The prioritization mechanism helps you remediate high-impact vulnerabilities as per the set rules and on time.

We have served thousands of companies across the globe and helped them achieve compliance across 20+ frameworks. Learn more and watch Sprinto in action to kickstart your compliance journey.

FAQs

What happens if the vulnerability is not patched within the agreed timeframe?

There can be several outcomes if the vulnerability is not patched within the agreed timeframe depending on the policy agreements:

• The organization can request a grace or extension period
• There can be issue escalation
• Temporary fixes may be applied
• A full-fledged review of patch management practices
• In certain cases, the researcher may publicly disclose the vulnerability

What should a researcher do if the vendor considers the vulnerability invalid or doesn’t fix it?

If the researcher believes that the vulnerability is valid but the organization does not fix it, the researcher must try to engage in a conversation and provide detailed proof of concept. If the organization stands firm on its decision,, the researcher can notify the CERT or other coordination centers to resolve the issue.

How to find the right person to contact for reporting a vulnerability disclosure?

Most organizations clearly share the contact details in the VDP. If there is no VDP then you can look for bug bounty program sites or look for social media platforms, contact us page, use tools that help find domain owners or reach out to the community.

How to implement a vulnerability disclosure program?

To implement a vulnerability disclosure program:

• Start by deciding the scope of the program ie. the assets to be covered under the program
• Create a mechanism for reporting the vulnerabilities
• Draft a vulnerability disclosure policy with all key components such as reporting process, guidelines, preferences etc.
• Make the policy publicly available