KeyedIn merged with Sciforma in 2023. Starting 1 Jan 2025, you will be redirected to the Sciforma website to access all the information, resources, and support you need. Visit us now at https://www.sciforma.com/

KeyedIn merged with Sciforma in 2023. Starting 1 Jan 2025, you will be redirected to the Sciforma website to access all the information, resources, and support you need. Visit us now at https://www.sciforma.com/

Vulnerability Disclosure Policy

As with all systems storing, processing and transmitting information there is inherent risk that systems may be susceptible to unknown vulnerabilities that have not been identified by KeyedIn’s own internal security solutions. Security vulnerabilities are discovered all the time and people want to be able to report them directly to the organisation responsible in a safe and secure manner and we encourage everyone to report identified vulnerabilities in the services we provide. The KeyedIn Vulnerability Disclosure Policy looks to address this and demonstrates that our organisation takes security seriously whilst also providing a means for responsible disclosure. This policy applies to any vulnerabilities you are considering reporting to us (KeyedIn Solutions) that you have identified within the websites or cloud solutions that we provide and we recommend reading this vulnerability disclosure policy fully before you report a vulnerability and always acting in compliance with it. We value those who take the time and effort to report security vulnerabilities according to this policy however, we do not offer monetary rewards for vulnerability disclosures.

The policy takes into consideration

  • How to contact KeyedIn
  • Information to include in the report
  • What the finder should expect to happen
  • Guidance on what is in and out of scope for the finder to do in finding vulnerabilities
  • Legal requirements

Reporting

If you believe you have found a security vulnerability, please submit your report to us at Security@KeyedIn.com and in your report please include details of:

  • The website address/URL, IP address or page where the vulnerability can be observed.
  • A brief description of the type of vulnerability, for example, “XSS vulnerability”.
  • Steps to reproduce the vulnerability (These should be a benign, non-destructive, proof of concept.)

Providing this information helps to ensure that the report can be triaged quickly and accurately. It also reduces the likelihood of duplicate reports, or malicious exploitation of some vulnerabilities, such as sub-domain takeovers.

What to expect

After you have submitted your report, we will respond to your report within 5 working days and aim to triage your report within 10 working days. We will also aim to keep you informed of our progress. Priority for remediation is assessed by looking at the impact, severity and exploit complexity. Vulnerability reports might take some time to triage or address. You are welcome to enquire on the status but should avoid doing so more than once every 14 days. This allows our teams to focus on the remediation. We will notify you when the reported vulnerability is remediated, and you may be invited to confirm that the solution covers the vulnerability adequately. Once your vulnerability has been resolved, we welcome requests to disclose your report. We would like to combine guidance to affected users, so please do continue to coordinate public release with us.

Assessing our application for vulnerabilities

As part of the vulnerability assessment conducted, you must NOT:

  • Break any applicable law or regulations.
  • Access unnecessary, excessive or significant amounts of data.
  • Modify data in the Organisations systems or services.
  • Use high-intensity invasive or destructive scanning tools to find vulnerabilities.
  • Attempt or report any form of denial of service e.g., overwhelming a service with a high volume of requests.
  • Disrupt the Organisation's services or systems.
  • Submit reports detailing non-exploitable vulnerabilities, or reports indicating that the services do not fully align with “best practice”, for example missing security headers.
  • Submit reports detailing TLS configuration weaknesses, for example “weak” cipher suite support or the presence of TLS 1.0 support.
  • Communicate any vulnerabilities or associated details other than by means described in this policy.
  • Social engineer, ‘phish’ or physically attack the Organisation's staff or infrastructure.
  • Demand financial compensation in order to disclose any vulnerabilities.

You must:

  • Always comply with data protection rules and must not violate the privacy of the Organisation’s users, staff, contractors, services or systems. You must not, for example, share, redistribute or fail to properly secure data retrieved from the systems or services.
  • Securely delete all data retrieved during your research as soon as it is no longer required or within 1 month of the vulnerability being resolved, whichever occurs first (or as otherwise required by data protection law).

Legal Requirements

This policy is designed to be compatible with common vulnerability disclosure good practice. It does not give you permission to act in any manner that is inconsistent with the law, or which might cause the Organisation or partner organisations to be in breach of any legal obligations.