What Good Disclosure Looks Like

Origin and history

The concept of "What Good Disclosure Looks Like" emerged from the global cybersecurity community in the late 1990s and early 2000s. Its development was a direct response to the chaotic and often adversarial early practices of vulnerability reporting. This period saw frequent "full disclosure" practices, where vulnerabilities were published publicly without prior vendor notification, leading to widespread exploitation. The philosophy was formalized through the work of various security researchers and organizations who began drafting coordinated disclosure guidelines. These efforts aimed to establish a standardized, ethical process that balanced public safety with vendor remediation time. The principles have since been adopted and adapted by numerous national cybersecurity agencies and industry consortia worldwide.

What it is for

This framework exists to provide a clear, structured process for reporting discovered software vulnerabilities to the affected vendors or maintainers. Its primary purpose is to ensure that security flaws are addressed and patched before they can be widely exploited by malicious actors. It serves to protect end-users by minimizing the window of exposure between discovery and remediation. The process also aims to foster a cooperative relationship between independent security researchers and software vendors. Furthermore, it acts as a de facto standard that helps researchers navigate legal and ethical uncertainties when handling potentially sensitive security information. Ultimately, it is for reducing systemic risk across the digital ecosystem by enabling orderly and effective fixes.

Overview

Good vulnerability disclosure is a multi-stage process initiated when a researcher discovers a flaw. It begins with the researcher making a good-faith effort to privately contact the vendor, providing detailed technical proof of the vulnerability. The vendor then acknowledges receipt and works to validate, prioritize, and develop a patch for the issue. A critical component is the establishment of a reasonable embargo period, typically 90 to 120 days, during which the researcher refrains from public disclosure to allow for patch development and distribution. Upon the release of a patch or at the end of the agreed embargo, the researcher may publicly disclose technical details, often in the form of an advisory. The entire process relies on mutual respect, clear communication, and a shared commitment to security.

What to know

Researchers must know how to properly identify and document a vulnerability with clear proof-of-concept code and impact analysis before making contact. It is essential to know the correct security contact point for a vendor, which is often a dedicated email address published on their website. All parties should understand that the initial report should contain enough detail for the vendor to reproduce the issue but should not be shared on public channels. Knowing how to negotiate a realistic timeline for remediation is a key skill, as some complex vulnerabilities require more time to fix properly. Researchers must be aware of the legal landscape, as some jurisdictions have laws that could criminalize certain investigative actions, even for research. Everyone involved should know that the goal is a published patch, not public accolades or blame.

Common questions

A common question is what happens if a vendor does not respond to the initial disclosure attempt; standard practice is to follow up after a reasonable period, often 14 days, and then potentially involve a trusted intermediary. Many ask how long the embargo period should be, with the general consensus being 90 days from initial acknowledgment, though critical flaws may warrant a shorter timeline. Researchers frequently inquire about whether they can be sued for reporting a vulnerability, which highlights the importance of acting in good faith and following established guidelines. Vendors often question what level of detail is required in the initial report to begin their investigation without being overwhelmed. Another recurring question addresses whether a finder should be paid for their report, touching on the differences between coordinated disclosure and formal bug bounty programs. People also commonly ask how to handle disclosure for vulnerabilities in open-source projects, which follows similar principles but often involves contacting project maintainers directly.

Pros and cons

A major pro is that this process significantly increases the likelihood a vulnerability will be patched before it is weaponized, directly improving public safety. It builds constructive channels between external researchers and vendor security teams, leading to more secure products over time. The structured timeline provides vendors with predictable pressure to act, while giving them necessary breathing room for development and testing. A significant con is that the process can break down if the vendor is unresponsive or dismissive, leaving the researcher in a difficult ethical and legal position. Researchers often bear the burden of effort with no guarantee of recognition or reward, which can lead to frustration and a return to full disclosure. The common mistake is poor communication, such as vague initial reports or missed deadlines, which erodes trust and can cause the entire process to fail.

Who it suits

This model suits ethical security researchers who are motivated by improving systemic security and are willing to work within a structured, patient framework. It is ideally suited for established software vendors and technology companies that have the resources and maturity to maintain a dedicated security response team. The process also suits large open-source projects with active maintainer communities capable of evaluating and integrating security fixes. It is less suited for dealing with abandoned software or vendors that have ceased operations, where no responsive entity exists. The model can be challenging for individual researchers facing uncooperative vendors, as it requires significant persistence and diplomatic skill. Ultimately, it suits any stakeholder who prioritizes the reduction of real-world harm from software vulnerabilities over immediate publicity or conflict.