Vulnerability Disclosure Policy

Reading note. WiseWave Limited welcomes good-faith security research on the Tirvea platform. This Policy explains how to report a vulnerability, what to expect, and the rules that keep your testing safe and lawful. There is no bug bounty; we recognise researchers with optional credit.

1. Purpose

Purpose. To explain how security researchers can responsibly report vulnerabilities in the Tirvea platform to WiseWave Limited, and what we commit to in return. Our goal is to make it safe and straightforward to report issues so we can protect our members.

2. Scope

Purpose. To state what this Policy covers. It covers security vulnerabilities in the Tirvea platform and its services operated by WiseWave Limited. It does not authorise testing of third-party services we rely on (for example Supabase, Stripe, or Amazon Web Services), which are governed by those providers' own policies. It does not cover general bug reports or support questions (use info@tirvea.com), abuse or safety reports (use the in-product reporting tools), or requests from authorities (Law Enforcement Guidelines, /legal/law-enforcement).

3. Security Contact

Purpose. To tell you where to send a report. Send vulnerability reports to info@tirvea.com with "Security" in the subject line. We are working to provide a dedicated security contact and a security.txt file so reports can be routed and, where you wish, encrypted; until then, please use info@tirvea.com. [Legal review required before publication - confirm the monitored security contact and publish a security.txt.]

4. How to Report

Purpose. To explain the reporting workflow. Report the issue privately to the security contact (§3) before disclosing it anywhere else. Give us enough detail to reproduce and assess the issue (see §5). Please do not open a public issue, post on social media, or share the vulnerability with third parties until we have had a reasonable opportunity to investigate and remediate (see coordinated disclosure, §7).

5. What to Include

Purpose. To help us act quickly. A good report usually includes:

• a clear description of the vulnerability and its potential impact;
• the affected area (URL, endpoint, or feature) and the environment;
• step-by-step instructions to reproduce, with any proof-of-concept;
• any relevant logs, requests, or screenshots; and
• how we can contact you for follow-up.

Please keep any proof-of-concept to the minimum needed to demonstrate the issue, and avoid accessing, modifying, or storing data that is not yours.

6. Acknowledgement and Timelines

Purpose. To set expectations on timing. We aim to acknowledge a valid report within a few business days, to keep you informed as we investigate, and to work towards timely remediation prioritised by severity. These are targets, not guarantees, and may vary with the complexity of the issue. [Legal review required before publication - set any binding acknowledgement and remediation timelines.]

7. Coordinated Disclosure

Purpose. To explain how public disclosure is coordinated. We follow coordinated disclosure: we ask that you give us a reasonable period to remediate before any public disclosure, and we will work with you on timing. Where you wish to publish, we will try to agree a disclosure date and, where appropriate, coordinate a joint statement. We ask that public disclosure not include member data or details that would put members at risk.

8. Remediation

Purpose. To explain what we do after a valid report. We triage and assess the issue, reproduce it, prioritise a fix by severity and risk, and remediate it in our systems. Where an issue affects data or members in a way that meets the legal threshold, we handle notification under our incident-response process and the Security Policy (/legal/security). We will let you know when the issue is resolved, and, with your permission, may credit you (§12).

9. Safe Harbor

Purpose. To protect good-faith research. If you make a good-faith effort to comply with this Policy, we will not pursue or support legal action against you for your research, and we will treat your testing as authorised for the purposes of our Terms of Service (/legal/terms) and Acceptable Use Policy (/legal/acceptable-use). To stay within safe harbour you must: act in good faith; avoid privacy violations, data destruction, and service disruption; only interact with accounts and data you own or have explicit permission to test; stop as soon as you have confirmed a vulnerability; and report it promptly and confidentially. This safe harbour does not extend to actions that violate applicable law, and it cannot waive the rights of third parties. [Legal review required before publication - confirm the safe-harbour scope against computer-misuse and data-protection law.]

10. Prohibited Testing and Out of Scope

Purpose. To keep testing safe and lawful. The following are not authorised under this Policy:

• denial-of-service (DoS/DDoS), load testing, or high-volume automated scanning that degrades the service (note the platform rate-limits sensitive actions);
• accessing, modifying, deleting, or exfiltrating other members' data, or attempting to;
• social engineering, phishing, or targeting our staff, contractors, or vendors;
• physical attacks against offices or infrastructure;
• testing third-party services we depend on (Supabase, Stripe, AWS, and others);
• deploying malware, backdoors, or persistence; and
• publicly disclosing before coordinated disclosure (§7).

Findings that are theoretical or without realistic security impact (for example, missing best-practice headers with no demonstrated exploit, or reports from automated tools without validation) may be considered out of scope. Testing outside this Policy is unauthorised and is handled under the Acceptable Use Policy (/legal/acceptable-use) and, where warranted, referred to authorities.

11. CVE Handling

Purpose. To explain how public identifiers are handled. We do not currently operate a CVE numbering-authority process. Where a vulnerability warrants a public identifier, we will coordinate CVE assignment on a case-by-case basis, through the appropriate authority and with you as reporter where you wish to be involved. [Legal review required before publication - confirm the CVE-handling stance.]

12. Recognition

Purpose. To be clear about what we offer. There is no bug bounty and no monetary reward. With your permission, we are happy to credit you publicly once an issue is resolved (for example, in a security acknowledgements list); you may also choose to remain anonymous. Recognition is at our discretion and does not create any entitlement to payment. [Legal review required before publication - confirm the recognition/credit approach.]

13. Legal

Purpose. To set the legal boundaries. This Policy does not grant you rights over WiseWave Limited's or any third party's systems or data beyond the limited authorisation in §9. It does not override applicable law, and it does not create a contract or a reward obligation. Your research must comply with all applicable laws, including computer-misuse and data-protection law. Nothing here limits WiseWave Limited's rights or your statutory rights. This Policy is read together with the Terms of Service (/legal/terms) and the Acceptable Use Policy (/legal/acceptable-use).

14. Policy Updates

Purpose. To explain changes to this Policy. We may update this Policy as our processes evolve, including to add a dedicated security contact, a security.txt, or defined timelines. The current version and its effective date are shown on this page. Changes are prospective and do not reduce a protection that already applied to a report made in good faith before the change.

15. Contact

Purpose. To tell you how to reach us.

• Contracting entity: WiseWave Limited (Company Number 762171)
• Registered office: 39 Cooley Park, Dundalk, Co. Louth, A91 AP2V, Ireland
• Security reports: info@tirvea.com (subject line "Security")

For our internal safeguards, see the Security Policy (/legal/security); for the general rules on testing, the Acceptable Use Policy (/legal/acceptable-use); for authority requests, the Law Enforcement Guidelines (/legal/law-enforcement).