Dear Thierry, why do you behaved like an arrogant asshole?

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 you are forced , that means - 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)

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

Let me get you up to speed: The disclosure policy 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 suffer 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 business incentives to invest in security vulnerabilities notification procedures, patch procedure, SDL processes and last but not least the personal behind it. Yes you read correctly, if we as "researchers" do not publish bugs , verbose time lines and how vendors reacted, there is nearly no (apparent) business incentive for a vendor to create such teams and procedures. (Yes realistically of course there is, but it's not apparent to everyone and that means : management). 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 interesting for 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 companys' product is good invested that the vendor really cares about the security of their products and gives further insight on how long it takes them to react.
   
   It's here where the lines join each other to form a circle, those sensitive clients are then going to ask for a more professional approach, sometimes even mentioning a change to another vendor (seen that happen) and only then, it becomes a business incentive, and money will be invested. 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 silent patches, 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. Even if so, rediscoveries are usually credited.
   
   
4. Free labor. I expect a certain degree of professionalism when I am doing free work for a company, and reporting a vulnerability (even if it's just a potential one) is free work. I have not introduced those bugs that became vulnerabilities in the first place, if they are within your code, it's because you have either have not done your job correctly or they weren't found during audits (which is a normal thing to happen even for the best). In any case, it's your 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 can tell because, due to some circumstances, I couldn't publish a great percentage of them).
   
   And what did that lead us to? Screwed statistics and false assumptions.
   
   Charts displaying that one vendor was being "more vulnerable" than another. Was this the truth ?(as in "entire story"). No it wasn't, actually it was far from that, the vendors that did not publish their vulnerabilities had a lot more holes then those that published. Was that fair to the vendor that respected me and their customers. Clearly, no. This lead me to the conclusion that everything even the low priority issues deserve disclosure, especially if the vendor doesn't answer.