Vulnerability Disclosure Policy

Summary

This document outlines how DeepSurface engages with vendors to responsibly resolve and disclose security vulnerabilities. We’re here to help vendors and their customers stay safe, and we hope this document will provide transparency into our disclosure process. We encourage communication and will review each vulnerability on a case by case basis to minimize the impact to the general public.

Note that this document is merely meant to serve as a general guideline, and the actual procedure can vary from situation to situation. We reserve the right to modify this document or the procedure below to take into account any extenuating circumstances.

Rationale

We understand the importance of providing a clear and transparent policy for vendors. Disclosure is a two-way street, and we want to provide clear and transparent steps for our policy. As always, our goal is to minimize the impact of vulnerabilities on the general public, which is most effectively achieved through a cooperative approach.

Drawing inspiration from the security policies of Google and Microsoft, we adhere to a 90-day disclosure policy. While it may seem harsh to set deadlines on security fixes, the vulnerability research community has found that some sort of deadline is necessary. Deadlines ensure security vulnerabilities will be addressed in a timely manner, adding an appropriate level of urgency to the remediation process.

Each day that passes without a published fix raises the chance that an unscrupulous entity will independently discover the vulnerability and abuse it. If a vendor delays the release of a security fix for long enough, their customers will ultimately be better off if they were aware of the problem even when a fix isn’t available.

After a vendor publishes a security fix, we will release full technical details about the vulnerability and exploit. This information is useful for raising awareness, helping customers assess the risk of the issue, and also educates developers on how to avoid similar problems in the future.

We recognize that full technical details can sometimes make it easier for adversaries to develop their own exploits. As a result, we typically delay the release of full technical details for a short period of time after a vendor publishes a patch or other fix. It’s common practice for adversaries to reverse engineer security fixes anyways, so only a short publication delay is useful.

Disclosure Process

Immediately after discovery of a vulnerability, we will prepare a report and notify the vendor. Initial attempts at contact will be made through contacts or channels detailed on the vendor website, or alternatively via email to commonly used notification aliases, such as “security@example.com”.
Vendors are expected to acknowledge receipt of the notification. Automated email responses are not considered a valid acknowledgement. Vendors are encouraged to provide an expected time frame for a fix after their initial technical assessment.
If the vendor fails to acknowledge the notification within 7 days, contact will be attempted through telephone. If all reasonable means to contact have been exhausted, we will disclose the vulnerabilities publicly 14 days after the initial contact.
After notification, vendors will have 90 days to prepare and publish a patch, fix, or other work around.
If no patch has been made available by the end of the 90 days, we will publicly disclose the vulnerability on our website so users can take steps to protect themselves.
Once a patch has been made available, we will typically wait 30 days before disclosing any vulnerability details to allow users to implement the security fixes. Circumstances may dictate a shorter delay or partial release of details on a differing schedule, however, if for instance another party has already released vulnerability details or if the vulnerability has already been exploited “in the wild”.