Modes of Public Vulnerability Disclosure: A 2026 Update

A proposed taxonomy for understanding how security vulnerabilities move from discovery to public knowledge... and what's changed.

Back in 2021, I wrote about the different modes of public vulnerability disclosure. The framework still holds, but the landscape has shifted. Let's revisit the taxonomy with updated context on how coordinated disclosure timelines have evolved.

A proposed taxonomy...

When a security researcher finds a vulnerability, three things happen in sequence:

1. Discovery: A finder discovers a vulnerability in an organization.
2. Documentation: The finder generates information about the vulnerability in a vulnerability report.
3. Distribution: The finder then chooses whether this information is reported to the vulnerable organization, as well as if it is disclosed to the public.

The interplay between reporting and disclosure defines the different modes of vulnerability disclosure.

The modes of vulnerability disclosure

Discretionary (or Private) Disclosure

In the discretionary disclosure model, the vulnerability is reported privately to the organization. The organization may choose to publish the details of the vulnerabilities, but this is done at the discretion of the organization, not the finder—meaning that many vulnerabilities may never be made public. The majority of bug bounty programs still require that the finder follows this model.

The main problem with this model is that if the vendor is unresponsive, or decides not to fix the vulnerability, then the details may never be made public. Historically this has led to finders getting fed up with companies ignoring and trying to hide vulnerabilities, leading them to the full disclosure approach.

Full Disclosure

In the full disclosure model, the finder publishes the full vulnerability details publicly, often without any prior notification to the vendor at all. The philosophy here is that public pressure and immediate availability of information forces vendors to respond quickly, and that users deserve to know about risks to make their own mitigation decisions.

While this approach maximizes transparency, it also maximizes risk to end users who may be exposed to exploitation before a patch exists. It's a forcing function, but a blunt one.

Coordinated Disclosure

Coordinated disclosure attempts to find a reasonable middle ground between these two approaches. With coordinated disclosure, the initial report is made privately, but with the full details being published once a patch has been made available (sometimes with a delay to allow more time for the patches to be installed).

In the ideal case, the organization proactively publishes its own deadline for disclosure based on its ability to fix reported vulnerabilities, and makes the authorization for security researchers required for safe harbor conditional on adherence to this deadline. This approach is outlined in NIST SP 800-53 R5, which Bugcrowd and many other platforms use as their guiding security policy.

What's changed: When the organization does not publish its own deadlines, the finder often provides a deadline for the organization to respond to the report, or to provide a patch. If this deadline is not met, then the finder may adopt the full disclosure approach, and publish the full details.

The convergence on 90 days

Google's Project Zero has been a major influence here. Their current policy is 90 days from notification to disclosure, with an additional 30-day grace period if a patch is available but not yet widely deployed. This "90+30" model has become something of an industry standard.

Other benchmarks:

• CERT/CC: 45-day default, extendable in some circumstances
• ZDI: 120 days from initial vendor contact
• Microsoft MSRC: Generally aligns with 90-day expectations

The trend is clear: the industry has largely converged on 90 days as a "proactive, but rational" baseline for coordinated disclosure.

Setting your own timeline with Policymaker

The disclose.io Policymaker tool makes it easy to generate a vulnerability disclosure policy that includes your CVD timeline. The available options reflect what we've learned about rational disclosure windows:

The tool strongly recommends that organizations take a proactive approach to setting their own timeline and making it clear within their VDP. This puts the organization in control of the conversation, rather than leaving researchers to impose their own deadlines.

Non-Disclosure

The finder reports the vulnerability with the understanding that it is not to be discussed with the public at any stage. This mode is common in private crowdsourced security, which is more focused on mimicking a third-party consulting model—managing the client relationship rather than the public interest.

It's important to note that in the context of publicly discovered vulnerabilities (i.e., the vulnerability itself was already in the public domain, the knowledge of it was just unevenly distributed) a non-disclosure agreement is NOT appropriate. In the situation where a bounty is offered in exchange for an NDA, accepting this reward and these terms becomes a discretionary exercise for the researcher, with the default being to publish according to normal CVD process and etiquette.

Why this matters

Understanding these modes helps organizations make informed choices about how they want to handle vulnerability reports:

• If you want control: Publish your own CVD timeline in your VDP. Use Policymaker to generate compliant policy language.
• If you're a researcher: Look for the organization's stated timeline. If none exists, 90 days is a reasonable default—it gives vendors adequate time while maintaining accountability.
• If you're designing policy: The convergence on 90 days isn't arbitrary. It balances the vendor's need for remediation time against the user's right to know about risks affecting them. But the important thing to recognize is that sometimes, and for very good reasons, the CVD timeline can be longer—and other times it can be shorter. It all depends on the product, the company involved, and the risks to the user. A complex embedded system might legitimately need 180 days; a cloud service with continuous deployment might reasonably commit to 30.

The best vulnerability disclosure happens when both parties understand the rules upfront. Proactive, published CVD timelines make that possible.

This post is an update to the original 2021 version to reflect modern shifts in disclosure practices.