Vulnerability Disclosure Policy

Last updated: 27 May 2026 Brand Atlas welcomes vulnerability reports from security researchers. This Policy describes the rules of engagement, our safe-harbour commitments, and the response timeline.

​

1. Reporting

Report vulnerabilities to security@brandatlas.pro. PGP encryption is available; the public key is published at brandatlas.pro/.well-known/security.txt per RFC 9116. Useful report content:

• A description of the vulnerability.
• The steps to reproduce.
• The expected impact.
• Any proof-of-concept (without exfiltrating data or persistently affecting other users).
• Your name or handle for credit (optional).

​

2. Scope

In scope:

• The Brand Atlas application at app.brandatlas.pro.
• The marketing site at brandatlas.pro.
• The documentation site at docs.brandatlas.pro.
• The public API.
• The Mintlify-hosted docs site infrastructure (where the vulnerability affects how Brand Atlas’s docs are served).

Out of scope:

• Sub-processor infrastructure (Stripe, Supabase, Vercel, GitHub, AI providers). Report directly to the sub-processor; we can coordinate.
• Customer-controlled content (a brand record that contains material we are not responsible for).
• Social engineering of Brand Atlas personnel.
• Physical attacks against Brand Atlas’s offices.
• Denial-of-service attacks (test at low volume only; volumetric DoS is not a vulnerability).
• Issues in third-party services embedded in customer atlases (Figma, YouTube, etc.).

​

3. Safe-harbour terms

We commit to the following safe-harbour treatment for good-faith security research:

• No legal action. We will not initiate or support legal action against you for security research that:
  • Stays within the scope above.
  • Does not access data beyond what is minimally necessary to demonstrate the vulnerability.
  • Does not exfiltrate, retain, or share customer data.
  • Does not degrade the Service for other customers.
  • Provides reasonable notice and the chance to fix before any public disclosure.
• Coordination on disclosure. We work with you to coordinate the disclosure timeline.
• Credit. We credit researchers in our security acknowledgements (with your permission).

These terms do not authorise actions that would violate applicable law beyond Brand Atlas’s own. If you have any doubt whether a specific test is in-scope, contact us first.

​

4. What we ask of researchers

• Test on your own accounts. Use a dedicated test atlas, not a production one.
• Do not access other customers’ atlases. Beyond minimal proof of concept against an account you control.
• Do not exfiltrate or retain customer data.
• Do not perform tests that degrade the Service for other customers (no high-volume DoS, no operations that lock other customers out).
• Provide reasonable time to fix before any public disclosure. We aim for 90 days; faster for critical issues.

​

5. Response timeline

• Acknowledgement: Within 1 working day of receipt.
• Triage: Within 5 working days, with an initial assessment of severity and reproducibility.
• Fix: Timeline depends on severity:
  • Critical: Hours to days.
  • High: Days to two weeks.
  • Medium: Two to four weeks.
  • Low: Within the next regular release cycle.
• Public disclosure: Coordinated with the researcher, typically 90 days after the fix lands. Earlier if the researcher prefers and the fix is shipped.

​

6. Bounty

Brand Atlas does not currently operate a bug bounty programme. We may introduce one in 2027; details will be published here. In the absence of a formal bounty, we acknowledge meaningful reports with:

• Credit on our security acknowledgements page (with permission).
• Brand Atlas swag for substantive reports.
• A direct thank-you from the founder.

​

7. The security.txt entry

Per RFC 9116, we publish a security.txt at brandatlas.pro/.well-known/security.txt containing:

• Contact email and PGP key.
• This policy URL.
• Expiry date for the entry.
• Preferred language for reports.

The file is the authoritative source. If anything on this page differs from the security.txt entry, the security.txt wins on contact details.

​

8. Researcher recognition

Researchers who report substantive vulnerabilities are listed on our security acknowledgements page (with their permission). We use the handle and credit the researcher requests.

​

9. Coordination with authorities

For vulnerabilities that involve customer data or that may indicate ongoing exploitation, we may need to coordinate with law enforcement or with affected customers. We will communicate with the researcher about any such coordination.

​

10. Changes

We may update this Policy. Material changes are announced via the changelog.

​

What changed

• 27 May 2026: Initial draft published for counsel review of safe-harbour terms.