Security

What We Do on Our Side

All traffic to GreenHat is served over TLS; we don’t do mixed content or downgrade to HTTP. Passwords are hashed with a modern algorithm—we never store or log plaintext. Session tokens are HTTP-only and tied to the same origin so script injection can’t steal them. Auth is handled by a provider that supports MFA; we don’t roll our own crypto. Database access is scoped with row-level policies so that, where it makes sense, your data is only readable in the context of your session or defined backend flows.

We patch dependencies, review access logs, and lock down admin actions (e.g. fleet and user management) behind re-auth. Backups exist for recovery; we don’t use production data for training or experiments.

What You Should Do

Use a strong, unique password for GreenHat—not one you reuse on other sites. We’ll never email you asking for your password or a “verification link” that goes to a different domain. If you get something like that, it’s phishing; don’t click. Turn on MFA if your provider offers it. Don’t paste API keys or creds in discussions or chat; if you do by mistake, rotate them and consider reporting the message so we can redact. Basic opsec: treat the account like a security professional would.

If You Find a Vulnerability

Report it to us first. Email security@greenhat.com with a clear description and steps to reproduce. Don’t exploit it beyond what’s needed to show impact; don’t dump data or touch other users’ accounts. We’ll confirm receipt, triage, and fix. We don’t sue researchers who follow responsible disclosure—we’d rather fix the bug. Once it’s patched we’re happy to credit you if you want (e.g. in a short hall-of-fame note), but we don’t run a formal bounty program right now.

If you post the vuln or PoC publicly before we’ve had a chance to fix it, we’ll treat that as a violation of the Code of Conduct and may take action on your account. Give us a reasonable window (e.g. 90 days) before any disclosure.