Security Innovation Vulnerability Disclosure Policy

Security Innovation is streamlining our process for receiving vulnerability reports that pertain to our products and website. We want to make the process of submitting an issue to us responsibly as easy as possible.

As a team of security researchers who actively participate in the security community and uphold a commitment to responsible disclosure and security education, we recognize the importance of responsible disclosure and value the work the security community does to uphold the safety and security for consumers everywhere.

Scope

Security Innovation’s Vulnerability Disclosure Program initially covers the following products:

Any 3rd parties are governed by the security guidelines of those organizations, which include but are not limited to:

    • Security Innovation hosting providers such as Amazon Web Services
    • Security Innovation’s Learning Management System
    • SCORM Cloud
    • HubSpot

Security Innovation’s Vulnerability Disclosure Program does not include:

  • CMD+CTRL Courseware
    • Our courseware follows the SCORM file format and as such vulnerabilities should be submitted to the respective hosting platform
  • GitHub
    • Security Innovation hosts a number of open source tools on GitHub, these are out of scope unless explicitly included in scope above.

Legal

Security Innovation will not seek legal action against individuals who submit vulnerability reports through our Vulnerability Disclosure Program. We openly accept reports for the currently listed Security Innovation products. We agree not to pursue legal action against individuals who:

  • Engage in testing of systems/research without harming Security Innovation, its partners, its vendors, or its customers
  • Engage in vulnerability testing within the scope of our vulnerability disclosure program and avoid testing against vendor or partner products or services
  • Do not modify or access data that does not belong to you.
  • Adhere to the laws of their location and the location of Security Innovation
  • Refrain from disclosing vulnerability details to the public before a mutually agreed-upon timeframe expires

How to Submit a Vulnerability

While we are happy to receive vulnerability information in any form, we appreciate discrete submission via email to Security Innovation’s Product Security Team at security@securityinnovation.com with the following details:

  1. What type of issue are you reporting? Does it align to the scoped issue?
  2. How does a user reproduce your issue?
  3. What is the impact of your issue?
  4. What are some scenarios where an attacker would be able to leverage this vulnerability?
  5. What would be your suggested fix?

You may also submit sensitive files, proof of concept code, or other artifacts to the Box uploader besides using the our security@securityinnovation.com mailing list.

Please provide your name, contact information, and company name (if applicable) with each report. Vulnerability details may also be submitted via our web interface which is available below.

Preference, Prioritization, and Acceptance Criteria

We will use the following criteria to prioritize and triage submissions:

  • Reports that include proof-of-concept code equip us to better triage
  • Reports that include only crash dumps or other automated tool output may receive lower priority
  • Reports that include products not on the initial scope list may receive lower priority
  • Please include how you found the bug, the impact, and any potential remediation
  • Please include any plans or intentions for any other disclosure

What you can expect from us:

  • A timely response to your email (within 2 business days)
  • After triage, we will send an expected timeline, and commit to being as transparent as possible about the remediation timeline as well as on issues or challenges that may extend it
  • An open dialog to discuss issues
  • Notification when the vulnerability analysis has completed each stage of our review

Excluded Issues:

  • Findings from applications or systems not listed in the above “In-Scope Targets” section.
  • Network level Denial of Service (DoS/DDoS) vulnerabilities.
  • Findings from physical testing such as office access (e.g. open doors, tailgating).
  • Findings derived primarily from social engineering (e.g. phishing, vishing, smishing).
  • HTTP 404 codes/pages or other HTTP non-200 codes/pages.
  • Disclosure of known public files or directories, (e.g. robots.txt).
  • CSRF on forms that are available to anonymous users (i.e. a contact us form).
  • Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.
  • Lack of Secure and HTTPOnly cookie flags on cookies which are not associated with login sessions.
  • Anything related to SPF
  • Clickjacking/UI redressing with no practical security impact
  • SSL/TLS best practices

Restrictions on Disclosure

Security Innovation would request that you do not publicly disclose a vulnerability:

  1. Until it is fixed OR
  2. Following a mutually agreed-upon (or negotiated) timeline, which may be adjusted as part of the process with the disclosing party

This document Version 1.0 was created as of May 2019. [We update or renew this policy every 90 days.] Any updates will be noted below in the version notes.