Security model

Proofline holds unreleased critical vulnerabilities, so its security model is built like infrastructure, not like a typical SaaS app.

#Encryption

• Per-case keys. Each Casefile has its own AES-256-GCM data key, stored wrapped by a platform key-encryption key. This is envelope encryption; in production, the wrapping key lives in a KMS.
• What's encrypted: the report body, every Proofline event payload (reasoning, messages, rule citations), and every evidence file.
• Bound ciphertexts: each ciphertext is tied to its record with authenticated data, so it can't be swapped between cases or events.

#Integrity

• The Proofline is hash-chained over the ciphertext, so an auditor can verify integrity without being able to read vulnerability details.
• Every decision is also a typed record linked to its event (the Decision ledger). One rebuttal per decision is enforced by a database constraint.
• Privileged access is audited. Case views by project members and mediators, evidence downloads, sign-ins, and wallet and team changes go to a hash-chained audit log.

#Access

• Per-case authorization. Only the researcher, members of the owning organization, and the assigned mediator can open a Casefile. There's no global admin read path.
• Viewers are read-only. Only owners, admins and triagers can make decisions.
• Evidence is decrypted per request and served only as a download, never rendered in the browser.

#Accounts

• Two-factor authentication (TOTP) is mandatory for project accounts and recommended for everyone.
• Sessions: the cookie holds a random token and the database stores only its hash. You can see and revoke every session in settings.
• Wallet ownership is proven by signing a single-use, expiring challenge, and sign-in is rate-limited.
• Identity verification results are stored as outcomes only. Documents and biometrics stay with the provider.

#Notifications

Notifications and emails say that something needs attention in Casefile CF-XXXX. They never contain vulnerability titles, details or reasoning.

#Web hardening

A Content-Security-Policy, HSTS, frame-ancestors 'none', nosniff, and a strict referrer policy. Configuration is validated at boot: a production deployment refuses to start with demo sign-in, a development KYC provider, or missing secrets.

#Reporting a vulnerability in Proofline

Proofline will run its own bounty program on the platform at launch. Until it's live, contact the Proofline team directly and don't test against production.