Vulnerability Coordination and Disclosure Policy (update)

Dear Vendor,

You probably reached this page because I referred to this policy when I reported a potential 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 you concerns. Failure to do so might result in immediate disclosure of my analysis and possible vulnerabilities. 

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

The likelihood of rediscovery of  is proven to be relatively high, hence 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 the choice under full access to your product line, code and ressource, that my report is solely a bug that poses no risk to your customers - hence publication 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 again, irregardless 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 with these vendors.

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

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.

__________________________________________________________________________________

END OF Policy/Agreement

Vulnerability notification procedures

If you are a smaller vendor, or a vendor that has not yet invested in vulnerability notification response procedures, you'll find a draft version of a security response procedure below. The work flow below is willingly from a macro viewpoint and not detailed, the reason being that a lot of the details depend on what development process you are using - Spiral, waterfall or scrum to name a few.