Found a security issue? Tell us, safely.
If you have found a vulnerability in Solves, we want to hear from you. This page sets out what is in scope, how to report it, and the good-faith safe harbour that protects researchers who follow it. We are a small, founder-led UK team at pilot stage, and we treat security reports as a priority.
Machine-readable pointer at /.well-known/security.txt, following RFC 9116.
Why this policy exists
A clear, safe route to tell us something is wrong
Researchers and curious users find things that automated checks and an internal team will miss. We would much rather hear about a weakness from you, privately and early, than read about it later. This policy is our open invitation to do that, and our promise about how we will behave when you do.
We are honest about where we are. Solves is at pilot stage, so we do not yet run a paid bug bounty and we will not claim certifications we do not hold. What we offer is a real human reading your report, a prompt response, and a fix when the report stands up. Please read this policy before testing, because the safe harbour only applies while you are inside it.
How to report
Two routes, one destination
There are two ways to reach the right place, and both lead to the same security contact. Pick whichever is easier.
- Use the contact route: send us the details on the contact page and mark it clearly as a security report, so it is routed to the security contact rather than general support.
- Read the machine-readable pointer: the security.txt file at /.well-known/security.txt follows the RFC 9116 convention and names the canonical contact and this policy, so a scanner or researcher can find the channel without guessing.
Please include enough for us to reproduce the issue: a clear description, the steps to trigger it, the affected URL or feature, and any proof-of-concept. Do not include other people's personal data, real customer content or live secrets; if you saw such data while testing, tell us, but do not copy or keep it.
What is in scope
Where we want your attention
In scope is the Solves application and the assets we run and control. If you are unsure whether something is in scope, ask before you test it.
- The Solves web application and its public marketing site on our own domains.
- Authentication, session handling, CSRF protection and access control between organisations, brands and tickets.
- Tenant isolation: any way to read, write or affect another organisation's data, or to widen access past the actor's scope.
- Anywhere encrypted-at-rest data, blind-indexed search fields or metadata-only logs might leak plaintext, addresses, secrets or payloads.
- Webhook and mailbox-ingestion endpoints, and billing flows handled in our own application.
We are especially interested in issues that break tenant isolation, expose customer content, bypass the public-reply versus private-note separation, send a reply as the wrong brand, or defeat CSRF on a state-changing request.
Out of scope
What we will usually not action
These are common low-impact findings or things we do not control. We may still read them, but they generally fall outside the safe harbour and a fix.
Third-party services
Issues in services we do not run, such as the payment, email, DNS or hosting providers. Report those to the relevant provider; our sub-processors page lists who handles what.
Best-practice nitpicks
Missing headers, cookie flags or SPF and DMARC records with no demonstrated exploit, and scanner output with no working proof-of-concept.
Spam and social
Spam, phishing of our staff, social engineering and physical attacks: anything that relies on tricking a person rather than a flaw in the software.
Denial of service
Volumetric denial-of-service, brute-force or load testing. Please do not stress-test the service; describe the weakness and let us verify it safely.
Self-inflicted issues
Findings that need a compromised device, an outdated browser, or an attacker who already has the victim's credentials.
Theoretical reports
Version banners, clickjacking on pages with no sensitive action, and issues with no realistic path to impacting a real user or their data.
Safe harbour
Good-faith research is authorised research
We do not want the people helping us to worry about legal risk. If you make a genuine, good-faith effort to follow this policy, we will treat your testing as authorised and we will not bring or support legal action against you over it.
In plain English: act in good faith, only access data and accounts that are your own or that we have set up for small teams, do not breach anyone's privacy, do not destroy or modify data that is not yours, and do not disrupt the service for others. Stop once you have demonstrated a problem, and give us a fair chance to fix it first. This safe harbour covers your interactions with us only; it does not authorise breaking the law or acting against third parties. If you are unsure whether something is allowed, ask first.
What happens next
From your report to a fix
We acknowledge
We aim to confirm we have received your report within two UK business days, so you are not left wondering whether it reached a person. These are targets for a small pilot-stage team, not a guarantee.
We assess
We aim to give an initial assessment within five UK business days: whether we can reproduce the issue, our view of its severity, and likely next steps. A serious, credible report jumps the queue.
We fix and coordinate
We work on a fix, keep you updated, and agree a sensible timeline for any public disclosure together. We ask that you hold off publishing until a fix is in place or we have agreed a date.
Coordinated disclosure
A fair window before anything is made public
We believe in coordinated disclosure: you tell us privately, we fix it, and then, if you wish, the issue is shared publicly. The point is to protect the people using Solves while a fix is being made.
We ask that you give us a reasonable, good-faith window to fix a confirmed issue before disclosing it elsewhere. What is reasonable depends on severity, so we will agree a timeline with you rather than impose a fixed number we cannot yet defend at pilot stage. If you would like credit, we are glad to acknowledge researchers who report valid issues once we have a thanks list; if you would rather stay anonymous, that is your choice.
Honest about pilot stage
We are not claiming a bug bounty, a certification or a finished assurance programme we do not have. What we offer today is a clear channel, a good-faith safe harbour, and a real human who will read your report and act on it. As Solves grows, this policy will grow with it.
FAQ
Responsible disclosure questions
Do you offer a bug bounty or pay for reports?
Not at pilot stage. We do not run a paid bug bounty and cannot promise a monetary reward. What we offer is a prompt, honest response, a fix when a report stands up, and credit on a thanks list once we have one, if you would like it. We would rather be straight about that now than imply a payout we are not set up to make.
How quickly will you respond to a report?
We aim to acknowledge a report within two UK business days and to give an initial assessment within five. These are intentions, not a contractual guarantee, because we are a small founder-led team at pilot stage. A serious, credible report jumps the queue.
Will I get in trouble for reporting a vulnerability?
No, provided you act in good faith and stay within this policy: follow the rules here, access only your own test data, avoid privacy breaches and disruption, and give us a fair chance to fix the issue before going public. Do that, and we will treat your work as authorised research and will not pursue legal action over it.
Where is the machine-readable policy?
There is a security.txt file at /.well-known/security.txt, following the RFC 9116 convention. It points to the contact route for security reports and to this policy page, so a scanner or a researcher can find the right channel without guessing.
Is Solves penetration tested or certified?
We are at pilot stage and we will not claim certifications we do not hold. What we can describe truthfully is the design: support content is encrypted at rest with per-organisation keys, access is restricted to authorised users, and our logs carry metadata only, never message bodies, addresses or payloads. Independent testing and assurance are where we are heading, not something we claim today.
Found something? We want to know
Report it through the contact route and mark it as a security report, or read the security.txt pointer first. Good-faith research is welcome and protected here.