Security

Draft: not legal advice, pending review by counsel. This page is a working draft, not a published security page. Placeholders in square brackets must be replaced and the whole document reviewed by qualified counsel before launch.

1. Scope

This page describes controls that the current codebase and deployment documentation support. It is an engineering overview, not a certification or a warranty. We do not claim any third-party security certification. [Confirm any future audit or certification claims before adding them.]

2. Encryption in transit

Public traffic to the applications and the API is served over HTTPS. The backend reverse proxy terminates TLS and is configured with HSTS. Managed services used for the database, authentication and file storage are reached over HTTPS.

[Confirm the TLS configuration and certificate renewal process for the production domains.]

3. Access control and row-level security

The database uses Postgres row-level security so that queries are limited to the rows a signed-in user is allowed to see. Company membership and role checks are enforced in the database policies and in the API layer.

Server-side processes use a service-role key that can bypass row-level security. That key is kept server-side only, is never shipped to the browser, and is not placed in the code-execution sandbox. Compromise of a server process would therefore bypass row-level security, which is why host and secret access are restricted. [Confirm the production secret-management and rotation process.]

4. Files, tokens and sessions

Resumes and recordings are stored in private buckets. Access is intended to use short-lived signed URLs, and access to recordings is logged. Session and invitation tokens are treated as sensitive; where tokens are stored, they are hashed rather than kept in plain text.

[Confirm the final bucket policies, signed-URL lifetimes and token storage details.]

5. Isolated code execution

Coding modules run submitted code in an isolated sandbox. The sandbox is kept off the public network, has no shared volumes with the rest of the stack, and enforces resource limits. Network access, extra files, compiler options, command-line arguments and callbacks are disabled for submissions. The sandbox container is treated as hostile-capable.

The sandbox database keeps submitted code and is not covered by the application retention workflow. Host access to it is restricted. [Confirm the production sandbox configuration and its retention handling.]

6. Rate limits, logging and monitoring

The API applies rate limits, single-use request identifiers and body-size limits. Security-relevant events and grading changes are recorded in audit logs. Service logs are capped and structured, and secrets are not intentionally written to logs.

[Confirm monitoring, alerting and log-retention arrangements, including who has access.]

7. Backups and recovery

Database backups and restore procedures exist for the workflow database. Managed database backups depend on the plan in use. Restore procedures are documented and are intended to be tested. [Confirm backup coverage, frequency, retention and the date of the last restore test.]

8. Incident response

We maintain an internal runbook for operational incidents and secret rotation. [Confirm the customer notification process and any contractual timelines.]

To report a suspected vulnerability, contact [security contact email]. Please do not test against other customers' data or run disruptive tests.

9. Limits

No system is perfectly secure. This page describes controls that are implemented or intended in the current codebase; it does not promise that a control will prevent every incident. [Have counsel review this page alongside the terms and privacy policy.]

This draft is not legal advice.