Security

This page describes the current state of security at Zerokit in plain language. It is not a substitute for the formal Data Processing Addendum, but it gives prospective and existing customers a useful baseline of what we do and how we operate.

Identity and access

• Authentication — email + password (with industry-standard hashing), GitHub OAuth, and WebAuthn passkeys. We support TOTP-based two-factor authentication with backup codes.
• Sessions — short-lived signed session cookies with secure flags; revocation propagates within minutes via our session cache. Password change revokes all other active sessions by default.
• API keys — scoped per organization, with permission presets (send-only, read-only, full-access), prefix identifiers for safe public logging, and easy rotation from the dashboard.
• Staff access — production access is gated by SSO with hardware-key MFA, granted on a least-privilege basis, and audit-logged.

Encryption

• In transit — TLS 1.2+ everywhere; HSTS on customer-facing domains; modern cipher suites only.
• At rest — primary database storage (Turso / libSQL) is encrypted at the storage layer; secrets and OAuth tokens are additionally encrypted at the application layer using AES-256-GCM with keys held outside the database tier.
• Email content — kept only as long as needed to deliver, retry, and emit events; encrypted in transit between components and from Zerokit to upstream SES.

Network and platform

• The API runs on Cloudflare's edge network with DDoS protection, WAF rules, and rate-limit-aware routing.
• The dashboard is hosted on Vercel with HTTPS-only delivery and managed CDN caching.
• Email is delivered through Amazon SES in the EU region. SPF, DKIM, and DMARC are mandatory for every sending domain and verified before any send is permitted.
• Inbound webhooks (e.g., SNS event notifications) are signature-verified before processing.

Software development

• Source code lives in a private Git repository with branch protection, mandatory review for production branches, and CI checks (typecheck, tests) on every change.
• Dependencies are pinned and reviewed; we run automated vulnerability alerts and patch high-severity findings on a short cadence.
• Database migrations are reviewed manually before merge and applied through Drizzle Kit with a versioned journal.

Monitoring and logging

• We collect application logs, request traces, and email-event telemetry. Personally identifying fields are minimised in logs and redacted from error reports.
• Anomaly alerts fire on traffic spikes, abnormal complaint / bounce rates, authentication anomalies, and failed delivery patterns.
• Access to logs is restricted to engineering staff with a business need, and access events are themselves logged.

Backups and disaster recovery

• The primary database is backed up automatically by the storage provider (Turso); we periodically verify restore from a known backup.
• Stateless components are immutable and re-deployable on demand; recovery time after a region-level outage is bounded by the upstream provider's SLO.

Incident response

We maintain a written incident-response runbook with on-call coverage. When a confirmed security incident affects customer data, we:

1. Contain the issue (rotate credentials, isolate affected components, throttle abusing traffic).
2. Notify affected customers without undue delay and at the latest within 72 hours of confirming the incident, per Article 33 GDPR.
3. Coordinate with sub-processors and authorities as required by law.
4. Conduct a written post-incident review and publish what we've learned (with sensitive details redacted).

Responsible disclosure

Security researchers are encouraged to report vulnerabilities to [email protected]. We commit to:

• Acknowledge receipt within two business days.
• Triage and provide an initial assessment within seven business days.
• Keep you informed throughout remediation.
• Refrain from pursuing legal action against good-faith research that respects the scope below.

In-scope: production assets at zerokit.co, the public API at api.zerokit.co, and our public marketing surfaces.

Out-of-scope: denial-of-service tests, social-engineering of staff or customers, physical attacks, and any activity that risks customer data or sending reputation. Please do not run automated scanners that produce significant traffic without contacting us first.

Subprocessors and shared responsibility

Security is a shared responsibility with our sub-processors. The current list and the regions they operate in is at Sub-processors. We continuously review their security posture and require contractual commitments equivalent to ours.

Contact

Security questions: [email protected]. Privacy and data-protection questions: [email protected].