Gretel was founded by veterans of the security community. We are passionate about ensuring that our interactions with security researchers are positive and respectful. We treat each report we receive with the utmost seriousness while we evaluate the potential impact that it could have for our customers across the various products & services we offer.
During this process, Gretel will communicate as promptly as we’re able until completion of our investigation and any necessary remediation. We thank you for your time & expertise to improve the security of our company and customers.
Rules of Engagement
To ensure a great experience with Gretel, we ask that bug reporters follow these simple rules of engagement to limit the potential that company and/or customer data may be at risk:
- Do not exploit identified vulnerabilities in a manner that risks the confidentiality, integrity, and/or availability of any resources not owned by you during testing processes.
- Do not install rootkits, ransomware, viruses or other malware on systems not owned by you.
- Do not use your findings to phish, spam, social engineer, or otherwise attempt to defraud any Gretel users, customers, or employees during the course of testing to gain more access.
- Do not perform denial of services (DoS) or distributed denial of service (DDoS) attacks against any Gretel resource to prove an impact for a suspected security issue.
If you are ever unclear on how far your testing should go, please reach out to Gretel (email@example.com) to coordinate testing with us. We can often validate your suspicions in simple ways that can reduce the chance of harm occurring to our services & customers.
Security Reports We Are Not Interested In
While many of the security reports Gretel receives are of a useful nature, we do want to specify the types of reports that are not useful at this time. This list is not all inclusive, but it may help bug reporters prioritize their research.
- Same-site scripting, self-XSS, or clickjacking
- CSRF that has no clear, practical security impact (e.g. Logout CSRF)
- Security best practice concerns (e.g. weak password policy)
- SSL/TLS best practices (e.g. weak cipher suites)
- Missing HTTP Headers (e.g. lack of HSTS)
- Email security best practices (e.g. DKIM, SPF, DMARC)
- Reconnaissance or fingerprinting information that has no practical use for exploitation
- Attacks that require physical access to the target’s device/operating system
- Social engineering attacks that require users to be convinced to be compromised
- Vulnerabilities related to deprecated and/or unsupported versions of our software
- Static/dynamic code analysis results without verification provided of an actual risk
How to Report Security Issues to Gretel
If you have found a security issue or bug with something in Gretel's open source repositories:
- Please open an issue on the impacted repository
- If the issue or bug is with a third party package that Gretel uses, please open an issue with that package's maintainers in accordance with their policies.
If you have found a security issue or bug in Gretel's services, tools, or infrastructure:
- The best way to report the issue is by emailing us at firstname.lastname@example.org. You are welcome to encrypt communications to us through the use of our GPG key, and we will reciprocate if we deem the contents of further emails to merit encryption.
What You Should Include in Your Report
- The date & time when you initially discovered the issue
- The URL(s) where you found the security issue to be applicable
- All relevant headers & parameters used to demonstrate the risk against the service
- Your operating system and browser, with version number, used for all testing
- A description of the type of issue (e.g. Remote Code Execution, Cross-Site Scripting)
- Your perspective of the impact, criticality of the finding, and any abuse cases
- Sample code (i.e. proof-of-concept) and/or tool used to generate an exploit payload
- The best contact information for the finder of the issue (e.g. email, phone)
- Any information you may have accidentally accessed during testing without permission
How Gretel Will Respond
Gretel will provide an initial acknowledgement of your security report within 48 hours under normal circumstances once our team receives it. We may follow up with additional questions to ensure we fully understand the report and its potential impact. Following our initial acknowledgement, Gretel will try to keep reporters aware of the progress on analysis, verification, and any required remediation steps along the way.
If a reported issue has been validated and depending on system(s) impacted, Gretel may provide a public acknowledgement in relevant release notes, documentation, or blog posts that reference the issue. Gretel does not operate a bug bounty program at this time, but may choose to reward reporters of issues in some cases, at our discretion.
Once a security report has been triaged, Gretel may take additional remediation steps. These remediation steps may extend many weeks or months if the severity is low enough. In these cases, we will let you know that we plan to fix our issue, but will be unable to guarantee a timeline in those cases due to the nature of remediation prioritization.