Grail Atlas — Responsible Disclosure Policy

DRAFT: this policy is in working-draft form pending review by qualified counsel. The content is the Grail Atlas team's best-effort framework; treat it as informational until the watermark is removed.

Last updated: 2026-05-19 (draft)

Our promise

If you find a security vulnerability in Grail Atlas, please tell us. We will:

• Acknowledge your report within 72 hours.
• Provide a remediation timeline within 7 days.
• Keep you updated on progress at a cadence we agree on.
• Credit you publicly (with your consent) once the issue is resolved.
• Not pursue legal action against good-faith research that follows this policy.

Scope

In scope:

• The grailatlas.com web application (Next.js front-end, API routes).
• The Grail Atlas Supabase project (sgzrlnnkuvyypsbvfbwf.supabase.co), but only in ways that don't compromise other users' data.
• The GitHub repository and CI/CD pipeline.

Out of scope:

• Social-engineering attacks against Grail Atlas staff, contractors, or users.
• Denial-of-service testing against production.
• Physical attacks against Grail Atlas property.
• Issues in third-party services (Supabase, Vercel, GitHub) — report directly to them.

Safe-harbor terms

Research that follows this policy is authorized under our terms. Specifically:

• You may probe the application using standard security tools.
• You may create test accounts (but please use realistic, throwaway data — no real PII other than your own).
• You may NOT access, modify, exfiltrate, or destroy data belonging to other users.
• You may NOT publicly disclose the vulnerability until we have agreed on a release date — typically 90 days after report.

What to report

We are particularly interested in:

• Authentication or session-management flaws.
• Authorization / RLS bypass — getting at another user's portfolio, saved searches, owner reports, or seller-dossier data.
• Server-side code injection (SQL, OS command, template).
• SSRF against internal endpoints or cloud metadata.
• Stored XSS in any UGC surface (signals, owner reports, comments).
• Sensitive data exposure (logs, error messages, browser storage).
• Defects in the score-audit-trail integrity (canonical-JSON hash collisions, replayable input forgery).

What's NOT a vulnerability for our purposes

• Missing security headers on legacy paths that don't accept user input.
• Self-XSS or vulnerabilities requiring physical access to a user's device.
• Click-jacking on pages without authenticated actions (we enforce frame-ancestors 'none' regardless).
• Username enumeration via timing — we run constant-time comparisons on every auth path; documented timing differences below 10ms are considered noise.
• Issues that only affect outdated browsers (>2 years old).

How to report

Email security@grailatlas.com. Include:

• A clear description of the vulnerability.
• A proof-of-concept (the smallest one that demonstrates the issue).
• Your assessment of the impact.
• Your name (if you'd like credit) and how to reach you.

If you'd like to use PGP, we'll publish a key once the program graduates out of draft. In the meantime, we accept reports over plain email and follow up over a channel you choose.

Hall of fame

The first ten researchers who report a valid, fixable vulnerability are listed here once the issue is closed (with consent). We don't currently run a paid bounty — we plan to graduate to one after the first 25,000 monthly visitors.

[Counsel to validate safe-harbor wording per jurisdiction.]