Security & compliance
A summary of CardBoard’s security posture for compliance reviewers, security teams, and procurement.
Hosting and infrastructure
Section titled “Hosting and infrastructure”CardBoard runs on Heroku, with file storage on Amazon S3 (via ActiveStorage). Production and staging are separate environments.
Encryption
Section titled “Encryption”- In transit: TLS is enforced on all connections (
force_ssl); Heroku negotiates TLS 1.2+. - At rest: file storage on S3 (bucket-level encryption per environment); application secrets via Rails encrypted credentials.
Authentication
Section titled “Authentication”| Method | Used for |
|---|---|
| Password (Devise) | Standard email/password sign-in |
| Google OAuth | Social sign-in |
| Microsoft Entra ID (Azure AD) | Social / enterprise sign-in |
| SAML SSO | Enterprise single sign-on (per-domain) |
| HTTP Basic (email + API key) | REST API |
OAuth 2.0 (mcp scope) | MCP endpoint for AI agents |
Authorization
Section titled “Authorization”Layered permissions: organization-level plus board-level, enforced server-side via policy classes, on a least-privilege model.
Audit logging
Section titled “Audit logging”CardBoard records change events (card created / updated / status changed) and system events through two audit models. Every tracker write is attributed to the member who made it, in both your tracker’s audit log and CardBoard’s.
Data and recovery
Section titled “Data and recovery”Data is stored in the US region and is exportable (CSV). Backup and recovery details are available on request.