Skip to content
All legal documents

Vulnerability Disclosure Policy

How to report a security vulnerability in HealthCoreSecurity AI, what we commit to in return, and the safe harbour that protects good-faith research.

Draft — no effective date set

Draft — not yet in force

This document has not been finalised and does not create binding obligations. It still needs company details that only we can supply, and review by Canadian privacy counsel. Anything shown as [[LIKE THIS]] is a blank, not a value.

Outstanding: entityName, entityJurisdiction, registeredAddress, privacyOfficerEmail, securityEmail, supportEmail, generalEmail, governingProvince, effectiveDate.

We sell security. It would be absurd for us to make reporting a flaw in our own systems difficult, so we have not.

If you have found a vulnerability affecting [[ENTITY NAME]], tell us at [[SECURITY EMAIL]]. You do not need permission to contact us, and you do not need an existing relationship with us.

1. What we commit to

  • Acknowledgement within 3 business days. A human reply, not an autoresponder.
  • An initial assessment within 10 business days, telling you whether we have reproduced the issue and how we have rated it.
  • Progress updates at least every 14 days until it is resolved or we have explained why it will not be.
  • Credit, publicly, if you want it and the fix is shipped. If you would rather stay anonymous, that is fine too.
  • No legal action against you for research conducted under section 5.

We will not ask you to sign an NDA as a condition of us fixing a flaw you reported.

2. In scope

  • healthcoresecurity.ca and its subdomains
  • The clinic dashboard and the customer-facing application
  • Our public APIs
  • The infrastructure we operate that serves those

3. Out of scope

Please do not report these. They are known, accepted, or belong to someone else:

  • Findings from automated scanners with no demonstrated impact
  • Missing security headers with no exploitable consequence
  • Weak TLS ciphers or configuration without a working attack
  • Rate-limiting or brute-force concerns on endpoints with no authentication
  • Social engineering, phishing or physical attacks against our staff or offices
  • Denial of service, volumetric testing, or anything that degrades the service for our customers
  • Reports about third-party services we use — report those to their own programmes, though we are glad to be told
  • Vulnerabilities requiring a jailbroken device, a rooted OS, or physical access to an unlocked machine
  • Self-XSS, clickjacking on pages with no sensitive action, or missing cookie flags with no impact
  • Email configuration findings (SPF, DKIM, DMARC) without a demonstrated spoofing path

Our customers' clinics are not in scope. Do not test a clinic's systems. If you believe a specific customer is affected, tell us and we will contact them.

4. How to report

Send to [[SECURITY EMAIL]] with:

  1. What the issue is, and what an attacker could do with it
  2. Where it is — the URL, endpoint or parameter
  3. Steps to reproduce, ideally the exact requests
  4. Anything supporting it: a proof of concept, a screenshot, a short video
  5. How you would like to be credited, or that you would not

Write in English or French. One issue per report, please — it keeps triage honest.

If your report contains personal information or customer data you encountered, say so at the top. Do not attach more of it than you need to demonstrate the issue.

5. Safe harbour

If you make a good-faith effort to follow this policy while researching:

  • we will consider your research authorised under the Criminal Code provisions on unauthorised use of a computer, and under any applicable computer-misuse and anti-circumvention law;
  • we will not bring or support a civil claim or criminal complaint against you for it;
  • we will not report you to law enforcement for it;
  • if a third party brings action against you for research that complied with this policy, we will make it known that your actions were authorised.

This authorisation extends only to us. It cannot authorise you against our customers, our providers, or anyone else, and it does not survive conduct that breaches section 6.

If you are unsure whether something is permitted, ask us first at [[SECURITY EMAIL]]. We would far rather answer a question than argue about it afterwards.

6. Rules

To stay inside section 5:

  • Only test accounts and data that are yours, or that you have explicit permission to use.
  • Stop as soon as you have confirmed a vulnerability. Enough to prove it, no further.
  • Do not access, modify, download, retain or destroy anyone else's data. If you encounter personal information, personal health information or credentials, stop, do not save a copy, and tell us immediately in the report.
  • Do not degrade, interrupt or damage the service. No denial of service, no automated load testing, no spamming forms.
  • Do not use a finding to pivot further into our infrastructure.
  • Do not extort us. A report conditioned on payment is not a report.
  • Give us a reasonable chance to fix it before telling anyone else. 90 days is our default; if the issue is being actively exploited, tell us and we will move faster together. We will not use a disclosure timeline to sit on a fix.

Breaking these does not automatically end safe harbour — we will consider what you did and why — but it is the point at which we stop being able to promise it.

7. Rewards

We do not currently run a paid bug bounty, and we would rather say so than imply one. What we offer is a fast, respectful process, public credit if you want it, and the safe harbour above.

If you find something serious, tell us anyway — and tell us if the absence of a bounty is a problem for you. It is a conversation worth having internally, and hearing it from researchers is how that changes.

8. Our own security posture

What we do to protect customer information is described on the Security page.

9. Machine-readable

This policy is advertised at /.well-known/security.txt in the format described by RFC 9116.