Trust
Found something in Sentinel? Tell us before you tell anyone else.
CyberWave would rather hear about a weakness from the person who found it than from a customer’s auditor six months later. This page says where to send a report, what to put in it, where the boundaries for research are, and what happens after you press send. There is no paid bug bounty — that is here in the first paragraph rather than three headings down.
No credit card required
Where to send it
- support@cyberwave.ca
- Subject line
- Security
- Format
- Plain text is fine. So is a screenshot, a request log or a two-minute recording.
- Reward
- None. No paid bounty — a reply from a person, a fix you can check, and credit if you want it.
You do not need to be a customer, and you do not need to write a formal advisory. One email per issue is easier for both of us than one email covering five.
What to include
Six things that turn a message into a fix.
Most reports that stall do so because reproducing them took three more exchanges than it needed to. None of this is mandatory — send what you have, and say which parts you are unsure about.
Where it is
The URL, endpoint or screen. If it involves a workspace, say which organisation and which account you were signed in as, so we can find the same rows you were looking at.
What you did
The shortest sequence that reproduces it. A request and response pair, a curl command or six numbered clicks all work. What does not work is “the login form is vulnerable”.
What you saw, and what you expected
Two separate sentences, and both matter. A good share of what arrives as a vulnerability turns out to be behaviour working as designed, and the expectation is what tells us which.
Why it matters
The impact you can actually demonstrate — data you could reach, an action you could take as somebody else, a control you could get around. A severity rating copied out of a scanner is not impact.
How you were testing
Timestamps with a time zone, the accounts and source addresses you used, and the tooling. This is how we match your report to our own records, and it is the fastest way to confirm that what you found is real.
What you ended up holding
If you saw anything that was not yours, stop, say exactly what you saw without attaching it, and delete every copy once we confirm we have what we need. Keeping it quiet is the part that becomes a problem.
A flaw reported by the person who found it costs a conversation.
Which is why nothing on this page is designed to make reporting harder: no scope document to accept, no platform account to create, no severity form to fill in, and no clause that asks you to stay quiet indefinitely.
Research boundaries
Where the line is, written down before you cross it.
The policy does not by itself permit testing: testing needs our written agreement before it starts. For anything you come across, and for any testing we agree, these are the boundaries. Outside them it stops being research and becomes an incident affecting somebody who never agreed to be part of your test — usually one of our customers, sometimes all of them.
Reporting, and testing agreed with us in writing
- Reporting a flaw you came across in ordinary use of the Sentinel application or this website.
- Testing only after CyberWave has agreed it with you in writing, and only within the scope, timing and rate agreed.
- Stopping at the point where the issue is shown, rather than seeing how far it goes.
- Reporting promptly, while the flaw is still ours to fix quietly.
- Keeping the detail between us until it is remediated.
Anything with a third party on the other end of it
- Accessing, altering, downloading or retaining data belonging to another organisation. If you can reach it, stop there and tell us that you could.
- Probing the separation between customers’ workspaces, in any circumstances.
- Disrupting the service: denial of service, load or stress testing, and automated scanners, fuzzers, brute-force tools or crawlers of any volume.
- Destructive testing — deleting or modifying records, planting content, establishing persistence, uploading malware.
- Credential attacks: brute force, password spraying, or signing in with credentials found somewhere else.
- Social engineering of CyberWave staff, customers or providers, including phishing and pretexting.
- Physical attempts on offices, hardware or people, and anything targeting a personal device or account.
- Publishing, selling or trading the finding before it is remediated.
No safe harbour
The Responsible Disclosure Policy is a route for reporting, not a research programme. It offers no safe harbour, does not authorise access to any system or data, and makes no promise about legal action either way. It cannot speak for the infrastructure providers whose systems sit underneath Sentinel or for our customers, and it does not create an exception to the Acceptable Use Policy that applies to everyone using the service.
What we do in return
What happens after you press send.
A sequence rather than a service level. Each step produces what the next one needs, and the only part with a clock on it is the part we can actually keep: we aim to acknowledge promptly.
- 01
It reaches a person
Reports go to the support address with the security attention line, and are handled by whoever is accountable for the application rather than by a triage queue that answers with a knowledge-base article.
- 02
We acknowledge it
We aim to acknowledge promptly and to tell you it is being looked at by a human. If a few days pass with nothing from us, send the message again — silence here is a failure on our side, not a verdict on your report.
- 03
We try to reproduce it
Sometimes that needs a second exchange: the exact payload, a screenshot, the account you used. If we cannot reproduce it we tell you what we tried, rather than closing it quietly and hoping you lose interest.
- 04
We decide, and we tell you why
Either it gets fixed, or we explain the decision — including the uncomfortable version, where we accept a risk and say what compensates for it. You get the reasoning either way.
- 05
We confirm the fix
When a change ships we tell you what changed so you can check it yourself. If we got something wrong the first time, we would rather hear that from you than close the thread.
- 06
We agree what gets said publicly
Once it is remediated, write it up if you want to. We will agree timing with you, correct anything factually wrong, and credit you by name if that is what you want. We will not ask you to stay quiet indefinitely.
What is deliberately absent from that list is a number of hours. A response-time commitment that no agreement backs up is worth nothing to you, and it would be the first thing to break on a bad week. Prompt acknowledgement and an honest account of where the fix stands are commitments we can keep.
What a report is usually about
Almost everything in Sentinel is a row that belongs to one organisation.
Controls, evidence, risks, actions, insurance answers, board summaries. Which makes tenant separation the promise the whole product rests on, and the report we most want if you come across it: data from one organisation reachable from another. Probing for it is never permitted — if you see it, stop there and tell us.
- 26 controls, 24 with named owners — in one example workspace — every row scoped to that tenant
- Significant actions are recorded — with who did them and when, which is how we match your timestamps and accounts to what actually happened
- So timestamps are worth the extra minute — they let us confirm the issue from our own side rather than take it on trust, and work out whether anybody else found it first
Example workspace used across this site. Northstar Manufacturing Ltd. is fictional and is not a customer.
Straight answers
There is no paid bug bounty.
Said plainly, because the alternative is a researcher discovering it after the work is done. No cash rewards, no vouchers, no swag, no reputation points, and no third-party platform holding a scope document.
- A reply from a person who is accountable for the application
- A decision with the reasoning attached, including when we accept a risk
- A fix you can verify yourself, described so you can check it
- Credit by name or handle if you want it — not being named is the default
If payment is what makes the effort worth it, that is an entirely reasonable position — and you know before you start rather than after.
What usually gets closed with an explanation
Not to discourage a report — send it if you are unsure. This list exists so you can spend your time on the things that would genuinely change our risk.
- Missing security headers, cookie flags or hardening recommendations with no demonstrated impact.
- The unedited output of an automated scanner, with no finding you have confirmed by hand.
- Self-inflicted issues — pasting a script into your own browser console, or a flaw that needs the victim to hand over their own credentials first.
- Clickjacking on a page with nothing on it to click, and version or banner disclosure on its own.
- Email configuration on domains CyberWave does not send mail from.
- An AI feature producing a wrong or incomplete draft. That is an accuracy question rather than a security flaw, and it belongs with support.
- Denial of service through volume, and anything whose proof is that the service slowed down.
The report we most want is the one nobody wants to make: evidence that data from one organisation is reachable from another. If you can break tenant separation, that is the email to send.
Scope
What is ours to fix, and what belongs somewhere else.
Sentinel runs on infrastructure CyberWave does not own, and it holds programmes CyberWave does not operate. Both facts change where a report should go.
- In scope
- The Sentinel application at sentinel.cyberwave.ca, and the cyberwave.ca website you are reading now — including anything either of them exposes.
- Report to the provider
- Flaws in the hosting, database or AI providers underneath Sentinel. They run their own disclosure processes, and a report to us is slower than a report to them. The providers are named on the subprocessor page.
- A customer’s own systems
- Sentinel records that a control is in place; it does not operate it. A weakness in an organisation’s own environment is theirs to fix, and CyberWave has no standing to accept a report about it.
Questions
What researchers ask us first.
Answered here so the first email can be about the finding rather than about the process.
Do you pay for reports?
No. There is no paid bug bounty, no reward tiers, no points and no platform behind this page. What you get is a human reply, a straight answer about what we are doing with it, a fix you can verify yourself, and credit by name if you want it. We would rather you knew that before you spent a weekend on this than after.
What can I test against?
Nothing, until we have agreed it with you in writing — the Responsible Disclosure Policy does not by itself permit testing, and that applies to customers too. Write to us first and say what you want to look at, and we will agree a scope, timing and rate or tell you why not. If you come across a flaw in ordinary use, stop there and report it. Another customer’s workspace is never a target, and “I only looked” is not a defence we can offer them on your behalf.
How long will it take to hear back?
We aim to acknowledge promptly and to keep you informed while the work happens. We are not going to print a number of hours on a marketing page that no agreement obliges us to meet. If you have heard nothing after a few days, resend the message — that is a missed email on our side rather than a decision.
Can I publish what I found?
Yes, after it is remediated and with the timing agreed between us. Publishing before there is a fix puts every organisation using Sentinel at risk for no benefit, which is the one boundary here we will hold firmly. We will not use a disclosure discussion to bury a finding, and we will not ask for indefinite silence.
Do you publish a PGP key, or a security.txt file?
There is no published encryption key today, and we are not going to list a fingerprint nobody holds the private half of. If your report contains something genuinely sensitive, say that in a first short message and we will agree a channel before you send the detail. The address cyberwave.ca/security.txt points at this page.
Will CyberWave take legal action against a researcher?
The Responsible Disclosure Policy offers no safe harbour and makes no promise about legal action either way. What it does say: a good-faith report is not, in itself, treated as a breach of the Acceptable Use Policy or of any agreement with CyberWave — which covers the report, not conduct the policy prohibits. Stay inside the boundaries set out above, report promptly, and stop the moment you reach another organisation’s data. The policy speaks only for CyberWave, not for the providers whose systems sit underneath Sentinel or for our customers.
Anything on this page unclear before you send something? Write to support@cyberwave.ca with “Security” in the subject line and ask. The address legal centre holds the agreements this page sits inside.
Would you rather see it than test it?
Sentinel is in production and priced on this website. If your interest in the application is professional rather than adversarial, a walkthrough covers the same ground faster — and you can bring the questions this page did not answer.
No credit card required
- Published pricing on every standard plan
- No credit card required for the trial
- No automatic charge when a trial ends
- Tenant-isolated architecture, data stored in Canada
- Clear data-processing terms
- No compliance guarantee — human judgement still required