Documentation
Reporting a security flaw
Where to send it
Write to security
Kestrel stores children's records, so we would rather hear about a weakness early and informally than not at all. Tell us what you found, the address of the page or the endpoint, and what you did to see it. A screenshot, or a request and its response, is enough. Working exploit code is welcome.
A school's IT manager who thinks somebody has reached records they should not have writes to the same address, and the support page covers everything else that goes wrong.
What happens to your report
- A person acknowledges it within two business days and tells you who is handling it.
- We give it a severity and an owner within five business days, using the four severities below, and tell you which one we reached and why.
- We fix it and tell you when the fix is released. A security fix is released on its own, ahead of the month's other changes, and it is marked as a security fix in the release notes.
- We credit you however you ask, by name, by handle or not at all.
Where the weakness was reachable in a deployment a school was using, we tell the affected schools what happened and what it means for them. That path is the incident response plan's, and it runs whether the weakness came from you or from us.
How soon a fix is released
The clock runs from triage, because triage is where the severity is settled and the severity decides the target. The periods are counted in calendar days.
- Critical
- Somebody with no account can reach a child's record, sign in as another person, or reach another school's data.Fix released within seven days
- High
- Somebody with an account at a school can reach records that account may not read, or can act as another person at that school.Fix released within thirty days
- Medium
- A weakness that needs an unusual sequence of events, or that reaches information the school does not treat as confidential.Fix released within ninety days
- Low
- A weakness with no path to a record, such as a missing hardening header on a page with no record on it.Fix released within the next ordinary release
What we ask of you
- Report what you find to the address above, and give us a reasonable period to fix it before you write about it in public.
- Use your own account and your own test school. Do not read, change or keep any record belonging to a real person.
- Do not run a denial-of-service test, send bulk email or SMS through the product, or try social engineering on anyone at a school or at Hoverpoint.
- Stop and tell us as soon as you reach a person's record by accident.
Within those bounds we will not pursue you for reporting what you found. There is no bug bounty, and we would rather tell you that here than leave you to guess.
In scope: Kestrel itself, its API, and the published source. The hosts and services it runs on belong to their own providers and have their own disclosure programmes, and a school's own network and devices are the school's.
Security advisories
An advisory is published for a weakness that was reachable in a deployment a school was using, whether we found it or somebody told us. It says what the weakness was, which releases it was in, and what an affected school has to do, which for a hosted fix is nothing.
No security advisory has been published.
How long Kestrel is supported for
One version of Kestrel is in service. A school on a current subscription is running it, and each security fix is released into it. The support period for a school runs for the whole of its subscription and ends when the subscription ends.
A software bill of materials in SPDX form, listing each component of the deployed product with its version and licence, is attached to each release and kept for 10 years. A school's assessor who wants the one for the release it is running asks at the address above.
Each release is checked for known weaknesses in those components before it goes out, and a release with a known exploitable high or critical weakness in it does not go out unless a named person has recorded why it is acceptable. The security page covers the rest of the posture.
The same policy, for your tooling
https://app.kestrel.hoverpoint.io/.well-known/security.txt is this policy in the form RFC 9116 describes: the contact address, the day the file expires, and the address of this page. The file expires on the day this document is next reviewed, so an address that has gone stale is visibly stale.
The same policy is in SECURITY.md in the source, which is where a reader who arrives at the repository first will look.