Vulnerability disclosure policy
How to report a vulnerability or a bypass in Moatgator, what is in scope, our promise not to pursue good-faith research and our response and fix timelines.
Last updated:
Draft under legal review. This text is not binding yet and may change.
This is a courtesy translation; the Portuguese version prevails.
Our customers' security depends on Moatgator being hard to break. If you found a vulnerability in the platform or a way to bypass the protection, we want to know, and we promise to treat you as a partner. This policy applies to GZ Segurança e Defesa Cibernética LTDA ("Moatgator"), CNPJ 40.988.106/0001-60, Brazil.
How to report
Use the contact form and start the message with [SECURITY]. Describe the issue, where it is and its impact in a few lines. We reply by e-mail and agree with you on a channel to send the details, the proof of concept and attachments.
A good report includes:
- the affected component (URL, SDK version, OS and device);
- steps to reproduce, and the expected and actual result;
- the impact you see (what an attacker could achieve);
- whether anyone's data was accessed (and which), so we can act.
We accept reports in English and Portuguese. Do not ask for or send third-party data you came across: describe the kind of data and stop.
Scope
In scope:
- moatgator.com, app.moatgator.com (console), api.moatgator.com (API), github-app.moatgator.com and the documentation;
- Moatgator SDKs (Android, iOS, React Native, Flutter, Capacitor and Kotlin Multiplatform), the CLI, the GitHub Action and the GitHub App;
- protection bypass: disabling, fooling or getting around a detection (root, jailbreak, Frida, debugger, emulator, tampering, Attest) in a test app of yours, built with our SDK or protected by our platform, on a device of yours;
- flaws that let you see or change another organization's data, escalate privileges, forge events or verdicts, or bypass billing.
Out of scope:
- our customers' apps: report to the app's developer (we can help route it);
- third-party services we use (Railway, GitHub, Stripe, Resend and others): report to them;
- denial of service, load testing, spam and social engineering of our team or customers;
- automated tool output without proof of impact;
- missing headers or settings without demonstrated impact (for example, SPF/DMARC, clickjacking on pages without sensitive actions);
- self-XSS and issues that only occur in unsupported browsers;
- rate limits on routes without sensitive effect.
Good-faith rules
To be covered by this policy, you:
- use only your own accounts and organizations (create as many as you need on the free plan) and your own apps;
- do not access, copy, change or delete other people's data beyond the minimum needed to prove the issue, and stop as soon as you notice such access;
- do not degrade the service (at most 10 requests per second, no aggressive scanning);
- do not keep access or install anything persistent;
- do not disclose the issue before we agree (see "Disclosure");
- comply with the law and this policy.
Safe harbor
If you act in good faith and follow this policy:
- we consider your research authorized and will not take legal action or file a complaint against you for it, including under art. 154-A of the Brazilian Penal Code (Law 12,737/2012) or the software and copyright laws (Laws 9,609/1998 and 9,610/1998) for reverse engineering our SDKs;
- we do not consider acts needed for the research a breach of the Terms of Service or the Acceptable Use Policy;
- if a third party takes action against you for acts covered by this policy, we will make it known that you acted with our authorization.
We cannot authorize testing of third-party systems, including our customers' apps. If you are unsure whether something is in scope, ask first through the form.
Timelines
| Step | Timeline |
|---|---|
| Acknowledgment | within 3 business days |
| First assessment (accepted, needs more data or out of scope) | within 10 business days |
| Fix for critical severity, including a critical protection bypass | target of 7 calendar days |
| Fix for high severity | target of 30 days |
| Fix for medium severity | target of 90 days |
| Low severity | in the next feasible release |
We rate severity by real impact (CVSS as a reference) and update you at least every 14 days until the fix.
Disclosure
We ask for up to 90 days from the report to fix before anything is published. Once the fix is available, we agree with you on the date and the text. If the issue affects customers, we tell customers first. With your permission, we credit you by the name or handle you choose.
Rewards
We do not have a cash reward program yet. We plan a private bug bounty program, and people who report relevant issues under this policy will be invited first.
Updates
We may update this policy. The version that applies to a report is the one in force on the date it was sent. The security.txt file points to this page. This is a courtesy translation: the Portuguese version prevails.