Security & Responsible Disclosure

Strength & Solidarity LLC ("the LLC") takes the security of BellusTowne and its Citizens seriously. This page describes our current security posture, how we handle vulnerability reports, and how researchers can contact us responsibly.

1. Security posture

• Row-Level Security (RLS): All database tables in the public schema enforce RLS policies. No unauthenticated query may access another Citizen's data.
• Multi-Factor Authentication (MFA): TOTP-based second seals (authenticator apps) are available to all Citizens and required for privileged roles (Founder, Constables, Thanes).
• Recovery codes: Hardware-seal recovery codes are generated server-side and shown once. They are hashed before storage.
• Security-definer functions: Sensitive operations (role checks, balance queries, audit writes) useSECURITY DEFINER functions to prevent privilege escalation through RLS recursion.
• Append-only audit ledgers: Critical tables (standing ledger, IP registry, market transactions) are append-only by database trigger and may not be altered or deleted by any application user.
• Anomaly detection: Automated sweeps flag duplicate avatars, impersonation attempts, unusual standing transfers, and mass-download patterns.
• Scoped secrets: Service-role credentials and webhook secrets are server-only and never bundled into client code.
• Webhook verification: All incoming webhooks (Stripe, etc.) are verified by HMAC signature before processing.
• Avatar allowlist: Uploaded portraits are validated against a strict allowlist of extensions, size limits, and MIME types before storage.
• Mandatory second seals for privileged roles: Founder, Constables, and Thanes must enrol a second seal (TOTP or hardware) before privileged actions will be honoured. The requirement is enforced server-side, not merely encouraged in the interface.
• Transport and header hardening: The site scores A+ on both independent TLS and HTTP security-header assessments, with HSTS, a content-security policy, and strict referrer and frame controls in force.
• Error telemetry: Client and server faults are recorded to a Founder-only ledger so that failures are observed rather than merely reported.
• Scheduled dependency review: Third-party packages are scanned on a recurring cadence and each sweep is recorded with its date and findings.

2. Incident response & breach notification

Our incident-response and breach-notification policy is live and binding. It sets a severity ladder with committed acknowledgement and containment times, and it commits us to notifying affected Citizens within 72 hours of confirming a breach of personal data — worldwide, as a matter of policy rather than only where law compels it.

Read the Incident Response & Breach Notification policy →

3. What we do not yet offer

We are transparent about the defenses we have not yet built so that researchers do not waste effort on known gaps:

• We do not currently operate a formal bug-bounty programme or paid vulnerability-reward scheme.
• Per-IP rate limiting on server functions is not yet deployed; we rely on infrastructure-level protections.
• We have not yet commissioned an independent third-party penetration test or SOC 2 examination.
• Second seals are mandatory for privileged roles but remain optional for ordinary Citizens; we encourage but do not compel them.
• Fault telemetry is kept in-house in our own ledger rather than with a third-party error-monitoring vendor; retention and detail are therefore narrower than a commercial service would provide.
• Dependency review runs on a recorded monthly cadence rather than on every commit; critical advisories are patched out of cadence when they arise.

4. Responsible disclosure

If you discover a security vulnerability in BellusTowne, we ask that you disclose it to us responsibly:

1. Do not exploit the vulnerability beyond what is necessary to confirm its existence.
2. Do not access, modify, or delete other Citizens' data.
3. Do not attack our infrastructure with brute force, denial-of-service, or social-engineering techniques.
4. Give us reasonable time to investigate and remediate before publishing any findings. We consider 90 days from first contact to be reasonable, and we will keep you informed of our progress.

5. How to report

Send reports to security@bellustowne.com. Please include:

• A clear description of the vulnerability and its impact.
• Steps to reproduce, with minimal test cases if possible.
• The affected components (URL, endpoint, table, etc.).
• Your contact information and whether you wish to be credited.

We will acknowledge receipt within 72 hours and aim to provide a substantive update within 14 days. Every published channel and its committed response time is listed on our Contact & Response Commitments page.

6. Safe harbour

We will not pursue legal action against researchers who:

• Follow the responsible-disclosure guidelines above.
• Make a good-faith effort to avoid privacy violations and service disruption.
• Do not publicly disclose the vulnerability before we have had a reasonable opportunity to fix it.

This safe-harbour pledge does not extend to acts that are criminal under applicable law, nor to researchers who deliberately cause harm, exfiltrate data, or extort the Towne.

7. Recognition

With your permission, we will publish a thank-you note in the Towne Crier or on this page crediting researchers who have helped us improve our defences. We do not offer cash bounties at this time.

8. Changes

This disclosure policy may be updated as our security posture evolves. Material changes will be posted here with an updated "Last reviewed" date.

9. Contact

Strength & Solidarity LLC — security@bellustowne.com