Security and vulnerability disclosure

1. How we protect data

• All traffic is encrypted in transit (HTTPS/TLS; WSS for live positions).
• Each account's saved data is isolated by row-level security in the database; the public website's database role cannot read account data at all.
• Administrative access requires multi-factor authentication, and every administrative change is logged in an append-only audit trail.
• Payments are handled by Stripe; we never see or store full card numbers.
• Dependencies are kept current and scanned, secrets are scanned in our code repository, and changes go through review and automated checks before release.

2. Reporting a vulnerability

Email security@theschoellergroup.com with a description, the steps to reproduce it and the impact. Please don't include other people's personal data. Our security.txt lists the same contact.

We aim to acknowledge reports within 3 business days and to keep you updated until the issue is resolved.

3. Rules for research

• Only test against your own account and data. Don't access, change or delete other people's data; if you reach any, stop and report it.
• Don't run denial-of-service tests, automated scanning that degrades the service, social engineering, phishing or physical attacks.
• Give us reasonable time to fix an issue before disclosing it publicly.
• Don't use a vulnerability for any purpose other than demonstrating it to us.

4. Safe harbour

If you follow these rules in good faith, we will not pursue legal action against you for your research and will treat it as authorised under our Terms. We don't currently run a paid bug bounty.

5. Out of scope

• Reports from automated scanners without a demonstrated impact.
• Missing security headers or best-practice configuration without a concrete exploit.
• Rate limiting, spam or brute-force reports without a bypass of an existing control.
• Vulnerabilities in third-party services we use (report those to the vendor).