Security
We say “AES-256-GCM envelope encryption”, not “military-grade”. Here's the actual mechanism — and its limits.
- Envelope encryption: Per-project 256-bit DEKs (AES-256-GCM), wrapped by a KEK derived via PBKDF2-HMAC-SHA256, 600k iterations, from your master secret.
- Password hashing: PBKDF2-HMAC-SHA256, 600k iterations, per-user salts. Unknown-user logins burn the same work (no timing oracle).
- Bearer tokens: HMAC-signed with a key HKDF-derived from the master secret (never the data KEK). Scopes, project/env bindings, expiry; revocation-checked.
- Login rate limiting: 30 attempts per 60s per IP (429 on excess), plus proxy-level throttling recommended.
- RBAC, fail-closed: owner/admin/developer/viewer/ci scoped to project + environment; denials are audit-logged.
- Tamper-evident audit: Hash-chained, append-only event log. Export it to immutable storage — the chain detects tampering, it doesn't prevent it.
- No secret logging: The server never logs secret values; structured logs carry metadata only.
Known limits (we'd rather you read them here)
- The master secret is a single root of trust (env var / 0600 file) — no HSM/KMS yet.
- Plaintext values exist in server memory during encrypt/decrypt (unavoidable; no swap-zeroing in v1).
- TLS is the reverse proxy's job — the server speaks HTTP on loopback.
Questions or a vulnerability to report? Contact us — security reports go to the top of the queue.
