Vulnerability Disclosure Policy
Version 0.2 · Pending legal review
Our commitment
If you think you have found a security vulnerability in anything we make or run, we want to hear about it.
We will work with you to confirm it, fix it, and disclose it responsibly. This policy says how to report, what we commit to in return, and what is in scope.
Scope
In scope — the things we actually build and run:
- The SureRedact desktop application (macOS and Windows), current version and the previous major version.
- SurePrepare, its desktop application and the helper components we publish for customer deployment. You would test against your own deployment, not ours.
- The website at
surematters.com. - Our release-signing infrastructure — the Ed25519 signing of licence files and detector bundles, and the Authenticode signing of Windows builds.
Out of scope:
- Third-party services we use. They are listed in our sub-processor list. Report to the vendor directly and copy us at security@surematters.com so we know.
- Your own configuration of a helper you have deployed into your own cloud — for example an IAM misconfiguration on your side. Follow your own incident process; we will advise if a default in our published image should change.
- Social engineering against us, and physical attacks.
- Denial-of-service testing. Please do not.
- Issues already public or already known to us. We will tell you if your report is a duplicate.
A note on what we do not run. We do not currently operate a telemetry service, a licence-verification service, an automatic update service, or a customer portal. If you find a host that appears to be one of ours offering those, that is itself worth reporting — it is not us.
We will add to this scope as we ship things. The version and date at the top tell you how current this list is.
How to report
Send your report to security@surematters.com. We acknowledge within 1 working day, UK business hours; reports arriving outside those hours are acknowledged the next working day.
We do not currently publish a PGP key. If your finding is sensitive enough that you do not want it in plain email, say so in a short message with no detail and we will arrange a secure channel with you before you send anything.
Please include:
- What the vulnerability is and where it lives.
- How to reproduce it — the smallest reproducer you can manage.
- What you think the impact is, and the worst case.
- Any proof-of-concept, screenshots or logs that help.
- Your name, real or pseudonymous, how you would like to be credited, and how to reach you.
What we commit to
- Acknowledgement within 1 working day.
- Initial triage within 5 working days, with a preliminary severity rating.
- Status updates at least every 14 days while we are working on it.
- Coordinated disclosure. We agree a date with you before we publish. The default is 90 days from a confirmed report — shorter if something is being actively exploited, longer if the fix is structurally hard and you agree.
- Credit in the advisory, if you want it. You may also stay anonymous.
- No legal action for good-faith research that follows this policy. We will not sue you, threaten to sue you, or report you to law enforcement for interacting with our systems as described here.
We do not currently run a bug bounty. We may later; this policy is not conditional on it.
In return, we ask that you:
- do not access more data than you need to demonstrate the issue;
- do not modify, delete or take customer data — if you reach any by accident, stop and tell us;
- do not disclose publicly before we have agreed a date;
- do not exploit beyond confirming the finding — no persistence, no lateral movement.
Severity
| Level | Examples |
|---|---|
| Critical | Remote code execution on the desktop application without operator interaction; compromise of a release-signing key |
| High | A signature-verification bypass that could let altered software appear to be ours; disclosure of data held on a system we operate |
| Medium | Cross-site scripting on our website; a logic flaw in licence validation; a denial-of-service condition on a non-customer-facing endpoint |
| Low | Verbose errors exposing version numbers; missing security headers on non-sensitive endpoints; minor disclosure with no clear path to exploitation |
| Informational | Hardening suggestions with nothing immediately exploitable |
On the High row: in normal operation your documents are not stored on any system we operate, so the disclosure category there covers our own operational data rather than yours.
Communication
security@surematters.com
is monitored Monday to Friday, UK business hours. For something
critical outside those hours, put URGENT in the subject
line — it is routed differently.
We are a very small company. You will deal with a person, not a queue, and we will tell you plainly if something is going to take time. We will not move a security discussion into a public channel without your agreement.
Public disclosure
When a fix ships:
- We publish an advisory covering what it was, which versions are affected, which version fixes it, the severity, any workaround, and credit to you if you want it.
- We publish the fixed release with a changelog identifying it as a security fix, so you can tell it apart from an ordinary update. The products do not update themselves, so a security fix is only useful if we make it obvious you should take it.
- For Critical and High severity we email current customers within 1 working day of the advisory, saying what to do.
What we do not promise
- No fix-time guarantee. Critical issues typically ship within 14 days; anything else depends on what it is.
- No bug bounty, currently.
- No commitment to investigate out-of-scope reports, though we will acknowledge them.
- No legal protection for research that breaches the conditions above.
Changes to this policy
Material changes are notified on our website within 10 working days and recorded below. Editorial changes are made in place and dated.
Change history
| Date | Version | Change |
|---|---|---|
| 2026-05-09 | v0.1 | Initial draft. |
| 2026-08-12 | v0.2 | Correction. Scope listed a customer portal, a licence-verification service, a telemetry ingestion service and an update-distribution service. We do not run any of them, so the policy invited researchers to test hosts that do not exist. Scope now lists what we actually build and run, with a note that a host claiming to be one of those is worth reporting precisely because it is not us. The reporting section carried a placeholder for a PGP key at a path that serves nothing; it now says plainly that we do not publish one and how to send something sensitive anyway. A public researchers page and a security-advisory archive were both named as though they existed; neither does, and the references are removed. The disclosure route no longer refers to update channels that do not exist. |
Questions
Anything about this policy: security@surematters.com.
Drafted with AI assistance and reviewed by a named person, per our AI Policy.