Security & Compliance
How secr protects your secrets at rest, in transit, and in use — mapped to SOC 2 Trust Service Criteria.
Encryption Architecture
Every secret stored in secr goes through a two-layer encryption model designed so that a database breach alone cannot expose plaintext values.
Layer 1 — Project Envelope Key
Each project has a unique AES-256-GCM key generated at creation. This key encrypts all secret values within the project. A random 12-byte IV is generated per encryption operation — no IV is ever reused.
Layer 2 — KMS-Wrapped Key
The project envelope key is itself encrypted by an external KMS provider (AWS KMS, GCP Cloud KMS, or Azure Key Vault). The plaintext envelope key never touches disk — it is unwrapped in memory for the duration of the request.
Key Rotation
Project keys can be rotated at any time via the CLI (secr rotate-key) or dashboard. Rotation generates a new envelope key and re-encrypts every secret in the project — previous key material is destroyed.
Access Control
secr enforces role-based access control at the organization level with three roles, each scoped to the organization's projects.
| Role | Read | Write | Manage Team | Billing & Delete |
|---|---|---|---|---|
| Viewer | Yes | — | — | — |
| Admin | Yes | Yes | Yes | — |
| Owner | Yes | Yes | Yes | Yes |
Sessions: Database-backed session tokens (secr_sess_*) with server-side revocation. CLI tokens support configurable expiry (default 90 days).
CSRF Protection: All cookie-authenticated mutations require an X-Requested-With: secr header, preventing cross-site request forgery.
Rate Limiting: API endpoints are rate-limited per-IP with a Redis-backed store (falls back to in-memory for single-instance deployments).
Audit Logging
Every mutation to secrets, projects, and membership is recorded in an immutable audit log with the acting user, timestamp, action, and affected resource.
Events logged: secret.created, secret.updated, secret.deleted, secret.bulk_delete, project.created, project.deleted, key.rotated, member.invited, member.removed, ownership.transferred.
Retention: Audit log retention is plan-gated. Free plans retain 7 days; paid plans retain 90+ days. Logs reference the user, project, and environment via foreign keys with SET NULL on delete so logs survive resource deletion.
Dashboard: Audit logs are viewable in the dashboard by admins and owners, with filtering by action type and date range.
Transport Security
TLS: All API traffic is served over HTTPS. The CLI and SDKs refuse plaintext HTTP connections in production.
Cookies: Session cookies use Secure; HttpOnly; SameSite=Lax flags. The Secure flag is enforced in production environments.
Body Limit: A global 1 MB body size limit is enforced to prevent abuse.
Webhooks: Webhook payloads are signed with HMAC-SHA256, allowing receivers to verify authenticity. Delivery attempts are logged with status codes.
SOC 2 Control Mapping
The table below maps secr's security controls to SOC 2 Trust Service Criteria. This is a self-assessment — formal SOC 2 Type II certification is on our roadmap.
| Criteria | Control | Implementation |
|---|---|---|
| CC6.1 | Encryption at rest | AES-256-GCM envelope encryption with KMS-wrapped keys (AWS, GCP, Azure) |
| CC6.1 | Encryption in transit | TLS-only API; Secure/HttpOnly/SameSite cookies |
| CC6.1 | Key management | External KMS; per-project keys; on-demand rotation with re-encryption |
| CC6.2 | Authentication | DB-backed sessions; bcrypt password hashing; email verification; password reset with session revocation |
| CC6.3 | Authorization | RBAC (owner/admin/viewer); per-org scoping; plan-gated resource limits |
| CC7.1 | Monitoring | Immutable audit log for all mutations; request metrics tracking; webhook delivery logging |
| CC7.2 | Anomaly detection | Per-IP rate limiting (Redis-backed); body size limits; CSRF protection |
| CC8.1 | Change management | Secret version history with timestamps; key rotation audit trail; project config export/import |
| CC6.6 | Secret scanning | 20+ regex patterns; pre-commit hook (secr guard); CI-compatible JSON output |
| CC6.7 | Data disposal | Org deletion cascades all data; secret deletion is immediate and irreversible; Stripe subscription cancelled on org delete |
Incident Response
If a project key is suspected to be compromised, the recommended response is:
- Rotate the project key immediately (
secr rotate-key). This generates a new envelope key and re-encrypts all secrets — the old key is destroyed. - Review the audit log for unauthorized access patterns in the dashboard.
- Revoke any suspicious CLI tokens via the dashboard token management page.
- Rotate the underlying secret values themselves (database passwords, API keys, etc.) since envelope re-encryption does not change the plaintext values.
Responsible Disclosure
If you discover a security vulnerability in secr, please report it responsibly. Email security@secr.dev with a description of the issue. We aim to acknowledge reports within 48 hours and provide a fix timeline within 5 business days.