Dear Thierry, why are you such an arrogant asshole?
I don't think I am.

That question really arrived in my inbox, in relation to the recent advisories and forced disclosures [1],[2] . Forced disclosure means that since the vendor hasn't reacted I consider myself forced, (ethically, because you don't want customer to run the risk of not knowing) to disclose the issue. In the last month this happened for Avast, IBM and Fortinet. (In all fairness, fortinet actually replied to my third try to reach them)


Let me get you up to speed: The disclosure policy that I adhere to didn't spontaneously spring out of my head, it is based on Secunias' policy. 

As I have reported quite some bugs in the recent years, and faced some problems with certain vendors, it immediately pleased my mind. I made some changes to it and there it was. It is straight forward and fair. It gives the vendor the chance to react, test their code, share their insight. If however the vendor does not answer this proves that either the vendor doesn't care about the security of their customers or that the vendor has simply not received the mail. 

This however is not really an excuse, the international standard addresses for security notification reports are well known (secure@ / security@) furthermore, repositories such as OSVDB exist where vendors can (an should) enter their security email address should it differ from the standard addresses - see, it's not the "researchers" fault if there was no reply, or reception.

Actually in my experience it's most often the vendor that simply ignores your e-mail and/or silently patches the bug in the next release.

So why do I do it then :

1. You see, responsibly disclosure goes both ways, and several vendors have yet to understand that. As a "researcher" you are bound to be responsible towards the vendor but also towards their customers and end-users. If there is a hole in a piece of code that runs at various customers, they should know they have that hole. If the vendor thinks that hole is minor, they should know the vendor thinks it's minor. If there are discrepancy in perception between the vendor and the "researcher", they also deserve to know. Not because the "researcher" is arrogant or suffers from delusions of grandeur, but the researcher thinks that the vendor has not had the complete oversight when rating the issue, and he wants the customers to know.
   
   Advisories are the essence on what risk management lies upon, no advisory and a risk manager lies in the dark about a particular issue. This by the way is also the reason why I think that the IMPACT of a vulnerability and a good description of it is often more important than releasing POC files and very detailed technical advisories.
   
   
2. Create the necessary business incentives for vendors invest in security vulnerabilities notification procedures, patch procedure, SDL processes and human capital. 
   
   Yes you read correctly, if we as "researchers" do not publish bugs, including verbose time lines and how vendors reacted, there is nearly no (apparent) business incentive for a vendor to create such teams and procedures. Why do I say that there would be no incentive. Simple, it's not visible, how often do you have reported a vulnerability ?
   
   Here is something that should be of interest to you: Customers (and mainly large enterprise customers) absolutely love reading vulnerability notification time lines. It proves or disproves that the million dollar license fees they invested in a company's' product is a good investment that the vendor really cares about the security of their products (and hence the customer) and it gives direct insight on how long it takes them to react.
   
   At this point everything comes together, customers that are interested in holding their vendor to account have then grounds to ask for a more professional approach, sometimes even considering a change to another vendor. This is what creates the very business incentive that I want to see. If it worked with Microsoft it works with everybody. Ask them.
   
   
3. And this leads me to another reason why the policy is more aggressive than that of Rain Forest Puppy. Vendors do silently patch. They take your notification, don't reply and magically the problem is gone in the next version. If you ask them - if they reply at all - they claim it has been found during internal tests. However it is common practice that even rediscoveries are credited - some however don't.
   
   
4. Free labor. I expect a certain degree of professionalism - reporting vulnerabilities is am doing free work for a company that make millions. Discovering and coordinating  vulnerabilities  is free work. I have not introduced those vulnerabilities in the first place, if they are within the product of the vendor, it's because you either didn't invest in controls or their controls failed. In any case, it's their problem.
   
   
5. NOT doing so is unfair to vendors that do respect researchers, invest money, time and effort. I have reported over 900 vulnerabilities in products, out of those 900 only 1% were voluntarily published by the vendor without me publishing first. I am able to tell due to particular circumstances.
   
   And where did that lead us to? Screwed statistics and false assumptions.
   
   Charts displaying that one vendor was being "more vulnerable" than another, when in fact it is exactly the opposite. Vendors hat did not publish their vulnerabilities had a lot more holes then those that published. And that, in my book, is not an acceptable situation towards a vendor that respected both researcher and their customers.
   
   An it is this very fact that  lead me to the conclusion that everything even the low priority issues deserve disclosure, especially if the vendor doesn't answer.

Dear Vendor,

You probably reached this page because I referred to this policy when I reported a vulnerability within your products. This policy represent the terms under which I am willing to coordinate disclosure with you.  Should you not be able to meet the requirements please notify me beforehand so we can discuss your concerns. Failure to do so might result in immediate disclosure of my analysis and  vulnerabilities. 

The rationale behind this policy (and ultimately it's reasoning) is that I am obliged to protect the customers, end-users as well as you the vendor.

The likelihood of rediscovery of vulnerability is a  proven fact and likely to be relatively high. The longer the time frame between discovery and patch the higher the chances this vulnerability is (re)discovered and used by malicious entities against you and/or your customers.

Source: Jason

Please understand that this is a free service too you, I have not sold the information on the open market [1, 2] and have taken the time to report it to you. I am trying to help you protect your customers. 

If you don't consider the bug I reported to be a security bug, it will be published without further coordination (see here). 

The reasoning behind this action is simple, you made this choice with full access to your product code and ressources and decided that my report represents solely a bug that poses no risk to your customers - hence the publication of it cannot possibly pose an issue to you.

Things to be communicated in order to correctly inform your customers and myself correctly:

• Affected product ranges, including exact version information.
• Advisory location and patch release schedule
• CVE number

Begin of Terms/Policy 

___________________________________________________

You are not allowed to share any details, proof of concept files with other vendors, irregardles of what your own policy or even terms say. I own the copyright on the code/examples and anything else submitted, regardless of your terms.

Should a request from a third party reach you, please simply forward it to myself, I will happily provide further details and work directly with these vendors.

1. If no security contact is known for the vendor and no security contact can be found at HackerOne, an e-mail requesting the security contact e-mail address may initially be sent to certain public e-mail addresses associated with the vendor. Online forms may only be used to request security contact information.
2. When a security contact or other relevant e-mail address has been identified, a vendor initially receives a mail with vulnerability details along with a pre-set disclosure date (usually set to a Wednesday 4 weeks later). 
3. If the vendor does not respond to the initial mail within a week, it is resent. 
4. If no response has been received at the day of the pre-set disclosure date, the vulnerability information is published immediately without further coordination attempts. 
5. If the vendor responds to either the initial mail or the resent mail, a new disclosure date may be set in case the vendor cannot meet the pre-set date.
6. I expect to receive continuous status updates from the vendor and a list of all affected products. Should no list be given it is assumed all products are vulnerable. 
7. Should a vendor not respond to a status update request, it is resent.
8. Should the vendor not respond to two consecutive status update requests, a mail is sent to the vendor advising that the vulnerability information will be disclosed a week later if no response is received. Has no response been received by this date, the vulnerability information is immediately published without further coordination attempts.
9. Eventually, the vulnerability information will be published if:
   a) The pre-set/agreed disclosure date is reached.
   b) The vendor issues a fix and/or security advisory
   c) Information about the same vulnerability is published by a third party.
   d) A year from the initial contact date has passed
   e)The vendor denies the security nature of the bug and/or gives no credit or other form of compensation 
10. Unless the vendor asks for an extension, I will not coordinate a vulnerability disclosure for more than 5 months. After 5 months the details will be published regardless of patch availability.

Additional Clauses 

Transparency clause: You may be quoted or the complete e-mail communication may be published if I deem it necessary.

____________________________________________

END of Policy/Agreement