1. Purpose
We want security researchers to have a clear, published route to tell us about a vulnerability in our products and services. This document is that route. It tells you what we want you to test, how to report what you find, what we will do in response, and what protection you have when you follow it.
If you are reading this because you have already found something: go to section 4, How to report. You do not need to read the rest first.
2. In scope
- Our production web applications and their public APIs.
- Our public-facing infrastructure: the hostnames and IP ranges we operate.
- Our mobile and desktop client applications, where we publish them.
- Our published container images and software packages.
If you are unsure whether a target belongs to us, ask before you test. Send the question to the contact in section 4. A target that merely mentions our name is not necessarily ours.
3. Out of scope
Do not test, and we will not accept reports about, the following.
Systems that are not ours
- Third-party services we consume (identity providers, payment processors, cloud consoles, SaaS tools), unless the defect is in our configuration of them and you can show that.
- Customer-operated deployments and customer-managed data. Several of our customers run their own instances. Testing those is testing someone else's system.
Activity we will never authorise
- Any access to, download of, or modification of real patient data or any other personal data. Our products handle health information. If a proof of concept needs real patient records, stop, and report the access path without the data.
- Denial of service, load testing, stress testing, or resource-exhaustion testing of any kind.
- Physical attacks, social engineering, or phishing of our staff, our customers, or their patients.
- Any attempt to move laterally, install a persistent implant, or keep access after you have demonstrated the finding.
Report classes we routinely close as informational
- Missing hardening headers, cookie flags, or TLS-configuration preferences with no demonstrated exploit path.
- Output from an automated scanner with no manual validation.
- Self-XSS, or an issue that needs a victim to paste attacker-supplied content into their own developer console.
- Rate limiting on non-authentication endpoints, absent a demonstrated impact.
- Vulnerabilities that only affect an end-of-life browser or platform.
- Publicly known CVEs in a dependency, with no shown reachability in our product. Tell us anyway if you can show it is reachable.
4. How to report
Send your report by email to:
Please include, as far as you can:
- The affected product, hostname, or endpoint.
- What kind of issue it is, and what an attacker gets from it.
- Reproduction steps precise enough for us to see it ourselves.
- Any proof-of-concept code, request/response captures, or screenshots.
- Whether, to your knowledge, anyone else already knows about this.
Two requests about the contents of your report:
- Do not send us personal or patient data. If you accessed records in the course of finding the issue, describe the access path and the shape of what was exposed — field names, record counts, which tenant — and redact the values. If you hold copies, tell us, and delete them once we confirm we have reproduced the issue.
- One issue per report, unless several only make sense chained together. If they chain, say so and show the chain.
If you believe the issue is being actively exploited, put ACTIVE EXPLOITATION in the subject line.
5. What you can expect from us
| Stage | What happens | Target |
|---|---|---|
| Acknowledgement | A human confirms we have your report | 1 business day |
| Triage | We reproduce it and assign a severity | 5 business days |
| Status updates | We tell you where the fix has got to | Every 10 business days, and at every change of status |
| Fix — Critical | Remediated or mitigated in production | 7 days |
| Fix — High | Remediated or mitigated in production | 30 days |
| Fix — Medium | Remediated or scheduled with a date | 90 days |
| Fix — Low | Scheduled into normal maintenance | Next scheduled release |
Targets are business days, Pacific/Auckland. If you believe an issue is being actively exploited, use the subject line in section 4 — those are paged, not queued.
The fix targets apply to the services we host and to the availability of a patched release. Where a customer operates their own deployment, we cannot control when they upgrade; see section 6.
We will also:
- Tell you our severity rating and how we reached it. If you disagree, say so; we will re-examine it.
- Tell you when the fix is live.
- Credit you by name or handle if you want that, or keep you anonymous if you prefer. We will ask before naming you.
- Tell you plainly if we decide not to fix something, and why.
We do not currently operate a paid bug bounty. We will not offer a reward and then dispute it afterwards; if that changes, this section changes with it.
6. Coordinated disclosure
We ask that you give us 30 days from your first report before you publish, so a fix can reach the people running our software.
We will not use that period to stall. If we need longer — a fix that requires a coordinated customer upgrade, for example — we will ask you, explain why, and propose a date. If we go quiet on you, or we dispute that a demonstrated issue is real, you are not obliged to keep waiting.
Because some of our customers operate their own deployments, a fix on our side is not the same as a fix everywhere. We may ask for extra time so those operators can upgrade. We will tell you if that is what we are asking for, and we will not present it as an indefinite embargo.
7. Safe harbour
If you make a good-faith effort to follow this policy, then in respect of your security research on our in-scope systems:
- We will not bring or support a civil claim against you.
- We will not report you to law enforcement, or ask a prosecutor to act.
- We will not treat your activity as a breach of our terms of service, and we will not use those terms as grounds for a claim about your research.
- If a third party brings an action against you for research that we can see complied with this policy, we will say publicly and in writing that your activity was authorised.
We consider you to be acting in good faith when you:
- Stay inside the scope in sections 2 and 3.
- Stop at the point you have demonstrated the issue, and do not take more data or more access than the demonstration needs.
- Do not access, retain, or disclose personal or patient data, and tell us promptly if you encounter any.
- Do not degrade, disrupt, or destroy our service or our customers' data.
- Report to us promptly, and keep to section 6 on publication.
Limits, stated honestly. This safe harbour is what we undertake. We cannot waive the rights of third parties, and we cannot bind a prosecutor or a regulator in any jurisdiction. If your research would reach a third party's system or data, get their authorisation too. If in doubt about whether an action is covered, ask us first — we would much rather answer the question than argue about it afterwards.
Nothing in this section authorises access to patient health information. There is no good-faith route to that, and we will not indemnify it.
8. This document
We will review this policy at least annually, and whenever the accompanying security.txt approaches its Expires date.