Security disclosure policy

Coordinated vulnerability disclosure for Apex Platform (southlodge.ai). Filed 2026-05-07. RFC 9116 security.txt at /.well-known/security.txt.

How to report

Email security@southlodge.ai. Include:

• A clear description of the vulnerability (one sentence is fine — we'll ask for detail).
• Reproduction steps. A minimal Proof-of-Concept request / payload accelerates triage hugely.
• Expected vs actual behaviour.
• Your assessment of severity (CVSS or descriptive).
• Any PII / customer-data you encountered during the test — we need to log that exposure for our own breach-notification posture.
• Whether you'd like credit (and under what handle) when we publish the fix.

Response SLAs

Scope

In scope:

• The production deployment at https://southlodge.ai and its sub-paths.
• Any Netlify Function under /.netlify/functions/.
• Authentication, authorisation, multi-tenant isolation, audit-chain integrity, RLS, refresh-token rotation, MFA flow, OAuth callback handling.
• Privilege escalation, IDOR, CSRF, SSRF, XSS, SQL/NoSQL injection, deserialization, prototype pollution, mass assignment, race conditions.
• PII / PHI exposure (we operate in healthcare verticals, so HIPAA-class findings are highest priority).
• Crypto misuse, weak password storage, secret leak in client bundles.
• Supply-chain issues in our dependency graph (CVEs we're shipping).

Out of scope:

• Denial-of-service or volumetric attacks (please don't).
• Spam / social-engineering of staff or customers.
• Physical attacks against any office or data centre.
• Findings that require non-default browser configuration (e.g. disabling SameSite at the browser).
• Self-XSS that requires the victim to paste payload into their own console.
• Missing low-risk security headers when no concrete attack scenario exists (e.g. missing X-XSS-Protection in modern browsers that ignore it).
• Reports from automated scanners with no manual reproduction.
• Issues in third-party services we integrate with (Stripe, Resend, Ably, etc.) — please report those to the respective vendors directly.

Safe harbour

If you make a good-faith effort to comply with this policy during your security research, we will:

• Consider your testing as authorised.
• Not pursue or support legal action against you for accidentally breaking things during in-scope testing, or for accessing customer data that was exposed by the bug you're reporting (provided you do not retain, share, or further misuse it).
• Work with you to resolve the issue quickly and to coordinate any public disclosure.

This protection applies only when you:

• Stay in scope.
• Avoid privacy violations (don't retain PII, don't pivot from one customer's data to another's, don't degrade or disrupt the service).
• Give us reasonable time to remediate before any public disclosure.
• Don't violate other laws (no fraud, no spam, no extortion).

Acknowledgements

Researchers who follow this policy are listed on our Hall-of-Fame page under the handle they request. We're not yet running a paid bug-bounty programme — that's gated on customer-revenue milestones tracked in our HUMAN-DECISIONS register §3. We will write a public acknowledgement post for any Critical or High that's responsibly disclosed, with your handle if you want it.

What we won't do

• Sue you for following this policy in good faith.
• Share your name or handle without your consent.
• Forward your report to law enforcement except where legally required (and we will tell you if that happens).
• Sit on a Critical or High beyond the SLA without giving you a written reason.

What we ask you not to do

• Don't degrade, deny, or DoS the service.
• Don't access customer data beyond what's needed to demonstrate the bug.
• Don't post the issue publicly before we've agreed disclosure terms.
• Don't extort or threaten.
• Don't run automated scans that generate large traffic volumes (manual repros are fine).

Versions

v1.0 — 2026-05-07. Filed at public/security/disclosure-policy.html in source. Markdown source at docs/security/disclosure-policy.md in source.