DRAFT — NOT LEGAL ADVICE. Template only; have a lawyer review before publishing.

Responsible Disclosure Policy (DRAFT)

Last updated: [DATE]

Solacess is a security product. We hold ourselves to the same standard we test our customers' applications against: Solacess must pass its own scan with zero critical or high findings before launch. If you find a security issue in Solacess itself, or a security issue that surfaced *through* using Solacess against your own authorized target, here's how to report it.

1. Scope

This policy covers:

• Security vulnerabilities in Solacess's own product (the web app, the scan engine/worker, or

our infrastructure) — e.g. an auth bypass on our own dashboard, an RLS gap in our own Supabase project, a way to trigger a scan against a domain that hasn't passed ownership verification.

• How we expect you to handle a vulnerability a Solacess scan reveals in your own target

application (short version: that's between you and your fix — a scan report is delivered privately to you).

This policy does not cover vulnerabilities in third-party applications you discover using Solacess, unless that application is your own authorized scan target. See Acceptable Use Policy Section 1 for what you may and may not scan.

2. How to report a vulnerability in Solacess

Email [SECURITY CONTACT EMAIL — placeholder] with:

• A description of the issue and its potential impact.
• Steps to reproduce (proof-of-concept preferred over a general description).
• Whether you've disclosed this anywhere else.

See also security.txt, which publishes this contact in the standard machine-readable format security researchers and tools look for.

3. What we ask of you

• Give us a reasonable time to investigate and fix the issue before any public disclosure.

We ask for 90 days from your report before public disclosure, or less once a fix has shipped and we have agreed a date with you.

• Do not access, modify, or delete data beyond what's needed to demonstrate the issue.
• Do not run automated scanners or load-testing tools against our production infrastructure

without contacting us first (ironic as that sounds for a security-scanner company — but the same "one client, rate-limited" safety principle we apply to our own scans applies to testing us).

• Do not test against real customer accounts or data; use a test account of your own if

possible, or ask us to provision one.

4. What you can expect from us

• Acknowledgment of your report within 2 business days.
• An honest assessment of severity and a rough timeline for a fix.
• Credit in a changelog or security acknowledgments page, if you'd like it. Solacess does not run a paid bug-bounty program.

5. Safe harbor

[PLACEHOLDER — a lawyer-drafted safe-harbor clause belongs here, stating that good-faith security research conducted under this policy will not be referred for legal action. This is standard in responsible-disclosure policies (see Paddle's own, linked below, as one example of the genre) but the exact wording needs legal review, since a badly worded safe harbor can create unintended liability.]

Reference for genre/structure (not copied, for orientation only): Paddle Vulnerability Disclosure Policy.