Responsible Disclosure Policy

How to report a security vulnerability to CyberWave, and what CyberWave does in return

1. Two things to know before you read any further

There is no paid bug bounty. CyberWave does not pay for vulnerability reports, does not offer bounties, rewards, swag or credits, and has no plans announced to do so. If payment is what you are looking for, this programme will disappoint you, and it is fairer to say that in the first paragraph than in a footnote. What CyberWave offers is a good-faith review of your report, honest communication, and credit if you want it.

There is no published response time. CyberWave is a small team. It does not operate a security operations centre or 24/7 monitoring, and it does not provide managed detection and response, emergency incident response, incident response retainers, penetration testing or forensics. Rather than publish a target it cannot guarantee, this policy does not commit to a response time. CyberWave will acknowledge your report and review it in good faith, and section 8 sets out what else it does in return.

2. Why CyberWave publishes this policy

CyberWave sells a cybersecurity readiness platform. A vendor in that business that has no way to receive a vulnerability report is not credible, and a person who cannot find a route ends up choosing between staying quiet and going public. This policy exists so that route is obvious, so the boundaries are written down rather than guessed at, and so a person acting in good faith knows where they stand before they do anything.

This policy is a route for reporting, not a research programme, and section 6 explains what that means in practice. It is referenced by the Terms of Service (§21.2(c)) and by the Acceptable Use Policy (§12). It is a public policy, not a customer contract.

3. Scope — what a report can be about

3.1 In scope. The following are operated by CyberWave, and reports about them are in scope under this policy, subject to the limits in §6:

3.2 Out of scope — third-party platforms. CyberWave builds on service providers, and a vulnerability in a provider's own platform is that provider's to receive and to fix. CyberWave has no authority to consent to testing against them, and this policy does not do so. The providers CyberWave relies on are named in its published Subprocessors document, and include:

• Supabase — database, authentication and file storage;
• Vercel — application hosting and compute, and hosting for the cyberwave.ca website;
• Anthropic — AI model provider;
• Stripe — payment processing for paid subscriptions;
• Resend — application email, and account emails such as sign-up confirmation and password reset;
• Microsoft 365, provided through GoDaddy — the support@cyberwave.ca mailbox; and
• GoDaddy — domain registration and DNS.

If you believe you have found a flaw in one of those platforms, report it to that provider directly. If you believe you have found a flaw in how CyberWave has configured one of them — an over-permissive storage rule, a missing authorisation check, a leaked key — that is in scope under §3.1 and CyberWave wants to hear about it.

3.3 The marketing site, specifically. cyberwave.ca is hosted on Vercel, and some of what serves it is the hosting platform's rather than CyberWave's. Report what you find; CyberWave will tell you honestly which side of that line it falls on.

3.4 Not in scope in any circumstances. CyberWave's customers' own systems; any organisation named or described inside a customer's Workspace; CyberWave personnel's personal accounts, devices and homes; and any system not listed in §3.1. A customer's data and a customer's infrastructure are never a legitimate target under this policy, however interesting the finding would be.

3.5 If you are a CyberWave customer. Testing the Services as part of your own supplier-assurance programme needs CyberWave's prior written consent — write to support@cyberwave.ca with the subject line "Security" before you test (Acceptable Use Policy §12.3). If you have found something incidentally in ordinary use, that is not a breach of the Acceptable Use Policy (§12.2): stop there and report it under this policy. If you think your own data has been affected, say so in the first line so it is treated as a possible security incident rather than as a vulnerability report; the Data Processing Addendum governs incident notification.

4. How to report

4.1 The channel.

Use that subject line. The same mailbox receives support, privacy, legal and abuse messages, and the subject line is how a security report is identified among them. CyberWave does not publish a separate security mailbox; this mailbox with that subject line is the route for security reports.

4.2 If you need to send something sensitive. CyberWave does not currently publish an encryption key for security reports, and the support@cyberwave.ca mailbox is provided through Microsoft 365, via GoDaddy, and may be processed outside Canada. If your report would include a credential, a key or anything else you should not put in plain email, send a first message describing the general nature of the finding without the sensitive detail, and say that you need a secure channel. Do not send the sensitive detail unless a way of receiving it has been agreed with CyberWave.

4.3 One report per issue. Please send one report per distinct finding, rather than a bundle, so each can be tracked and answered on its own.

4.4 Language. Reports in English or French are welcome.

5. What to include

A report CyberWave can act on usually contains the following. If you cannot supply something, send the report anyway and say what is missing. Nothing in this list is a reason to go further than §6 allows.

Please do not include another person's or another customer's data in your report. Describe it, do not attach it.

6. What not to do

This policy does not authorise access to any system, account or data. The Acceptable Use Policy (§12.1) prohibits testing, probing or scanning the Services except with CyberWave's prior written consent, and the Terms of Service (§21.2(c)) prohibit it except under this policy or with prior written consent. This policy does not itself permit testing and does not add a wider permission: the only route to testing is CyberWave's written agreement, given before the testing starts (§6.1). If you are a customer or a user of the Services, the Acceptable Use Policy and the Terms of Service apply to you, and nothing in this policy changes them.

6.1 No testing without prior written consent. Do not test, probe, scan, fuzz, load-test, penetration-test or red-team the Services or any asset listed in §3.1 unless CyberWave has agreed to it in writing before you start, and then only within the scope, timing and rate agreed. Never test a third-party platform (§3.2), a customer's systems, or anything else outside §3.1. If you come across an issue in ordinary use, stop there and report it under §4.

6.2 No access to other people's data, and no probing of tenant isolation. Do not access, copy, download, retain, modify, delete or transmit data belonging to another customer, another user, or CyberWave. Do not attempt to circumvent, weaken, probe for a weakness in, or test the boundaries of the separation between customers' Workspaces (Acceptable Use Policy §5.2); this policy never permits that. If you come across such data, or what appears to be a way to reach one customer's Workspace from another's: stop immediately, do not look further, do not save or share anything, tell CyberWave in your report exactly what you saw without attaching it, and delete every copy once CyberWave confirms it has what it needs. Where CyberWave has agreed to testing under §6.1, use only your own accounts and your own data.

6.3 No disruption. Do not degrade, interrupt or take down the Services or any part of them. That means no denial-of-service or resource-exhaustion activity of any kind, no load or stress testing, no lock-out or account-enumeration attempts, no changes to configuration or data you do not own, and no persistence — do not leave a backdoor, a scheduled task, a file or an account behind.

6.4 No automated tools. Do not run automated scanners, fuzzers, brute-force tools or crawlers against the Services. If you believe a tool is genuinely needed to demonstrate a finding, ask first (§9.6); nothing may be run unless CyberWave has agreed the scope, timing and rate with you in writing.

6.5 No social engineering. Do not phish, pretext, vish, smish, bribe or otherwise socially engineer CyberWave personnel, contractors, customers, suppliers or anybody else. Do not target CyberWave staff members' personal accounts or devices. Do not use a support ticket as an attack path.

6.6 No physical attacks. No physical intrusion, tailgating, dumpster diving, device theft, or interference with premises, hardware or people. CyberWave is a small company and its people work from where they live, so there is no meaningful distinction here between a corporate site and somebody's home. Neither is a target.

6.7 No spam, no defacement, no third-party harm. Do not send unsolicited messages through the Services, do not alter public content, and do not do anything that would harm a third party.

6.8 Report promptly. Report what you find as soon as you reasonably can after discovering it, and before you tell anyone else. Holding a finding to build a bigger report, to time a publication, or to use as leverage is outside this policy.

6.9 Do not demand payment. There is no bounty (§1). A report accompanied by a demand for payment, a threat of publication or of disclosure to a customer or regulator unless money is paid, or any similar pressure, is not a good-faith report, is outside this policy entirely, and will be treated accordingly.

6.10 Obey the law. Nothing in this policy authorises conduct that is unlawful, and this policy cannot make unlawful conduct lawful. See §9.

7. Coordinated timing, and publication

7.1 Please do not publish before it is fixed. CyberWave asks that you do not disclose a finding publicly, or to any third party, until CyberWave has confirmed to you that the issue is remediated, or you and CyberWave have agreed the timing.

7.2 What this request is, and what it is not. It is a request to you, not a deadline CyberWave undertakes to meet — §1 explains why this policy publishes no response-time commitment. If you have told CyberWave when you intend to publish and a fix is going to take longer than that, CyberWave will tell you why and ask you for more time. If you do not agree, tell CyberWave before you publish; it would rather have that conversation with you than discover a finding published without one.

7.3 Working together on publication. Where you intend to publish, CyberWave is glad to check your write-up for factual accuracy, to confirm the remediation timeline, and to be quoted. CyberWave asks that a publication does not include another customer's data, another organisation's identifying details, or a working exploit against an unpatched version.

7.4 A live, exploited issue. If you have reason to believe an issue is being actively exploited, say so in the first line of your report. Timing is different in that situation, and CyberWave will discuss it with you.

8. What CyberWave commits to

For a good-faith report about an asset listed in §3.1, made in line with §6, CyberWave commits to:

1. Acknowledge your report, confirming that it has been received.
2. Review it in good faith, and tell you plainly whether it has been reproduced, whether it is accepted as a vulnerability, or why it has not been — a report that is not accepted gets a reason, not silence.
3. Keep you informed as the review and any fix progress, and confirm when remediation is complete.
4. Give you credit where you want it, in the form and under the name or handle you choose, and no credit at all if you prefer that.
5. Not treat a good-faith report as a hostile act. Making a good-faith report is not, in itself, a breach of the Acceptable Use Policy or of any agreement with CyberWave. This covers the report; it does not authorise or excuse conduct that §6, the Acceptable Use Policy or the Terms of Service prohibit.
6. Handle your report as confidential, and not pass your identity or contact details to a third party without your agreement, except where the law requires it.
7. Handle your personal information under the Privacy Policy. Your name, email address and the contents of your report are held to run this programme, to fix the issue, and to keep a record that it was fixed.

CyberWave asks you to keep the finding confidential in line with §7, and to work with it in good faith. This is a two-way arrangement.

9. No safe harbour

9.1 No safe harbour is offered. This policy does not contain a safe harbour. Read it as a description of how to report and what not to do, not as a promise about how any testing or other conduct will be treated. §8 item 5 and §9.5 describe how CyberWave approaches a good-faith report and a candid disclosure; neither is a safe harbour.

9.2 No authorisation of access. This policy does not authorise access to any system, account or data, and it does not by itself permit testing. The only route to permission to test is CyberWave's prior written agreement (§6.1), and this policy never permits probing tenant isolation (§6.2).

9.3 No promise about legal action. This policy makes no promise, either way, about legal action.

9.4 The limits, stated plainly. Nothing in this policy:

• authorises anything on a third-party platform, on a customer's systems, or against a customer's data — CyberWave has no authority to give that, and §3.2 and §6.2 are absolute;
• waives any right of any CyberWave customer, provider or other third party, and it cannot;
• prevents, or can prevent, a prosecution or an action by a public authority; or
• excuses conduct that §6 prohibits, conduct that is unlawful, or a demand for payment under §6.9.

9.5 If you go over the line. If you realise you have gone beyond what §6 allows — most commonly by seeing data that is not yours — stop, and tell CyberWave immediately and completely in your report. CyberWave will take a prompt and candid disclosure into account. That is a statement of how CyberWave intends to behave, not a guarantee of any outcome, and it cannot be one, because the rights of the person whose data it was are not CyberWave's to give away.

9.6 If you are unsure whether something is in scope, ask first. Write to support@cyberwave.ca with the subject line "Security" and describe what you intend to do, before you do it. A question before the fact is always cheaper than a disagreement after it, and CyberWave will answer. Nothing you describe is permitted unless CyberWave has agreed to it in writing.

10. Findings usually assessed as informational

The following are welcome and will be read, but are usually assessed as informational unless the report shows a concrete impact. Where you can explain that impact without going beyond §6, please do.

• Missing or misconfigured security headers, cookie flags or TLS options with no concrete impact
• Theoretical findings, best-practice deviations and version-disclosure banners with no exploit path
• Missing rate limits on endpoints where no sensitive action is reachable
• Self-inflicted issues that require the reporter to alter their own browser, extensions, device or session
• Social-engineering or physical findings, which are outside scope entirely (§6.5, §6.6)
• Vulnerabilities affecting only users of end-of-life or unpatched browsers, plugins or operating systems
• Reports about a third-party platform rather than CyberWave's configuration of it (§3.2)
• Email spoofing or deliverability findings where CyberWave's published DNS records already prevent the attack described

CyberWave does not publish a severity matrix. Impact is assessed on the facts of the report, and CyberWave will tell you how it assessed yours.

11. Credit

If you want credit, tell CyberWave how you would like to be named — a real name, a handle, an organisation, or some combination — and it will use exactly that. CyberWave does not presently publish an acknowledgements page; credit today means being named in any release or customer-facing note about the fix, and in any public statement CyberWave makes about the issue. If an acknowledgements page is published later, CyberWave will ask you before adding you to it. If you want no credit, say so and there will be none.

12. Reporting something that is not a vulnerability

13. Changes to this policy

CyberWave may update this policy. The current version is the one published with the version identifier and effective date shown at the top of this policy. The version in force when you make a report is the version that applies to it, and a later change does not apply retroactively to a report already made.

14. Contact

support@cyberwave.ca — subject line: Security

CyberWave is CYBER WAVE INC., a corporation existing under the laws of Ontario, Canada (Ontario Corporation Number 1000780137), located in Markham, Ontario, Canada. CyberWave does not publish a street or postal address, so notices to CyberWave, including under this policy, are given by email to support@cyberwave.ca.

Thank you for taking the time to report something rather than walking away from it.