Vulnerability Disclosure Cheat Sheet
Last revision (mm/dd/yy): 10/9/2017
This cheatsheet is to help people report vulnerabilities they can find either randomly, either through security research.
Disclaimer: No warranty - consult lawyer!
Remember if they are rules defined by a bounty program or laws applied to your country. Document every step allowing to identify vulnerability, and if acceptable in your context, how to exploit it.
It is recommended to use responsible disclosure when dealing with vulnerabilities
Depending on your context, each step may have more or less important time interval. Be flexible. Encourage trust, transparency and openness. Timeline of full disclosure is always a debate especially if there is active exploitation. Be considerate of the work necessary to do the fix while balancing with public interest.
Examples of public disclosure timeline and methodology
Report should include all details necessary to understand vulnerability and reproduce it (exploit code for example). If you identify limiting factors, include them (Non-Admin user, use of Ms EMET, security HTTP headers...).
If possible, use encryption like PGP/GPG to encrypt your report. You can use Encrypt.to to do from a web browser if recipient has a public key. If you want to remain anonymous, it's probably better to use pseudonym and one-time use email on Tor network or similar. Intermediate party might also be available like ZeroDisclo but ensure target destination is relevant (In 2017, mostly FR & EU).
If you think your lessons learned would be useful to community, share it (anonymously or not).
Most western countries have an exception for interoperability and security research but...
« Full disclosure is the practice of publishing analysis of software vulnerabilities as early as possible, making the data accessible to everyone without restriction. The primary purpose of widely disseminating information about vulnerabilities is so that potential victims are as knowledgeable as those who attack them. », Wikipedia
« The issue is reported privately to the vendor *and no one else* until the vendor issues a patch. », Microsoft, 2010
« Coordinate public release happens, ideally, when the vendor releases the update. In the case of publicly verifiable active attacks, details may be released prior to an update being released, with emphasis on giving details to protection providers. », Microsoft, 2010
« The vulnerability is released to a small group of people (not the vendor) or kept private »
Other definitions : CERT/CC
Feel free to provide other countries!
Authors and Primary Editors
OWASP Montréal, v1.0, Jul 2017. https://www.owasp.org/index.php/Montréal
Thanks to OWASP Montréal chapter, @el_d33 and gosecure.ca team for review!