Responsible Disclosure Policy

Effective Date: May 17, 2021

Requirement to Follow

1. strongDM requires that those submitting vulnerabilities through this Responsible Disclosure Policy:

Requests for Compensation

1. This Responsible Disclosure Program is not a bug bounty program, and strongDM does not provide monetary compensation for reported vulnerabilities.

2. Vulnerability Reporters who request monetary compensation, either before or after submission, will be considered non-compliant with the requirements of this policy, and will not be afforded the protections defined in strongDM's Commitments.

strongDM’s Commitments

1. As long as a vulnerability reporter follows the requirements defined in this policy, strongDM makes the following commitments:

Defining the Scope

Allowed Targets

1. The following targets are considered to be "in-scope" or allowable under the provisions of this Responsible Disclosure Policy:

Prohibited Methods

1. The following methods are prohibited and considered out-of-scope:

Submitting Vulnerabilities

What Should be Submitted

1. Please forward as much of the following to our Security Team as you have available:

What Should Not be Submitted

1. Please do not send any of the following information to us:

How to Send Us a Report

1. strongDM's Security Team keeps a public GitHub repository with instructions and templates for creating vulnerability reports located at

2. Vulnerability Reporters should refer to the GitHub repository for the most up to date methods for securely submitting reports to strongDM

What Comes Next

1. The strongDM Security Team will respond with an acknowledgement of receipt of submitted vulnerabilities within 3 business days

2. The strongDM Security Team will work with internal stakeholders, and the Vulnerability Reporter as needed, to reproduce and verify the submitted vulnerability

3. The strongDM Security Team will work with internal stakeholders to develop a timeline for remediation, accounting for the severity of the vulnerability, availability of exploit code, and internal workloads. The timeline for remediation will be communicated to the Vulnerability Reporter

4. After a reported issue has been remediated, strongDM will follow up with the Vulnerability Reporter to ensure they are aware of the fix, discuss public disclosure of the vulnerability, and discuss details for public recognition on strongDM's website

Remediation Timelines

1. Consistent with strongDM's internal policies on vulnerability remediation, strongDM will strive to resolve all reported vulnerabilities within the following timelines, subject to verification and reproduction of the vulnerability, and strongDM making an independent assessment of the criticality:

Rating Deadline
Critical 14 days
High 30 days
Medium 60 days
Low 90 days


1. Within this document, the following definitions apply:

Availability: Ensuring timely and reliable access to and use of information

Auditability: Ability to independently review or examine the records and activities of a system to assess the adequacy of system controls, and ensure compliance with established policies, and attribute all actions on a system to a unique account or process

Confidentiality: Preserving authorized restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information

Integrity: Guarding against improper information modification or destruction, and includes ensuring information non-repudiation and authenticity

Reporters: Any person who, through this Policy, submits a report of a potential vulnerability to strongDM

Security Team: The employees of strongDM who are responsible for ensuring the confidentiality, integrity, availability, and auditability of all information systems that process, store, or handle strongDM data

System Owners: The person or role that is responsible for implementing and maintaining an information system

Vulnerability: Weakness in an information system, system security procedures, internal controls, or implementation that could be exploited or triggered by a threat source

Revision History

2021-08-19 - Initial Version and Publication