Security you can inspect, not just trust
Scribase is an application cloud — Postgres, auth, storage, realtime, and functions. Its security model leans on Postgres itself, a least-privilege operator plane, and recovery that ships evidence. Below is what that means in practice, and an honest account of what is and is not yet certified.
How your data is protected
Each practice reflects a real property of the platform, not an aspiration.
Row-level security, linted for cost
Access control lives in Postgres row-level security policies, and Scribase lints those policies for cost so tenant isolation stays both correct and fast. Security that is too slow to keep on tends to get turned off.
Encryption in transit and at rest
Traffic to the data-plane and control APIs is served over TLS, and stored data and backups are encrypted at rest. Keys and secrets are managed by the platform, never checked into your code.
Least-privilege operator model
The control plane runs on a least-privilege role model and never requires cluster-admin inside your workloads, whether you run on managed Scribase or bring-your-own-cloud.
Secret-scrubbed preview branches
Preview environments are scrubbed of production secrets and swept on a TTL when a pull request closes, so a stale branch never becomes a credential leak.
Auditable, idempotent operations
Every mutation runs through a durable executor, carries an idempotency key, and returns an operation ID, so changes are safe to retry and traceable to who or what made them.
Verified restore with evidence
Recovery is proven, not assumed: each verified restore ships row-count parity, SHA-256 checksums, policy parity, and a real login proof.
Portability as a safeguard
scribase export produces a checksummed bundle that boots elsewhere. Being able to leave with your whole stack is itself a security property — you are never trapped with a single provider.
Where we stand, stated plainly
Overclaiming compliance is the one security lie that matters most, so anything not yet certified is labeled as such.
| Control | Status | Notes |
|---|---|---|
| Data encryption (in transit + at rest) | Available | TLS for all API traffic; encrypted storage and backups. |
| Row-level security & policy-cost linting | Available | Enforced in Postgres; policies linted for cost. |
| Data export & portability | Available | Full-stack export with a checksummed manifest. |
| Verified restore evidence | Available | Row-count, checksum, and policy parity with a login proof. |
| SOC 2 | Planned | Not yet certified. Stated plainly rather than implied. |
| HIPAA | Planned | Not yet supported. Stated plainly rather than implied. |
Responsible disclosure
Found a vulnerability? Report it privately and we will acknowledge and work the fix with you.
Security questions
Is Scribase SOC 2 certified?
Not yet. We state that plainly rather than implying a certification we do not hold. The controls a SOC 2 audit examines — encryption, least-privilege access, auditable operations, and verified recovery — are already in place; the formal attestation is planned.
How is tenant data isolated?
Access control lives in Postgres row-level security policies, so isolation is enforced by the database itself rather than by application code alone. Scribase additionally lints those policies for cost so isolation stays fast enough to keep switched on.
What happens to secrets in preview branches?
Preview environments are scrubbed of production secrets and swept on a TTL when a pull request closes, so a stale branch never becomes a credential leak.
How do I know a backup will actually restore?
Recovery is proven, not assumed. Each verified restore ships row-count parity, SHA-256 checksums, policy parity, and a real login proof — evidence you can inspect, not a green checkmark you have to trust.
How do I report a vulnerability?
Email security@scribase.com. Report it privately and we will acknowledge and work the fix with you.