Reporting a Vulnerability
Last updated September 24, 2026
Report anything you find to security@katami.io. This policy is also published at /.well-known/security.txt, per RFC 9116.
In scope
- The Katami app for macOS — the current release and the current beta.
- katami.io and bespokebyte.io.
- The License Manager —
licenses.bespokebyte.io. - Our API —
api.bespokebyte.ioandmodels.bespokebyte.io.
Out of scope
- Services we use but do not run — Paddle's checkout and payment pages, Apple, Resend and Linear. Please report to them directly; Paddle, for one, runs its own programme.
- Findings with no demonstrated impact — missing headers or "best practices", outdated libraries, or scanner output without a working proof of concept.
- Denial of service and volumetric testing of any kind.
- Social engineering of us, our customers, or anyone else, and physical attacks.
- Email configuration reports (SPF, DKIM, DMARC) without a demonstrated spoof that reaches an inbox.
- Account enumeration through sign-in. Our sign-in says whether an address holds a license, deliberately, so a customer who typed the wrong address is told so.
Please
- Test only against your own license, your own Macs and your own data.
- Stop as soon as you reach data that is not yours, do not keep it, and tell us.
- Give us a reasonable chance to fix the issue before telling anyone else.
- Include enough detail for us to reproduce it — steps, a proof of concept, and the versions involved.
Please do not
- Run automated scanners or brute-forcing tools against production.
- Access, change or delete data that is not yours.
- Degrade the service for anyone else.
Safe harbour
If you act in good faith under this policy, we consider your research authorised, we will not pursue or support legal action against you, and we will not ask your employer or anyone else to. If a third party takes action against you over research that followed this policy, we will make clear that it was authorised.
If you are unsure whether something is in scope, ask first. A question costs nothing, and this protection is easier to give in advance than to argue about afterwards.
What to expect from us
| Acknowledgement | within 3 working days |
| An assessment, with our view of severity | within 10 working days |
| Progress updates | at least every 14 days while it is open |
| Fix, or an explanation of why not | as fast as the severity warrants |
| Disclosure | coordinated with you, normally within 90 days |
We are a very small team, so those are commitments about communication rather than a promise that every fix is instant. If we are going to miss one, we will tell you before it slips rather than afterwards.
Recognition
We do not run a paid bug-bounty programme. We credit every reporter who wants to be named, in the release notes of the fix, and we say plainly what they found.