Responsible Disclosure Policy

Draft for legal review. Keeta Workspace prepared this draft, and it has not yet been reviewed by counsel. Text in [square brackets] needs a decision from counsel. Remove this note when the document is published.

Last updated: [date of publication]

Keeping our customers' data safe matters to us. If you find a security vulnerability in Keeta Workspace, please tell us, and we will work with you to fix it.

How to report

Email [security@keeta.ai] with:

• what the vulnerability is and where it is (the address, the feature or the component);
• the steps to reproduce it, with a proof of concept if you have one;
• what an attacker could do with it.

Please don't include other people's personal data. [Counsel and security: confirm the address, and whether to publish a PGP key and a security.txt file.]

What we promise

• We will acknowledge your report within 3 business days, and keep you updated.
• We will not take legal action against you, or ask authorities to, for research done in good faith under this policy. We consider such research authorized, and will say so if a third party takes action against you for it.
• With your permission, we will credit you once the issue is fixed.
• [We do not currently run a paid bug bounty. / Counsel: decide on rewards.]

In scope

• app.keeta.ai and eu.app.keeta.ai, and their APIs
• keeta.ai
• The connect command and runner (the @keetanetwork/workspace package)
• The Workspace phone apps

The Keeta network has its own security programme; report network issues to it. Vulnerabilities in third-party services we use should go to their owners.

The rules

• Test only against accounts and organizations you own, or have the owner's permission to test.
• Don't access, change or delete other customers' data. If you reach data that isn't yours, stop, and tell us what you saw.
• Don't degrade the service: no denial-of-service, load testing, spam or automated scanning that generates heavy traffic.
• No social engineering of Keeta staff or customers, and no physical attacks.
• Give us reasonable time to fix the issue before you disclose it publicly, and agree the date with us. We aim to fix critical issues within 30 days.
• Follow the law.

Not usually accepted: missing security headers with no demonstrated impact, self-XSS, clickjacking on pages without sensitive actions, rate limiting on non-sensitive endpoints, reports from automated scanners without a working exploit, and issues needing a compromised device.