Vulnerability Disclosure Policy

We want Cusp to be safe for the people who rely on it, and we welcome reports from security researchers. This policy explains how to report a vulnerability and what you can expect from us. It's linked from our security.txt.

How to reportCopy Anchor Link

Email security@cusp.run. If you'd like to encrypt your report, ask us for our PGP key [OR: use the key at /.well-known/pgp-key.txt, once published].

Please include:

• what the vulnerability is and what an attacker could do with it;
• the product and version (desktop app, CLI, daemon, iOS app, web app, cloud API, Hub) and your platform;
• steps to reproduce, with a proof of concept if you have one; and
• how you'd like to be credited, if at all.

You can write in English or Russian.

What we promiseCopy Anchor Link

• We'll acknowledge your report within 3 working days.
• We'll give you an initial assessment within 10 working days, and keep you updated at least every 14 days until it's resolved.
• We'll aim to fix critical issues within 30 days, and others within 90 days.
• We'll tell you when it's fixed and agree a disclosure date with you. We'd normally expect public disclosure no later than 90 days after your report, or sooner once a fix is released.
• With your permission, we'll credit you in our release notes and on an acknowledgements page.

We don't currently run a paid bug bounty.

ScopeCopy Anchor Link

In scope:

• the Cusp desktop app, CLI and daemon, editor extensions, GitHub Action and SDKs, current release;
• the iOS app, current App Store release;
• app.cusp.run, api.cusp.run, hub.cusp.run and cusp.run;
• the hosted-artifacts domain, where the issue lets one user's content affect another user or our systems; and
• the Hub's signing, transparency log, scanning and revocation, and the update channel.

Particularly interesting: escaping the sandbox or the permission system, getting the agent to act without approval through content it reads, reading another customer's data, bypassing the invite gate or billing limits, and anything that exposes provider keys.

Out of scope:

• third-party extensions on the Hub (report those to the publisher, and tell us at hub@cusp.run if one is malicious);
• model providers, Railway, Stripe, GitHub, Apple and other third-party services (report to them);
• denial-of-service or volumetric testing, spam, social engineering, and physical attacks;
• findings that need a compromised device, a jailbroken phone, or an attacker who already controls the user's account or workspace configuration;
• the model saying something wrong or unpleasant, unless it leads to a security impact; and
• missing best-practice headers, banner disclosure or rate limits without a demonstrated impact.

Rules for testingCopy Anchor Link

• Only test against accounts and data you own or have permission to use. Ask us for a test workspace if you need one.
• Don't access, change or delete other people's data. If you come across it by accident, stop, don't keep a copy, and tell us.
• Don't degrade the service for others. No automated scanning that generates heavy load.
• Don't use what you find for anything beyond showing the issue, and don't leave anything behind (such as backdoors).
• Give us reasonable time to fix the issue before you disclose it publicly.

Safe harbourCopy Anchor Link

If you make a good-faith effort to follow this policy:

• we consider your research authorised, and we won't start legal action or report you to law enforcement for it, including under the Computer Misuse Act 1990 or equivalent laws, or for breaching our terms in the course of research;
• we'll waive the parts of our Terms of Service and Acceptable Use Policy that would otherwise prohibit your testing, to the extent needed for research within this policy; and
• if a third party brings legal action against you for research that followed this policy, we'll make it known that your actions were authorised by us.

We can't authorise testing of systems we don't own. If you're unsure whether something is in scope, ask us first.