Modes of Public Vulnerability Disclosure
A proposed taxonomy...
- Discovery: A finder discovers a vulnerability in an organization.
- Documentation: The finder generates information about the vulnerability in a vulnerability report.
- 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 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 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.
Coordinated Disclosure
Responsible disclosure attempts to find a reasonable middle ground between these two approaches. With co-ordinated 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 uses as it's guiding security policy. Intermediaries like Bugcrowd put pressure on this model, as the use of our services implies that these operational details have been worked out proactively within the organization offering the policy.
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.
Google's Project Zero adopts a similar approach, where the full details of the vulnerability are published after 90 days regardless of whether or not the organization has published a patch.
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 focussed on mimicking a third-party consulting model that it is on managing the disclosure process itself.
Full Disclosure
NOTE: Bugcrowd never encourages Full Disclosure in our programs. Full Disclosure is a little like "death and taxes" - It exists as the default failure-mode for unsuccessful vulnerability reports.
With the full disclosure approach, the full details of the vulnerability are made public as soon as they are identified. This means that the full details are made available to the public, including attackers before a fix is available. Full disclosure is primarily used in response to a negative response, organizations ignoring and failing to fix reported vulnerabilities, or as an option of last resort when an organization is non-responsive. Full disclosure has the effect of putting pressure on the organization to develop and publish a fix.
This makes the full disclosure approach very controversial, and it is seen as irresponsible by many people. Generally, it should only be considered as a last resort, when all other methods have failed, or when exploit code is already publicly available.