Responsible Disclosure Policy | Gradio Safety LTD

// table of contents

1.  Introduction and philosophy2.  In-scope targets3.  Out-of-scope targets4.  Reporting a vulnerability5.  Rules of engagement6.  What not to do7.  Safe harbour8.  Severity rating and prioritisation9.  Response timeline and process10. Recognition and rewards11. Hall of Thanks12. Coordinated disclosure13. Policy review and version history14. Contact us

1. Introduction and philosophy

Gradio Safety LTD is a security-focused consulting company. We believe that working with the security research community makes our systems stronger. If you find a vulnerability, we want to know about it so we can fix it before it can be exploited.

We are committed to:

Acknowledging every legitimate report within 48 hours
Providing regular updates on remediation progress
Fixing confirmed vulnerabilities as quickly as possible
Recognising and crediting researchers who follow this policy
Not taking legal action against researchers who act in good faith and within this policy

// quick summary
→ Report to: info@gradiosafetyltd.com
→ PGP key: available on request
→ Response time: 48 hours (acknowledgement) · 14 days (initial assessment)
→ Safe harbour: yes, if you follow the rules
→ Rewards: recognition + optional public credit (no monetary bounty at this time)

2. In-scope targets

The following targets are in scope for responsible disclosure:

Target	URL / identifier	Notes
Main website	gradiosafetyltd.com (and all subdomains)	Next.js application hosted on Vercel
API endpoints	api.gradiosafetyltd.com (if applicable)	REST/GraphQL APIs exposed by our application
Authentication systems	Login, registration, password reset, MFA flows	Google Workspace SSO integration
Payment integration	Payment checkout flows on our domain	Only our integration layer — not third-party payment infrastructure itself
Client portals (if any)	Any authenticated area of our website	Test accounts available on request

3. Out-of-scope targets

The following are explicitly out of scope. Reports about these targets will not be accepted:

Target	Why it is out of scope	Where to report instead
Third-party payment gateways	Operated by third-party payment providers — report to their respective security programmes	Respective provider security portals
Vercel infrastructure	Our hosting provider — report to Vercel security	vercel.com/security
Cloudflare infrastructure	Our CDN/DNS provider — report to Cloudflare	cloudflare.com/disclosure
Google Workspace	Operated by Google — report to Google VRP	bughunters.google.com
GitHub	Operated by GitHub — report to GitHub Security	bounty.github.com
Notion	Operated by Notion — report to Notion security	notion.so/security
Third-party SaaS used internally	Report directly to the respective vendor	See vendor security pages

If you are unsure whether a target is in scope, contact us before testing.

4. Reporting a vulnerability

To report a vulnerability, send an email to info@gradiosafetyltd.com with the subject line "Responsible Disclosure — [brief description]".

4.1 What to include in your report

Description: A clear description of the vulnerability and its potential impact
Affected target: The specific URL, endpoint, or component affected
Steps to reproduce: Detailed, step-by-step instructions that allow us to reproduce the issue
Proof of concept: A minimal PoC (screenshots, HTTP requests, scripts) that demonstrates the vulnerability
Impact assessment: What an attacker could do if they exploited this vulnerability
Suggested fix: If you have a recommendation for how to fix it (optional but appreciated)
Your details: Name or handle for recognition (optional — anonymous reports are accepted)
PGP key: Your PGP public key if you want encrypted communication (optional)

4.2 Report format

// recommended report template
Subject: Responsible Disclosure — [brief description]

1. Vulnerability title: [short title]
2. Affected target: [URL / endpoint]
3. Severity: [Critical / High / Medium / Low — see Section 8]
4. Description: [what the vulnerability is]
5. Steps to reproduce: [numbered steps]
6. Proof of concept: [screenshots / HTTP requests / code]
7. Impact: [what an attacker could do]
8. Suggested remediation: [optional]
9. Researcher: [name/handle or "anonymous"]

5. Rules of engagement

To be eligible for safe harbour protection and recognition, researchers must follow these rules:

Authorisation: Only test systems that are explicitly in scope (see Section 2)
No data access: Do not access, modify, or delete data that does not belong to you. If you accidentally access data, stop immediately and report it
No data exfiltration: Do not download, copy, or transfer any data from our systems
No persistence: Do not install backdoors, persistent access, or malware on our systems
No degradation: Do not perform attacks that could degrade service availability (DDoS, resource exhaustion, denial of service)
No automated scanning: Do not run automated vulnerability scanners at high volume — they create noise and can disrupt service. If you use automated tools, rate-limit them
No social engineering: Do not target our employees, clients, or partners with phishing, pretexting, or other social engineering attacks
No physical testing: Do not attempt physical access to our offices, devices, or infrastructure
Privacy: Respect the privacy of our users and clients. Do not access personal data
Good faith: Act in good faith to improve security, not to cause harm

6. What not to do

The following actions are strictly prohibited and will result in loss of safe harbour protection and may lead to legal action:

Prohibited action	Why	Consequence
Public disclosure before fix	Puts users at risk; gives attackers a head start	Loss of safe harbour + legal action
Accessing or exfiltrating user data	Violates privacy and data protection law	Loss of safe harbour + legal action + report to ICO
DDoS or availability attacks	Disrupts service for all users	Loss of safe harbour + legal action
Social engineering our staff	Not in scope; targets individuals, not systems	Loss of safe harbour + legal action
Installing malware or backdoors	Criminal offence under the Computer Misuse Act 1990	Loss of safe harbour + criminal report
Selling or trading vulnerabilities	Contrary to the spirit of responsible disclosure	Loss of safe harbour + permanent ban
Testing out-of-scope targets	Targets third parties who have their own policies	Report rejected; no safe harbour

7. Safe harbour

Gradio Safety LTD provides safe harbour to researchers who comply with this policy. Specifically:

If you discover and report a vulnerability in good faith and in compliance with this policy, we will not initiate legal action against you
We will not report you to law enforcement or regulatory authorities for good-faith security research that complies with this policy
We will treat your report as confidential and will not share your identity without your consent
This safe harbour applies to research conducted on in-scope targets only
This safe harbour does NOT apply if you violate the rules of engagement (Section 5) or prohibited actions (Section 6)

// safe harbour conditions
→ You must comply with ALL rules of engagement (Section 5)
→ You must NOT engage in any prohibited actions (Section 6)
→ You must report the vulnerability to us first, not publicly
→ You must not demand payment or threaten public disclosure
→ This policy is not a bug bounty programme — no monetary reward is guaranteed

8. Severity rating and prioritisation

We use the following severity scale to assess and prioritise vulnerability reports. This is based on the CVSS v3.1 framework and adapted for our context:

Severity	CVSS range	Description	Examples	Target fix time
Critical	9.0 – 10.0	Remote code execution, full system compromise, mass data exposure	RCE on server, SQL injection dumping user database, auth bypass	24 hours
High	7.0 – 8.9	Significant data exposure, privilege escalation, persistent XSS	Stored XSS on admin pages, IDOR exposing client data, SSRF	72 hours
Medium	4.0 – 6.9	Limited data exposure, reflected XSS, CSRF on sensitive actions	Reflected XSS, CSRF on settings change, information disclosure	7 days
Low	0.1 – 3.9	Minor issues, best-practice gaps, theoretical vulnerabilities	Missing security headers, verbose error messages, open redirect	30 days
Informational	N/A	Not a vulnerability — hardening suggestions, observations	Suggested CSP improvements, HSTS preload recommendation	Best effort

Severity is assessed by Gradio Safety LTD based on impact, exploitability, and affected data. We may adjust the severity rating in consultation with the researcher.

9. Response timeline and process

Stage	Timeline	What happens
1. Acknowledgement	Within 48 hours	We acknowledge receipt of your report and assign a tracking ID
2. Triage	Within 5 business days	We assess the report, determine severity, and confirm or reject the vulnerability
3. Investigation	Within 14 business days	We reproduce the issue, investigate root cause, and develop a fix
4. Fix and deploy	Per severity (see Section 8)	We deploy the fix to production and verify it resolves the vulnerability
5. Confirmation	Within 5 business days of fix	We notify you that the fix is deployed and ask you to verify
6. Closure	After your verification	We close the report and coordinate public disclosure (if requested)
7. Recognition	After closure	We add you to the Hall of Thanks (if requested) and issue any agreed recognition

// communication commitment
→ We will keep you updated at every stage of the process
→ If we need more time to fix, we will tell you why and give a new ETA
→ If your report is rejected, we will explain why
→ You can ask for status updates at any time by replying to the tracking thread

10. Recognition and rewards

Gradio Safety LTD does not currently operate a monetary bug bounty programme. However, we recognise researchers who help us improve security through:

Severity	Recognition
Critical	Hall of Thanks + public credit (if desired) + written letter of appreciation + optional reference
High	Hall of Thanks + public credit (if desired) + written letter of appreciation
Medium	Hall of Thanks + public credit (if desired)
Low	Hall of Thanks (if desired)
Informational	Acknowledgement email

We may also provide:

A written testimonial or reference for your portfolio (on request)
A mention in our blog or insights section (with your permission)
Swag (if available — stickers, t-shirts)
Early notification of future security initiatives and programmes

If you would prefer to remain anonymous, we respect that. Anonymous researchers are still eligible for the Hall of Thanks under a pseudonym.

11. Hall of Thanks

We maintain a Hall of Thanks to recognise researchers who have helped us improve security. Researchers are listed by their chosen name or handle.

// hall of thanks
→ No reports yet — be the first!
→ To be listed, include your preferred name or handle in your report
→ You can request to be removed from the Hall of Thanks at any time

12. Coordinated disclosure

We believe in coordinated disclosure. After a vulnerability is fixed, we support public disclosure so the community can learn from it. Our coordinated disclosure process:

Embargo period: We request a 90-day embargo from the date of your report before public disclosure. This gives us time to fix and deploy the patch
Extension: If we need more time, we will request an extension and explain why. We will not unreasonably withhold agreement to disclose
Joint disclosure: We are happy to co-author a disclosure blog post with you, if you are interested
Credit: You will be credited in any public disclosure unless you prefer to remain anonymous
Pre-publication review: We ask to review the disclosure text before publication to ensure no sensitive details are included that could enable new attacks
No zero-day: We do not accept zero-day disclosures (public disclosure without prior private report). Zero-day disclosures are not eligible for safe harbour or recognition

13. Policy review and version history

This policy is reviewed annually by the Security & Compliance Lead and approved by the founder. It may be updated at any time to reflect changes in our systems, legal requirements, or community standards.

// version history

v2.0  2026-08-28  Full rewrite — 14 sections: in-scope/out-of-scope tables, reporting template, rules of engagement, prohibited actions, safe harbour, CVSS severity matrix, response timeline, recognition tiers, Hall of Thanks, coordinated disclosurev1.0  2026-08-27  Initial Responsible Disclosure policy

14. Contact us

For vulnerability reports, questions about this policy, or to request a test account:

Security reports: info@gradiosafetyltd.com
Subject line: "Responsible Disclosure — [brief description]"
PGP: Public key available on request for encrypted communication
Company: Gradio Safety LTD, Company No. 17456330, 71-75 Shelton Street, Covent Garden, London, United Kingdom, WC2H 9JQ
Related policies: Security & Ephemeral Access Policy · Compliance Overview · Privacy Policy