Recently I became enamored by the concept of Responsible Disclosure. After reading up on the topic, I began digging at what various companies are doing on this particular topic. Unfortunately I found that this information was extremely hard to come by. Information on points of contact, disclosure policies, and various other bits are well fragmented.

I also searched for some sort of database or website on the topic and I was only met by other websites or blogs that noted how hard it was to find information on the topic. The only standard I found on the topic was a draft IETF document from May 2002 which was never ratified. IETF did ratify RFC 2142 which noted that companies should maintain a mailbox for the purpose of “Security bulletins or queries.” Unfortunately most companies either do not know about this RFC or simply choose to not follow it.

To help solve this issue, I’ve put together a comprehensive list of various “Responsible Disclosure” webpages for various vendors, companies, and organizations that post their information publicly. I plan on hosting and maintaining the document perpetuity.

Responsible Disclosure List

If you discover any errors or would like to include your organization’s information, all I ask is that you contact me with the relevant pieces of information to update.

Recommendations for companies

From forming the list above I’ve come up with a non-exhaustive list of recommendations to companies that are thinking about posting policies publicly.

  • Do it. You have everything to gain and nothing to lose from being open and transparent
  • Have a point of contact and be responsive. As noted earlier, security@ is RFC2142 compliant in lieu of this list, researchers would likely try that email address.
  • Reward researchers. Whether that is through a Bug Bounty program, a funny hat, or a simple thank you, researchers will be more likely to responsibly disclose if they are incentivized
  • Generate and publish a PGP key. It is amazing how many organizations do not do this for such a sensitive topic as vulnerabilities.

Recommendation for researchers

If you’re thinking about reporting a vulnerability to a company on the list, I’d recommend that you:

  • Know your rights. EFF published the Coders’ Rights Project Vulnerability Reporting FAQ which covers many commons questions that you may have when reporting a vulnerability
  • Understand the company’s policy. Some companies have very strict and well thought out policies on this topic. If you’re seeking monetary or other rewards from a Bug Bounty program, make sure you read it front to back before moving forward. When in doubt, ask the company to clarify their policies
  • Be responsible. Understand that real people with busy schedules are on the other side of email address you reached out to. For a rule of thumb you should: expect a non-robot replies within 48 hours and up to 60 days of time required to resolve the issue (although Google claims most issues can be solved within 7 days).

I hope I was able to cover this topic in some level of detail that was useful to you my dear reader. If you have a question or would like me to clarify something, feel free to reach out to me.