Legal
Security
How ShadowDB keeps untrusted migration SQL away from your data, our infrastructure and other customers.
Draft · This document is under legal review and is not yet in effect. Text in [BRACKETS] is still to be filled in.
01Every run in its own sandbox
Each run gets a fresh virtual machine that is destroyed afterwards and never reused. The sandbox has no network interface, so SQL inside it cannot reach the internet or our control plane.
PostgreSQL in the sandbox has no untrusted procedural languages, only allowlisted extensions, and no rights to run server programs or read server files.
02Results we don't take on trust
What the sandbox reports is validated and size-limited, and the verdict is recomputed by the control plane. Static checks run again outside the sandbox, so a run can't hide a finding.
03Tenant isolation
Every organisation's data is separated in the database with row-level security, and stored files are keyed by organisation. People outside an organisation can't tell its projects exist.
04Encryption and retention
Traffic uses TLS 1.2 or newer. The database and object storage are encrypted at rest. Raw migration bundles are deleted when a run finishes, and deleted organisations are purged after 30 days.
05GitHub access
The GitHub App asks only for the permissions it needs to read migration files and post checks. Webhooks are signature-verified and de-duplicated.
06Reporting a vulnerability
Email [SECURITY EMAIL] with the details and steps to reproduce. We aim to acknowledge reports within [2 business days]. Please don't access other customers' data or degrade the service while testing. [SAFE HARBOUR / BUG BOUNTY TERMS]