Security disclosure policy

Dronedesk appreciates investigative work into security vulnerabilities which is carried out by well-intentioned, ethical security researchers. We're committed to investigating and resolving security issues in our platform and services in collaboration with the security community. This document aims to define a method by which Dronedesk can work with the security research community to improve our online security.

1. Scope

1. This disclosure policy applies only to vulnerabilities in Dronedesk products and services under the following conditions:
   1. Only vulnerabilities which are original and previously unreported and not already discovered by internal procedures are in scope.
   2. Only domains which have a security.txt file in their root are in scope. Subdomains are considered in scope provided their parent domain is in scope.
2. The following security issues are currently not in scope (please don’t report them):
   1. Volumetric vulnerabilities (i.e. simply overwhelming our service with a high volume of requests).
   2. TLS configuration weaknesses (e.g. "weak" ciphersuite support, TLS1.0 support, sweet32 etc.)
   3. Reports of non-exploitable vulnerabilities
   4. Reports indicating that our services don't fully align with "best practice" e.g. missing security headers (CSP, x-frame-options, x-prevent-xss etc) or suboptimal email related configuration (SPF, DMARC etc)
   5. Reports of improper session management / session fixation vulnerabilities.

2. Bug Bounty

1. Due to Dronedesk's funding structure (we're a bootstrap start-up), our paid bug bounty programme is modest. This is approximately how much we will pay for reports:
   1. "not applicable" — Reports about things that we have specifically noted as out of scope.
   2. "informative" — We're aware of this, or we don't really see it as a security issue.
   3. 0GBP — This is a public security issue for another browser or platform.
   4. ~20GBP — While this bug is appropriately categorised as a security issue, it doesn't present much risk and isn't a priority to fix.
   5. ~50GBP — A minor security problem. Someone should probably fix it. It's likely not getting fixed in the next release.
   6. ~100GBP — This is definitely a real problem that puts the Dronedesk service or users' data at risk. We will ship a fix in, or even before, our next scheduled release.
2. If payment is due, it will only be made by card via PayPal or Stripe and on receipt of a headed invoice containing the reporting company's legally registered name, address and contact information.

3. Reporting a vulnerability

1. If you have discovered an issue which you believe is an in-scope security vulnerability, please email security@dronedesk.io including:
   1. The website or page in which the vulnerability exists.
   2. A brief description of the class (e.g. "XSS vulnerability") of the vulnerability. Please avoid including any details which would allow reproduction of the issue at this stage. Detail will be requested subsequently, over encrypted communications.
2. In accordance with industry convention, we ask that reporters provide a benign (i.e. non-destructive) proof of exploitation. This helps to ensure that the report can be triaged quickly and accurately whilst also reducing the likelihood of duplicate reports and/or malicious exploitation for some vulnerability classes (e.g. sub-domain takeovers). Please ensure that you don't send your proof of exploit if the vulnerability is still exploitable. Please also ensure that all proof of exploits are in accordance with our guidance (below), if you are in any doubt, please email security@dronedesk.io for advice.
3. Please read this document fully prior to reporting any vulnerabilities to ensure that you understand the policy and can act in compliance with it.

4. What to expect

1. In response to your initial email to security@dronedesk.io you'll receive an acknowledgement reply email from Dronedesk, this is usually within 24 hours of your report being received. The acknowledgment email will include a ticket reference number which you can quote in any further communications with our Security Team.
2. We will ask you to send the following detail via encrypted email:

   Report Section	Description
   Title	Concise summary categorising the vulnerability, and the site/application where it can be found, e.g. Reflected XSS on the XYZ website
   Asset *	Web address, IP address, product, service name, etc.
   Weakness	Such as a CWE
   Severity *	Such as low, medium, high, critical, and the calculated via CVSS
   Description of the Vulnerability *	A summary of the vulnerability Supporting files (e.g. screenshot or video) Any mitigations or recommendations
   Steps to reproduce *	Clear and descriptive steps to reproduce the vulnerability Proof of concept code if available
   Impact	A clear description of the effects of successfully exploiting the vulnerability
   Contact details	Company name Name * Email address *
   * denotes mandatory information

3. Following the initial contact, our Security Team will work to triage the reported vulnerability and will respond to you as soon as possible to confirm whether further information is required and/or whether the vulnerability qualifies as per the above scope, or is a duplicate report. From this point, necessary remediation work will be assigned to the appropriate teams and/or supplier(s). Priority for bug fixes and/or mitigations will be assigned based on the severity of impact and complexity of exploitation. Vulnerability reports may take some time to triage and/or remediate, you’re welcome to enquire on the status of the process but please limit this to no more than once every 14 days, this helps our Security team focus on the reports as much as possible.
4. Our Security Team will notify you when the reported vulnerability is resolved (or remediation work is scheduled) and may ask you to confirm that the solution covers the vulnerability adequately.

5. Guidance

1. Security researchers must not:
   1. Access unnecessary amounts of data. For example, 2 or 3 records is enough to demonstrate most vulnerabilities (such as an enumeration or direct object reference vulnerability);
   2. Violate the privacy of Dronedesk users, staff, contractors, systems etc. For example by sharing, redistributing and/or not properly securing data retrieved from our systems or services;
   3. Communicate any vulnerabilities or associated details via methods not described in this policy or with anyone other than Dronedesk;
   4. Modify data in our systems/services which is not your own;
   5. Disrupt our service(s) and/or systems; or
   6. Disclose any vulnerabilities in Dronedesk systems/services to 3rd parties/the public prior to Dronedesk confirming that those vulnerabilities have been mitigated or rectified. This does not prevent notification of a vulnerability to 3rd parties to whom the vulnerability is directly relevant, for example where the vulnerability being reported is in a software library or framework – but details of the specific vulnerability of Dronedesk must not be referenced in such reports. If you are unsure about the status of a 3rd party to whom you wish to send notification, please email security@dronedesk.io for clarification.
2. We request that any and all data retrieved during research is securely deleted as soon as it's no longer required and at most, 1 month after the vulnerability is resolved, whichever occurs soonest.
3. If you are unsure at any stage whether the actions you are thinking of taking are acceptable, please contact our security team for guidance (please don't include any sensitive information in the initial communications): security@dronedesk.io.

6. Legalities

1. This policy is designed to be compatible with common good practice among well-intentioned security researchers. It does not give you permission to act in any manner that is inconsistent with the law or cause Dronedesk to be in breach of any of its legal obligations, including but not limited to:
   1. The Computer Misuse Act (1990)
   2. The General Data Protection Regulation 2016/679 (GDPR) and the Data Protection Act 2018
   3. The Copyright, Designs and Patents Act (1988)
2. Dronedesk will not seek prosecution of any security researcher who reports, in good faith and in accordance with this policy, any security vulnerability on an in-scope Dronedesk service.