No, we won’t start another discussion about the ethics of disclosing security vulnerabilities to the public, but we need to discuss how Y-Security handles the disclosure process. We believe that with the knowledge about a security issue there comes a responsibility in handling it for a wide field of users. This also includes users and environments that we are not even aware of. To keep those users safe – and those we are not even aware of – we do need to make security issues in software products publicly available.

As we know now – we need to make the knowledge public. The question that follows is „When should it be made public?“. An easy answer would be „When the patch is ready to be shipped!“. Sadly, numerous examples exist that keep the disclosure time in vendor hands, which does not always work. It is so common that it even received its own category at the Pwnie Awards, which are celebrated yearly at the Black Hat USA event in Las Vegas.

There is no defined industry standard, but we have reviewed the GitHub and Google’s vulnerability disclosure policy. Both match to a big extend with our goal and therefore, we have decided to align to Google’s policy with the following terms:

• 90-day disclosure deadline, or sooner if the vendor releases a fix
• Disclosure only on German workdays
• 7 days disclosure deadline, if we believe the issue is under active exploitation („0-day“)
• Immediate disclosure, if parts of the issue are disclosed by the vendor prior to the deadline

As always, we reserve the right to bring deadlines forwards or backwards based on extreme circumstances.

Creating pressure towards more reasonably timed fixes will result in smaller windows of opportunity for attackers to abuse vulnerabilities. In our opinion, vulnerability disclosure policies such as ours, result in greater overall safety for users of the Internet.

You can find our disclosure policy linked at the bottom of every page and if you are a vendor, then you have received it as part of our vulnerability submission.