Security

Security as an invariant

Security at Score isn’t a marketing checkbox. The commitments below are structural — enforced in code, gated in CI, and audited in the database. We’d rather refuse to ship a feature than ship one that breaks tenant isolation or weakens our audit trail.

Multi-tenant Row Level Security

Every Score tenant lives in shared Postgres tables protected by Row Level Security policies that scope reads and writes to the current tenant’s organization. A cross-tenant fuzz suite runs in CI to verify no query path leaks a row across the boundary — if it fails, the build doesn’t ship.

Rails against AI hallucinations

Score is built so that an AI hallucination cannot affect your score, your decision, or your data. The score itself is computed by a deterministic 15-metric rule engine — there is no language model in the scoring decision. The only place an AI is involved is the initial extraction of structured numbers from your bank statements, and that JSON output is validated against a strict schema before any rule runs. Every extraction call is independently audit-logged so a hallucinated extraction is detectable via the audit chain plus a deterministic re-score. We’d rather slow down a feature than ship one that lets a model invent something about your business.

SOC 2-grade audit chain

Every privileged action — admin operations, score recalculations, data exports, billing changes — writes to a hash-chained audit log. Each row references the previous row’s hash, so tampering with history is detectable. We’re building toward SOC 2 Type II; until certification, we run the controls the certification expects.

Six CI security rules

Every pull request runs through six required security gates before it can merge:

1. Gitleaks — secret scanning against history + diff.
2. Push protection — GitHub-side secret push blocking, enforced on the org.
3. Dependency audit — high/critical advisories block the build.
4. Cross-tenant fuzz — probes every API route for RLS leakage.
5. Static analysis — typecheck + lint + security-linter rules.
6. License scan — blocks copyleft or unknown licenses from entering the build.

Encryption in transit and at rest

Traffic between users and Score is encrypted with TLS 1.2 or higher. Customer data stored in the application database (Neon Postgres) is encrypted at rest using AES-256-grade encryption managed by the database provider. Uploaded artifacts (bank statements, supporting documents) are stored in Azure Blob Storage with server-side encryption and access scoped by short-lived signed URLs — never via long-lived public links.

Authentication architecture

Production authentication is built on Microsoft Entra External ID (formerly Azure AD B2C) with MFA available to every tenant and required for Rate Tracker staff accounts. Session cookies are HTTP-only, Secure, SameSite, and signed. Local development uses a separate, lower-privilege HMAC-based identity adapter that is structurally incapable of issuing production tokens. The adapter architecture means we can layer SSO providers per tenant without touching application code.

Credentials and secrets

Production secrets live in a managed secret store (Azure Key Vault, fronted by an in-app gateway with PII redaction). Application code never sees raw credentials — it requests scoped tokens through the gateway. Local development uses separate, lower-privilege credentials.

Incident response

We maintain a written incident response runbook covering detection, triage, containment, eradication, and recovery. In the event of a confirmed security incident that affects customer data, we will notify affected customers without undue delay — targeting notification within 72 hours of confirmed impact, and faster where law or contract requires. Our Sentry observability layer (with strict PII scrubbing) feeds the detection side of this loop.

Backups and disaster recovery

The application database runs on a managed provider with continuous point-in-time recovery and automated daily snapshots. Blob storage uses zone-redundant or geo-redundant replication depending on container. Recovery objectives (RPO ≤ 24 hours, RTO ≤ 8 hours for V1; tighter targets in roadmap) and the full DR plan will be enumerated alongside the SOC 2 audit package.

Compliance roadmap

Score is being engineered against SOC 2 Type II controls from day one, even ahead of formal certification. Penetration testing, third-party security review, and a vendor data-processing addendum are all on the V1.1 roadmap. As we cross each milestone we’ll surface it here with the corresponding evidence (report, attestation date, scope).

Reporting a vulnerability

If you believe you’ve found a security issue, please email security@ratetracker.io. We’ll acknowledge within one business day. Our formal coordinated disclosure policy will be published here before V1 launch.