Trust centre · Disclosure policy
Vulnerability disclosure policy
How to report a security issue in the platform, what happens next, the times we target, and the safe harbour that covers good-faith research.
One inbox, a written timeline, no public bug-bounty theatre.
We do not run a public bug-bounty programme. The times below are targets, not guarantees.
Mail security@sylphx.com with what you found, where, how to reproduce it, and what impact you believe it has. Plain email is enough; encrypted reports are welcome if you already have a channel, and we will not ask you to register for a portal.
- Step 1 — send one email. One report per issue, with a proof of concept where you have one; it shortens triage more than a long report does.
- Target: 2 business days — we acknowledge. We aim to confirm we received the report. If we cannot reproduce it, we may ask for what is missing.
- Target: 5 business days — we triage. We aim to assess severity and tell you whether the report is in scope. We aim to fix critical issues within 14 days; the time a fix takes depends on the issue.
- Before disclosure — we coordinate. We ask for at least 90 days before public disclosure, or sooner only if we agree in writing. We aim to tell you when the fix ships.
What makes a report fast to act on
- The endpoint, header or UI path involved, with the exact request you sent.
- The account, project and timestamp you used, so we can correlate logs.
- Whether another customer’s data was reachable — isolation escapes are always treated as critical.
- Any constraint you need from us (embargo, credit preference, or no credit).
The hosted platform is in scope.
A report is in scope when it is about what we run, and when the data you touched is yours.
Reports about the hosted platform — the API, the build and deploy pipeline, the console, and this site — are in scope. So is anything that reaches another customer’s data, which is the one class we treat as critical before we look at anything else: an isolation escape, a credential leak, access to the deploy pipeline, or exposure of data that is not yours.
You may test projects you own, provided you do not degrade shared infrastructure. Send the schedule to security@sylphx.com first so we do not treat the traffic as an attack. Multi-tenant tests that touch other projects are out of scope for self-service.
Three things that take a report outside the safe harbour.
- Do not test projects you do not own. A project of your own, or a test account you created, is yours to probe; another customer’s is not.
- Do not run scans that degrade service. Volume that harms availability is not research.
- Do not attempt social engineering of staff or customers.
These limits are part of the safe harbour below. Research that breaks them is outside what we can authorise, and we cannot promise not to act on it.
Good-faith research, on these conditions.
If you act in good faith and follow this policy, we consider your research authorised for the purposes of the Computer Misuse Act 1990, we will not take legal action against you for it, and for that research only we waive the parts of our Terms of Service that would otherwise forbid it. To qualify, you must:
- make a good-faith effort to avoid privacy violations and service disruption;
- only access, modify or destroy data belonging to yourself or to test accounts;
- give us at least 90 days to investigate and remediate before public disclosure, or less only if we agree in writing;
- not engage in social engineering of staff or customers.
This safe harbour does not cover actions that break these conditions, the limits above or the law, and we cannot authorise testing of anyone else’s services or waive anyone else’s rights. We decide, acting reasonably, whether research followed this policy. We may change this policy; the version published when you did the research applies. Any reward or public credit is at our discretion, and we credit reporters only with their permission.
The same facts, in the file a scanner reads.
A copy of this page cannot be current forever, so the machine-readable file carries an expiry date.
The platform publishes the contact, the URL of this page as its policy, and that expiry at /.well-known/security.txt, in the RFC 9116 format. The file’s fields, exactly as it serves them:
- Contact
- mailto:security@sylphx.com
- Expires
- 2027-03-13T00:00:00.000Z
- Preferred-Languages
- en
- Canonical
- https://sylphx.com/.well-known/security.txt
- Policy
- https://sylphx.com/security/disclosure
Material changes are announced in the changelog, and the version date under the heading above moves with them. If a change is not in either place, treat it as not announced.