Gavel Suite handles private membership data, financial records, and (where opted in) ritual content for fraternal organizations. Security and trust are the product.

Do not file public GitHub issues for security problems.

Email: security@gavel-suite.com (interim: stevenfackley@gmail.com until the domain is live) PGP: published on the project website once available.

Please include:

• A description of the vulnerability and the affected component(s).
• Steps to reproduce, or a proof-of-concept.
• Your assessment of the impact.
• Whether the issue is publicly known (e.g., a CVE in a dependency).

You will receive an acknowledgement within 2 business days. We aim to provide an initial assessment within 7 days and remediation within 30 days for high-severity issues, 90 days for medium and below.

In scope:

• Any component in this repository.
• The hosted production environment at the production domain (once live).
• Mobile-installed PWA behavior.

Out of scope:

• Social engineering of staff or lodge members.
• Physical attacks on infrastructure.
• DoS / DDoS demonstrations against production.
• Third-party services (Stripe, Supabase, Cloudflare, etc.) — please report those upstream.
• Vulnerabilities requiring physical access to a member's unlocked device.

We follow coordinated disclosure. Once a fix is deployed and tenants have had a reasonable window to update (when self-hosted enterprise tenants exist), we will publicly acknowledge the reporter — unless anonymity is requested.

We use a simplified scale aligned with CVSS:

• Critical: Tenant isolation breach, ritual content egress to a non-local LLM, payment-processing manipulation, full account takeover.
• High: PII disclosure across roles within a tenant, privilege escalation, authentication bypass.
• Medium: Sensitive metadata leakage, denial of single-tenant functionality.
• Low: Information disclosure of non-sensitive metadata, missing security headers without exploitable impact.

These are the security invariants we test continuously. A break here is automatically critical:

1. Tenant data isolation. No request authenticated for tenant A may read or write data of tenant B. Enforced at the API and at the database (Postgres RLS).
2. Ritual egress prevention. Documents marked is_ritual_content = true, and any embedding, chunk, retrieval result, or generated answer derived from them, must never appear in a request payload destined for a cloud LLM provider.
3. Audit log integrity. The audit log is append-only and hash-chained. Any break in the chain is alerted within 5 minutes.
4. Payment authorization. Only the Treasurer (or an explicitly granted role) may issue refunds, void invoices, or change payment-processor configuration.

During the POC phase, the launch lodge is notified of all confirmed critical or high-severity issues at the same time a patch is deployed, along with an explanation in non-technical language and a description of any exposure (which records, what time window).

There is no formal bug-bounty program yet. Researchers who help us in good faith will be recognized and, at the project's discretion, may receive a token of appreciation. We will publish a formal program before exiting POC.