Guidelines and Practices for Multi-Party Vulnerability Coordination and Disclosure

Version 1.0
Released July 6thth, 2017


Vulnerability disclosure events over the past few decades have led to more than one effort to document vulnerability coordination and disclosure philosophy, policy, and practice. Historically, such efforts have focused on bi-lateral coordination (one finder and one vendor) and have not adequately addressed the additional complexities of multi-party vulnerability coordination (multiple vendors and other stakeholders). Factors such as a vibrant open source development community, the proliferation of bug bounty programs, third party software, and the support challenges facing CSIRTs and PSIRTs are just a few of the complications. Examples such as Heartbleed1 highlight these coordination challenges.

The purpose of this document is to improve multi-party vulnerability coordination across different stakeholder communities. This document is the outcome of an effort between the National Telecommunications and Information Administration (NTIA)2 and the FIRST Vulnerability Coordination SIG3.

Multi-party coordination and disclosure involves multiple vendors and can also include coordinators, defenders, users, and other stakeholders. While this document focuses on multi-party coordination and disclosure, a considerable amount of material also applies to more basic bi-lateral scenarios.


This document consists of two main sections: Guiding Concepts and Best Current Practices that are derived from a set of Multi-Party Disclosure Use Cases. The use cases were developed first, based on the experiences of the contributors participating in multi-party disclosure events. The use cases are further broken down into exceptions called variants, and each variant lists causes, prevention, and response. Prevention and response activities that occur repeatedly or are otherwise deemed to be important are organized into the Guiding Concepts and Best Current Practices section.

Practices are denoted as strong recommendations (“should”) or suggestions (“can,” “could,” or “may”).


Within the context of this document, the following definitions apply. Definitions that are available in ISO/IEC 29147:20144 are used with minimal modification.

Stakeholder Relationships

Figure 1 shows conceptual relationships and communication paths between stakeholder roles.

Stakeholder roles and communication paths Figure 1: Stakeholder roles and communication paths

Guiding Concepts and Best Current Practices

The following guidance is derived from the Multi-Party Disclosure Use Cases and variants discussed later in this document. The most important response and prevention practices, particularly those that occurred repeatedly, are captured here. In general, stakeholders should carefully consider actions that have widespread effects on others, particularly sharing sensitive vulnerability information and public disclosure.

Establish a strong foundation of processes and relationships

Maintain clear and consistent communications

Before public disclosure
After public disclosure

Build and maintain trust

Stakeholders should encourage security research and coordinated disclosure within relevant legal frameworks. Legal or other coercive pressure, actual or perceived, often creates a chilling effect on desired security research.

Minimize exposure for stakeholders

Respond quickly to early disclosure

Use coordinators when appropriate

Multi-Party Disclosure Use Cases

Vulnerability disclosure can be a complicated process, especially when multiple parties (usually multiple vendors) are involved. This section of the document is organized as a set of vulnerability disclosure use cases, in rough order, from simple to complex. Significant attention is given to coordinated, multi-party disclosure (see Use Case 2: Vulnerability with coordinated disclosure). Disclosure often deviates from the expected or ideal process, so within each use case are variants that are common exceptions to the ideal use case. Within each variant are causes, preventions, and responses. The collected set of preventions and responses are presented as practices that can be used to reduce the occurrence and cost of expected variants.

Use Case 0: No vulnerability


This case is included for completeness, if there are no vulnerabilities, there is no need for coordination or disclosure.

Use Case 1: Vulnerability with no affected users

Vulnerability with no affected users Figure 2: Vulnerability with no affected users


A vulnerability in software or hardware with no users is a security hole that does not affect anyone else in any way. Examples of this case include: products that are (a) non-production, experimental (e.g., webgoat10), (b) internal or for personal use, (c) never published or sold, or (d) under development.

Vulnerability is discovered and fixed before the product is deployed. Vendor takes steps to prevent recurrence of the vulnerability. No advisory required for users.

Coordination is not required, except:

Variant 1: Product is deployed before vulnerability is discovered or fixed


The product is shipped and available with one or more existing vulnerabilities. The vendor discovers the vulnerabilities and corrects them. The vendor releases an updated version of the product and takes steps to prevent reoccurrence. The vendor, then, publishes an advisory.


Use Case 2: Vulnerability with coordinated disclosure

Vulnerability with coordinated disclosure Figure 3: Vulnerability with coordinated disclosure


Many security vulnerabilities are discovered after the product is released. Multiple stakeholders such as finders, upstream vendors, vendors, defenders, and users are involved in the coordinated disclosure effort. Stakeholders are encouraged to follow some guidelines set out by international bodies like ISO, to formulate the basis of their disclosure practice.

In a generalized coordinated disclosure process, the following stakeholders perform certain roles.


Variant 1: Finder makes the vulnerability details public prior to remediation


There may be instances in which a finder publicly releases details of a vulnerability prior to remediation, which can increase risk to affected users. Although a known active exploitation may prompt the finder to publicly disclose prior to remediation, other causes for disclosure include inability to establish contact with vendor and financial or other motivations for finder disclosure. Preventing public release prior to remediation is ideal, but in cases where early public release happens, quick response and communication of potential mitigations is paramount.


Variant 2: Users do not deploy remediation immediately


Providing remediation alone is not sufficient to reduce risk, deployment is also necessary. There may be instances in which users do not deploy either the remediation or the vendor suggested mitigations immediately after being made available by the upstream vendor. In general, users are strongly encouraged to apply, where possible, a risk-based approach in deciding how quickly they should deploy vendor-supplied remediations or mitigations when made available to help reduce potential risk of exploitation. Vendors responsible for issuing remediations or mitigations for critical and high severity vulnerabilities should communicate the availability of such as broadly as possible, along with clear deployment and recommendations.


Variant 3: Missing communication between upstream and downstream vendors

Missing communication between upstream and downstream vendors Figure 4: Missing communication between upstream and downstream vendors


Direct communication or a security disclosure could be missing between upstream vendors and downstream vendors or between vendors and users. A coordinator could facilitate receiving and distributing information back and forth to relevant parties at various stages of remediation.


Variant 4: Vendor makes the vulnerability details public prior to remediation


Multi-party vulnerability disclosure often involves complex interaction among stakeholders. It is possible for a vendor to disclose the vulnerability details publicly prior to remediation. In many cases, such disclosure is accidental and a plan for damage control should be in place. A review of the incident afterwards should take place to prevent occurrences in the future.


Variant 5: Vendor does not remediate a reported vulnerability


There may be situations in which the vendor does not provide remediation to a vulnerability. There are many causes for such a scenario including the vendor no longer existing, the affected product no longer being supported, or the vendor being unable to verify the finder’s report or the vendor not considering the report to be a vulnerability. Establishing clear communication and dialogue between the reporter and vendor is foundational to establishing a plan of action, whether that be remediation or mitigation.


Variant 6: Some peer vendors are unware of the vulnerability or coordination


Missing or poor communication between peer vendors can negatively impact coordination efforts. In some cases, this is due to lack of awareness of the uses and impacts of a common component or technology, or it may be difficult to identify and coordinate with affected peers. Use of third party coordinators and investing in developing and maintaining an awareness of peer vendors are just two ways of managing these complexities in multi-party coordinated response.

Example 1: A vulnerability named ‘httpoxy’ affected many CGI or CGI like environments.
According to httpoxy.org15 , it was first discovered in 2001. Over the years the issue was rediscovered many times. Its impact on other peer CGI implementations was never investigated. In 2016 when an exploit was discovered in the wild, the issue was widely investigated across various CGI implementations and 14 CVE IDs were assigned.

Example 2: CVE-2008-1447
CVE-2008-1447 is a vulnerability in DNS protocol that was first mitigated by UDP source port randomization idea implemented in djbdns in 1999. While importance of this mitigation was emphasized on public mailing lists, many other DNS implementations lacked this mitigation until 2008. When a practical exploit for this vulnerability was demonstrated in 2008, the source port randomization mitigation was widely implemented.


Variant 7: Coordinator makes vulnerability details public prior to remediation


In this variant, a coordinator discloses vulnerability information publicly before remediation is ready. As in previous variants, disclosure may be accidental, or a coordinator may intentionally disclose due to the perceived defensive benefit. Similar to other variants, setting expectations and communicating clearly can reduce accidental disclosures.


Use Case 3: Public disclosure of limited vulnerability information prior to remediation

Public disclosure of limited vulnerability information prior to remediation Figure 5: Public disclosure of limited vulnerability information prior to remediation


Some information about the vulnerability is published, without giving any hints about the exploit. This use case is different than what is typically called “full-disclosure.”

As a middle way between full public disclosure and a privately coordinated disclosure, a vendor may publish some preliminary information about the existence of a vulnerability and its disclosure timeline. Information disclosed may contain names of vulnerable product or component, worst case impact, and location of future advisories, but not provide any hints about exploiting the vulnerability such as source code changes or vulnerability type. This disclosure scenario is common when a large number of vendors are affected and maintaining confidentiality can be difficult.

Such advance notice helps all the responding parties (including upstream and downstream vendors, users, and defenders) to plan and prepare to respond to the disclosure. Preparation may involve identifying potentially affected products and assets and identifying and scheduling personnel.

For limited disclosure to be effective, the information provided (particularly scope and severity) must be accurate and reliable. While finders16 and coordinators17 sometimes practice limited disclosure, vendors usually have more complete information, less incentive to exaggerate, and more authority when disclosing vulnerabilities in their own products and services. The uncertainty that accompanies a non-vendor limited disclosure can lead to speculation and inefficient response effort.

Example 1. Vendor advance warning:
On April 28, 2016, OpenSSL project team announced a new software release with fixes for several ‘high’ severity security defects that was made available on May 3rd, 2016.18 The users and downstream vendors had five days to plan and prepare for taking response measures, thus minimizing the preparation time required for the responders. OpenSSL practices limited advanced disclosure for some vulnerabilities.19

Example 2. Vendor expected cadence:
Oracle published Critical Patch Update Advisories on a pre-determined quarterly schedule. According to Oracle20, a pre-release announcement is also published five days prior to each Critical Patch Update release with a summary of affected products and risks. This notification serves as a trigger to initiate a customer’s patching procedure.

The variations, including causes, preventions, and responses from Use Case 2 also apply to Use Case 3.

Use Case 4: Public disclosure or exploitation of vulnerability prior to vendor awareness

Public disclosure or exploitation of vulnerability prior to vendor awareness Figure 6: Public disclosure or exploitation of vulnerability prior to vendor awareness


When a vulnerability is discovered in a deployed product. The finder makes the information about the vulnerability accessible to anyone such as publishing on the Internet, mailing lists, academic papers or conferences. Disclosed information may include affected products and versions, proof of concept test cases that can trigger or demonstrate the vulnerability and detailed explanation of the defect or attack methodology. This disclosure is made without waiting for development or deployment of a remediation or mitigation. This type of disclosure is often referred to as “full disclosure” or a “zero-day.”

One of the main intentions here is to make users aware of the vulnerability as early as possible as a way to minimize exposure, with an assumption that there could be unknown attackers who may already know about the vulnerability and could be exploiting it.

A survey21, of about 400 researches, indicates that only 4% of the finders follow full public disclosure versus 92% of finders that follow some form of coordinated disclosure. While such disclosures are rare, vulnerability responders (vendors, defenders, users) should be prepared to handle disclosures anytime.

Example 1: A paper22 presented at AppSec California in January 2015, described remote code execution under certain context related to Apache Commons Collection. Apache Commons project was not informed23. On November 2015, a blog post24 was published containing exploits based on this paper for multiple products. None of the vendors or open source projects were directly notified prior to disclosure.

Example 2: The past few years several organizations have suffered data-leaks, apparently performed by activists who disagree with the behavior of the targeted organizations. In 2015 a large mail archive was leaked from Hacking Team25 and in 2016 several tools from Cellebrite26 were posted online. The activists chose to publish all of the leaked data without prior analysis or selection. The vulnerabilities that these organizations discovered were disclosed publicly without informing the vendors beforehand.

Variant 1: Finder publishes vulnerability details and vulnerability is exploited


In this variant, a finder publicly discloses detailed vulnerability information without first having notified the vendor. Attackers can use this information to develop exploits and attack systems before vendors have prepared a remediation. Typically, attackers can develop attacks faster than vendors can develop a remediation and users can deploy them. This variant is commonly called a “zero-day” disclosure.


Variant 2: Previously undisclosed vulnerability used in attacks


In this variant, a vulnerability becomes publicly known because of its use in attacks. This variant is also referred to as a “zero-day” vulnerability or exploit, since vendors and defenders have not had a warning in advance. This is usually a very harmful scenario since vendors, defenders, and users rush to respond while under attack. Exploitation of a vulnerability in an attack can be considered as a disclosure of the vulnerability or a confirmation of its existence. The attacker typically wants the vulnerability and its exploitation to remain undetected and undisclosed.


Supporting Resources








  7., see AB4 




  11. OpenSSL CVE-2016-2108: A vulnerability was fixed in OpenSSL June 2015 releases, but was not recognized as a vulnerability until May 2016. Downstream Vendors who upgraded their OpenSSL code base to the latest stable release in June 2015 had effectively resolved this vulnerability eleven months ahead of vendors who selectively patched only the vulnerabilities recognized with CVE IDs. 
















  27. Coordinated vulnerability disclosure is often considered part of the deployment, maintenance, or support phases of a Secure Software Development Lifecycle.