- No Disclosure – When a vulnerability is found, all information about the vulnerability is kept private. Sometimes this is enforced by non-disclosure agreements (NDAs). Vendors sometimes prefer this scenario to protect secrets, as well as certain researchers that wish to do the same.
- Limited Disclosure – When a vulnerability is found, only some information about the vulnerability is disclosed. The goal is typically to slow down reverse engineering and exploit development long enough for a fix to be developed and deployed. This is done by withholding proof of concept code or other technical details of the vulnerability.
- Full Disclosure – When a vulnerability is found by a reporter, all information about the vulnerability including proof of concept should be disclosed immediately. The belief is that this disclosure serves the greater good by allowing consumers to be aware of issues in their products, and demand action from vendors, as well as have information available to make more informed purchasing decisions. Security researchers tend to favor this approach. The vendor is typically not informed prior to disclosure, or at least has a very small window (typically < 1 day) to act. Alternately, this type of disclosure may also be performed by the vendor themselves: many open source projects, for example, handle security issues in the open in order to maximize review of the vulnerability and testing of the proposed solution.
- "Responsible" Disclosure – When a vulnerability is found by a reporter, the reporter informs the vendor that the information will be disclosed in a set timelineand suggests a timeline for disclosure. The amount of time varies greatly based on the organization. The vendor is and reporter typically expected to adapt to the schedule imposed by the reporterwork together to provide a simultaneous public disclosure after a patch is ready. The disclosure may be Limited Disclosure or Full Disclosure after the timeline has expired. In cases where the vendor and reporter do not agree on a timeline, or the vendor is unresponsive, the reporter may publish anyway at the end of the original proposed timeline. In the CERT/CC's opinion, the term "responsible" is too vague and can confuse reporters. The responsible goal should be obtaining a fix for users; only informing the vendor of the existence of the vulnerability may be insufficientword "responsible" tends to draw focus toward "good" and "bad", rather than objectively searching for a way to address a problem that was discovered.
- Coordinated Disclosure – When a vulnerability is found by a reporter, the reporter informs the vendor of the vulnerability and suggests a timeline for disclosure. The reporter and vendor negotiate and coordinate (sometimes through a 3rd party such as the CERT/CC) on the timeline, and disclose information on the vulnerability jointly at an agreed upon time. Typically, a Limited Disclosure occurs at that time, but Full Disclosure is also possible if agreed upon. If a timeline cannot be agreed upon, this disclosure scenario may turn into Full Disclosure. Coordinated Disclosure is the CERT/CC's preferred terminology for the older "Responsible Disclosure". Among others, Microsoft has advocated for coordinated disclosure. Otherwise, Coordinated Disclosure and Responsible Disclosure are the same thing.
Another take on this issue is provided at Wikipedia.