Disclosure

If you have found a security issue, we want to hear about it.

security@saved.sh

Encrypted mail is welcome if you prefer; say so in a first message and we will exchange keys.

What to include

A report we can act on in one pass, rather than three rounds of questions:

• What you found, in a sentence.
• How to reproduce it, with the exact requests, commands or steps.
• What it lets an attacker do, and what access they would need to start.
• Where you were testing: a workspace ID, an approximate timestamp, and the source IP if you have it, so we can find it in our own logs.

A working proof of concept is welcome. A scanner's raw output, on its own, usually is not.

What we will do

If we disagree that something is a vulnerability, we will say so and explain why, rather than letting the thread go quiet.

Scope

In scope: saved.sh and its subdomains, our API, the dashboard, the CLI, the local worker, and the published container images.

Out of scope, because reports on these consume time without improving anyone's security:

• Findings that require a compromised worker host. That host is outside the threat model by design.
• Missing hardening headers or TLS configuration with no demonstrated impact.
• Rate limiting on unauthenticated endpoints, absent a concrete attack.
• Social engineering of our staff or our customers.
• Reports generated entirely by an automated scanner, with no analysis.
• Vulnerabilities in third-party services we depend on. Report those to their owners; tell us too if they affect us.

Already known and documented, so please do not spend your time on them:

• lock_for is application-level rather than storage-level object lock. Documented.
• Encryption is optional and unenforced. Documented.
• Machine credential revocation is bounded by a validation cache TTL. Documented.

We list these because a good-faith researcher deserves to know what we already know.

Testing safely

Please test against your own workspace, on data you own.

Do not run denial-of-service or load tests against our infrastructure. If you believe you have found a resource-exhaustion issue, describe the mechanism and we will test it ourselves.

Our commitment to you

If you follow this policy, act in good faith, and give us reasonable time to fix what you found before publishing:

• We will not pursue legal action against you, or ask anyone else to.
• We will credit you by name when the fix ships, if you want the credit and are happy to be named.
• We will not ask you to sign anything in order to report.

Disclosure timing

We aim to ship a fix before any public write-up, and we would like to coordinate the timing with you. If a fix is taking longer than it should, tell us, and we would rather agree a date than have the conversation stall.

If a vulnerability is being actively exploited, we will move faster and will tell affected customers directly rather than waiting on a fix.

If you are a customer reporting an incident

If you believe your own workspace has been compromised, that is a different message and does not need a security researcher's framing. Write to security@saved.sh with the workspace and what you have seen, and say "incident" in the subject line.

Useful first steps while you wait:

1. Rotate any API keys and worker credentials you are unsure about.
2. Check the audit log for artifact.download_url_issued, api_key.created and worker.token_rotated entries you cannot account for.
3. Rotate source credentials for any backup whose artifacts may have been read.
4. If your private key may be exposed, read what to do next.

Next