How we back it up
Alignment isn't a slide. These are the mechanisms running in production and in our build pipeline today.
425+ row-level security policies across 225+ tables gate rows at PostgreSQL itself (not just in application code), so an app-layer bug is far less likely to cross tenants, because the database enforces isolation independently of the application.
Type-checking, 10,000+ automated tests (as of August 2026), linting, and a production build must pass before code ships. A dedicated test asserts that no data-changing route is reachable without authentication.
Static analysis (OWASP Top Ten), secret scanning, dependency vulnerability audits, and a software bill of materials run automatically, and re-run weekly against newly disclosed vulnerabilities.
Cryptographic operations are centralized in one internal module that uses only FIPS-approved algorithms, with an automated guardrail that blocks weak algorithms from entering the codebase.
Security-relevant actions are recorded through a privileged server-side path that ordinary user sessions cannot write to directly, designed to be tamper-evident and retained on a defined schedule.
A self-run OWASP ZAP scan returned zero critical or high findings. A scoped penetration test by an independent firm is on our roadmap. This complements our internal security-audit cycles.
The audit trail is stricter than that description suggests. In the lab-records ledger, each row's hash is taken over the previous row's hash plus its own contents, and the trigger that writes it takes a transaction-scoped advisory lock before it reads the tail. Without that lock, two results released in the same instant would chain off the same predecessor, and the chain would stop verifying for a reason that had nothing to do with tampering.
Questions, or need our control mappings?
We maintain detailed control-to-evidence mappings (NIST 800-53/171, CSF 2.0, ASVS, SSDF) for security reviews. Security researchers can report issues through our responsible disclosure policy.