LegalVulnerability Disclosure Policy
Vulnerability Disclosure Policy
1. Scope
1.1 In scope
First-party properties we operate that are associated with beingoptimal.org, including:
| Surface | Examples |
|---|---|
| Primary site and app | https://beingoptimal.org, https://beingoptimal.org, and the signed-in planner |
| Help | https://help.beingoptimal.org |
| Community | https://community.beingoptimal.org |
| Static assets | https://assets.beingoptimal.org |
| First-party APIs | Same-origin /api/* and related backends we control |
If you are unsure whether a target is in scope, email [email protected] before testing.
1.2 Out Of Scope
| Out of scope | Guidance |
|---|---|
| Third-party providers | Authentication, database, hosting, CDN or edge, cloud infrastructure, email delivery, AI model, community platform, reverse-geocoding, billing, and other providers named in the Sub-processor List. Report vulnerabilities to those providers under their programs. |
| Physical attacks | Data-center or office physical intrusion |
| Social engineering | Phishing or social engineering of staff or users |
| Third-party sites | Unrelated websites that link to or from Optimal |
| Denial of service | Volumetric DoS or DDoS testing against production |
| Non-security bugs | Product defects without security impact (use [email protected]) |
2. Safe Harbor
If you make a good-faith effort to comply with this Policy during your research, Nativity Ltd will:
- Consider your research authorized under applicable computer-misuse laws to the extent we can grant such authorization;
- Not pursue civil legal action against you, or support criminal prosecution, related to that research;
- Work with you in good faith if others misconstrue your actions.
Safe harbor applies only to research on in-scope Optimal systems. It does not bind third parties, including sub-processors or other users.
Safe harbor does not cover accessing other users' data, data exfiltration, extortion, public zero-day dumps, or intentional damage. If in doubt, ask at [email protected] before testing.
3. Rules Of Engagement
You must:
- Use your own test accounts. Do not access, modify, exfiltrate, or store Personal Data (especially health data) that is not yours.
- Stop and report immediately if you encounter another person's Personal Data.
- Avoid harm: no denial of service, spam, resource exhaustion, ransomware, or destructive testing.
- Avoid high-volume automated scanning that degrades service.
- Not pivot into third-party systems, other tenants' data, or provider control planes.
- Not attempt to socially engineer staff or users.
- Give us reasonable time to remediate before any public disclosure (see Section 5).
- Not demand payment under threat of disclosure. Extortion voids safe harbor.
You must not publicly publish exploit code or zero-day details before we have had a fair chance to remediate, and you must not sell or transfer vulnerability details to third parties other than us, except as required by law or a mutually agreed coordinated-disclosure channel.
4. How To Report
Email [email protected] with:
| Field | Content |
|---|---|
| Summary | Clear title and impact assessment |
| Steps to reproduce | Minimal proof of concept, not a weaponized exploit pack |
| Affected URLs or endpoints | Host, path, method, timestamps (UTC) |
| Account used | Test account identifiers only |
| Suggested fix | Optional |
| Contact | How we can reach you for follow-up |
If we publish a PGP key via security.txt, you may use it for sensitive reports. Email is accepted either way.
Do not file security reports through public community forums or social media.
5. Coordinated Disclosure
| Stage | Our aim |
|---|---|
| Acknowledgment | Prompt confirmation of receipt |
| Triage | Initial severity assessment and next steps |
| Remediation | Risk-prioritized fix on a reasonable timeline |
| Disclosure | Coordinated public disclosure by mutual agreement, typically about 90 days from the report, extendable for complex issues |
We ask that you keep the report confidential until we agree it is safe to disclose, that you not publish zero-day details, credentials, or Personal Data, and that you allow time for users to update if a client-side fix is required.
If we fail to respond after repeated good-faith contact, you may escalate via [email protected] before any public statement.
6. Recognition & Rewards
Optimal does not operate a paid bug-bounty program by default. We may thank researchers privately, offer public acknowledgment with your permission, or announce a separate bounty program later with its own terms. No reward is guaranteed.
7. Findings Not Typically Actionable
We generally will not treat the following as security bugs:
- Missing "best practice" headers without demonstrated impact;
- Rate-limit or spam reports without a concrete vulnerability;
- Self-XSS or clickjacking on non-sensitive public pages without impact;
- Theoretical issues without a working demonstration;
- Reports based solely on automated scanner output without validation;
- Vulnerabilities in out-of-scope third-party products.
8. Published Information
Machine-readable contact information is published at:
https://beingoptimal.org/.well-known/security.txt
This Policy remains the human-readable source of process and safe-harbor terms.
See also: Security and Compliance, Privacy Policy, Contact and Legal Notices, and Sub-processor List.