Trust Center
Security is not a feature.
It is the architecture.
DevSafe encrypts your code before it leaves your machine. Your keys never touch our servers. Your backups live in your own storage.
What we enforce
Security controls
Need to map these against your vendor questionnaire? Read the pre-filled SIG Lite with all 19 risk domains answered.
- AES-256 authenticated encryption
- Unique key per repository, never transmitted
- TLS 1.2 or higher to DevSafe infrastructure and storage providers.
- Encryption at rest on all infrastructure (Supabase)
- HTTPS enforced. No HTTP connections accepted.
- Streaming encryption for large repos. AES-NI hardware acceleration.
- Encrypted snapshots from git's internal structures, not filesystem copy
- Snapshot verification before encryption
- Parameterized queries on all database access.
- CORS locked to devsafe.com only
- Rate limiting on all API endpoints
- Input validation on every request
- Security headers (HSTS, CSP, X-Frame-Options)
- User-generated encryption keys. Never transmitted or stored by DevSafe.
- Email and password, magic link, or GitHub OAuth authentication. Optional TOTP multi-factor authentication. Passwords hashed by Supabase Auth, never accessible to DevSafe.
- API key authentication for programmatic access
- Principle of least privilege for all systems
- Role-based access (Owner, Member) for team plans
- DDoS protection via Cloudflare
- Web Application Firewall (WAF)
- Bot detection and blocking
- Immutable deployments with instant rollback
- Private networking between services
- Automated SSL certificate provisioning
- Every backup receipted with cryptographic verification proof
- Tamper-evident audit trail on all operations
- Backup integrity verified on restore
- Export all data anytime. No lock-in. Open backup format.
- Restore with standard tools: decrypt with your key, clone with git
- All systems use environment variables for secrets
- No customer data used for training. Ever.
- No third-party analytics tracking
- Incident response plan documented
- Sub-processor list published and maintained
- GDPR Data Processing Agreement available
Backup verification
Every backup DevSafe creates is cryptographically verified restorable. Not "probably fine." Provably intact.
After upload, DevSafe checks the GCM authentication tag and confirms the bundle is structurally valid and restorable. The receipt records that check.
The backup format is documented and open. You can restore without DevSafe. Decrypt with your key and restore with standard git tools. No vendor required.
Compliance status
Sub-processors
These are the third-party services that may process data on your behalf when you use DevSafe. This list is maintained per GDPR Article 28. We notify customers of changes.
| Provider | Purpose | Data Processed | Location |
|---|---|---|---|
| Cloudflare | Website hosting, DNS, DDoS protection, WAF, CDN, SSL/TLS | Request metadata (IP, headers). Not query content, no PII. | Global edge |
| Supabase | User authentication, account database | Email, usage metrics | US (EU option) |
| Stripe | Payment processing | Payment card details (DevSafe never sees card numbers) | US |
| Resend | Transactional email delivery | Email address, email content | US |
Your data stays yours
Your code and backups are not processed by any sub-processor. Encrypted backups go directly from your machine to your own storage bucket. DevSafe never has access to your encryption keys or your backup contents.
How we handle your data
Documents
Questions about security?
We respond within 24 hours.
For security-specific inquiries, responsible disclosure, or compliance document requests, contact the security team.