UnityFreak Security Whitepaper

This paper describes how UnityFreak protects customer data today: what is implemented, what is only partly implemented, and what is not implemented. It is a self-description by the people who operate the platform. It is not an audit report, a penetration-test result or a certification, and it makes no claim of SOC 2, ISO 27001 or CSA STAR status.

Every substantive statement carries a claim label such as C-ENC-01 and an evidence class. The classes are defined in the next section. A reviewer-only claim trace, held privately, maps each label to dated source code or to deployment and drill evidence. Where we could not gather evidence, the statement says so.

How to read the evidence classes

• Code: the behaviour is implemented in the platform source at the reviewed commit. This does not by itself prove that the production deployment matches the source.
• Deployed: the behaviour is code-verified and is also supported by dated deployment or drill evidence from the production environment.
• Partial: implemented, with known gaps that are listed next to the claim.
• Not implemented: the control does not exist. It is listed so that nobody assumes otherwise.
• Unverified: we believe this holds but have not gathered evidence for it.

Document control: version 1.0.1, dated 2026-10-02, status draft. The source was checked against the platform source as of commit 5815075eb and against the compliance readiness table dated 2026-09-22. The status stays draft until an independent reviewer has traced every claim.

Architecture and data flows

UnityFreak is a project-management and version-control platform. Customers use it through a web application, a public API, a git service reachable over HTTPS and SSH, and desktop and command-line clients.

• The platform is built from a web application, an API service, a git hosting service, a real-time collaboration service and background workers. Evidence class: C-ARC-01 · Code
• Application data lives in a PostgreSQL database. Short-lived state, rate limiting and job queues use Redis. Evidence class: C-ARC-02 · Code
• Git repositories are stored on a dedicated block-storage volume. Large-file (LFS) objects and uploads are stored in object storage. Evidence class: C-ARC-03 · Deployed
• Browsers talk to the web application, which calls the API. Git clients talk to the git service directly. The API calls the database, the queue and the third-party services listed on the public subprocessor page. Evidence class: C-ARC-04 · Code
• The production environment currently runs on a single server. There is no automatic failover and no multi-region redundancy. Evidence class: C-ARC-05 · Deployed
• Customer-enabled integrations (for example chat, incident and design tools) send data only to the destination the customer connects. Evidence class: C-ARC-06 · Code

Encryption at rest

Encryption at rest is scoped, not blanket. The accurate picture, per data class:

• Selected secrets are encrypted in the application with AES-256-GCM, using a random initialization vector and an authentication tag per value. The platform refuses to encrypt when its key is missing, so there is no silent plaintext fallback on write. Evidence class: C-ENC-01 · Code
• The encrypted secret fields we verified are single sign-on client secrets, data-loss-prevention webhook secrets and stored integration credentials. Evidence class: C-ENC-02 · Code
• Values that do not carry the encrypted prefix are read back as legacy plaintext. Old values written before encryption was introduced would therefore remain readable as plaintext until they are rewritten. Evidence class: C-ENC-03 · Partial
• Passwords are stored as bcrypt hashes and SCIM provisioning tokens as one-way SHA-256 hashes. Neither is reversible. Evidence class: C-ENC-04 · Code
• Customer content such as tasks, comments, documents and messages is stored in PostgreSQL and is not encrypted by the application. We have not gathered evidence that the database storage itself is encrypted at rest. Do not read this paper as saying it is. Evidence class: C-ENC-05 · Unverified
• Git repositories are stored on a dedicated storage volume. We have not yet verified at-rest encryption for that volume or for the database. Evidence class: C-ENC-06 · Unverified
• Large-file objects sit in Cloudflare object storage, which encrypts stored objects at rest by default. This is the provider's control. Evidence class: C-ENC-07 · Deployed
• Backups are produced with restic, which always encrypts its repositories. Evidence class: C-ENC-08 · Deployed

Encryption in transit

• The web application sends an HTTP Strict Transport Security header on every response, with a two-year lifetime, subdomain coverage and the preload flag. Evidence class: C-TLS-01 · Code
• Git is served over HTTPS and SSH. Evidence class: C-TLS-02 · Code
• Certificate management and TLS termination for the production hosts are configured outside the application source. This review did not independently verify the production TLS configuration, protocol versions or certificate renewal. Evidence class: C-TLS-03 · Unverified

Key management and rotation

• The application encryption key is a 256-bit value supplied to the service through its environment. The service validates its format and will not encrypt without it. Evidence class: C-KEY-01 · Code
• Ciphertext does not record a key identifier, and the service holds one active key. Rotating the key therefore means re-encrypting stored values by hand. There is no automated rotation, no managed key service and no hardware security module. Evidence class: C-KEY-02 · Not implemented
• The backup encryption passphrase is generated and held by the operators outside the source repository. A documented custody and rotation procedure was not reviewed. Evidence class: C-KEY-03 · Unverified
• Sessions can be revoked on demand, and refresh tokens rotate with reuse detection that revokes the whole session family. Evidence class: C-KEY-04 · Code

Backup and restore

• Repositories and a full database dump are backed up nightly into an encrypted restic repository. Snapshots are kept for 30 daily, 12 weekly and 12 monthly generations, and a one percent data sample is verified each night. Evidence class: C-BAK-01 · Deployed
• Large-file objects are synchronised weekly to a separate backup bucket and the copy is checked after each run. Evidence class: C-BAK-02 · Deployed
• Backup freshness is monitored and an alert fires when the nightly success marker is older than about a day. The alert path was exercised deliberately. Evidence class: C-BAK-03 · Deployed
• Recovery point objective is up to about 24 hours for repositories and the database, and up to about 7 days for large-file objects. These are measured design facts, not contractual commitments. Evidence class: C-BAK-04 · Code
• A full restore drill was run once, on 2026-07-13, on a separate server with a small pre-launch dataset. It restored the repositories and the database and passed repository integrity checks, clone tests and row reconciliation. It has not been repeated, and restore time at production scale has not been measured. A configured backup is not the same as a proven restore, and only that one drill supports this claim. Evidence class: C-BAK-05 · Partial
• Recovery means provisioning a replacement server and restoring from backup. There is no live standby. Evidence class: C-BAK-06 · Deployed
• Point-in-time database recovery is not available. Evidence class: C-BAK-07 · Not implemented

Tenant isolation

• Customer separation is enforced in application code on each request, by checking organization and project membership and role permissions before data is returned or changed. Evidence class: C-ISO-01 · Code
• The database does not use row-level security policies, so isolation rests on the application checks and not on a second database-level barrier. Evidence class: C-ISO-02 · Code
• Six organization roles with fine-grained permissions are defined, and project access resolves custom-role permissions. Evidence class: C-ISO-03 · Code
• Authorization has known defects. The readiness table lists escalation and bypass paths in custom roles, and an export that bypasses some project permissions. Fixes for the defects found in the 2026-09-27 closeout review are in the source but the production deployment of those fixes is still pending. Evidence class: C-ISO-04 · Partial
• A systematic authorization review of the whole codebase and an independent penetration test have not been completed. Evidence class: C-ISO-05 · Not implemented

Audit logging

• Organization-level events such as sign-ins through single sign-on, provisioning changes, role changes and audit-log exports are written to an organization audit log. Evidence class: C-AUD-01 · Partial
• Audit rows are protected against modification by a database trigger. This guards against application bugs. It is not tamper-proof or write-once storage, and a database administrator could alter the data. Evidence class: C-AUD-02 · Code
• Audit data is archived to private object storage before it is deleted. The default retention is 400 days and the minimum configurable value is 180 days. Evidence class: C-AUD-03 · Code
• Logs can be exported as CSV or JSON, and can be streamed to a customer system by webhook. Failed deliveries after retries do not yet notify organization owners. Evidence class: C-AUD-04 · Partial
• Known gaps: some project mutations are not yet audited, and an offset-pagination defect can skip events in long exports. Evidence class: C-AUD-05 · Partial

Single sign-on and SCIM

• SAML and OpenID Connect single sign-on are supported. SAML assertions must be signed and are verified, and the OpenID Connect flow uses PKCE, a single-use state and a nonce. Evidence class: C-SSO-01 · Code
• Organization administrators can require single sign-on and verify ownership of an email domain. The 2026-09-27 closeout review found and fixed enforcement races in the source; those fixes await production deployment. Evidence class: C-SSO-02 · Partial
• A valid single sign-on session cannot yet refresh consistently, a known defect recorded in the readiness table. Evidence class: C-SSO-03 · Partial
• SCIM 2.0 provisioning is supported with a hashed token. Deprovisioning revokes the user's sessions. Evidence class: C-SSO-04 · Code
• Two-factor authentication (TOTP) is available. A whiteboard relay path does not yet enforce the second factor, a known defect recorded in the readiness table. Evidence class: C-SSO-05 · Partial

Retention, deletion and legal hold

• Organizations can configure a message-retention window for governed project conversations, and a scheduled job purges messages older than the window. Evidence class: C-RET-01 · Code
• A scheduled job applies retention to project-management content and checks legal holds before purging. Evidence class: C-RET-02 · Code
• Administrators can place legal holds at organization, project or user scope. Held content is preserved ahead of retention and deletion. The 2026-09-27 closeout review found a gap where task evidence could be purged under a narrower hold; the fix is in the source and awaits production deployment. Evidence class: C-RET-03 · Partial
• Deleting an account anonymises the profile (name, email, avatar and similar fields), releases the username, revokes sessions, API keys, linked sign-ins and SSH keys, blanks the password and blocks sign-in. The same steps run whether you delete the account yourself or an administrator processes your request; the administrator path used to do less, and the fix is in the source and awaits production deployment. Deletion is refused while a hold placed on that user is still in force. Neither path was found to erase content the user authored inside projects. Evidence class: C-RET-04 · Partial
• Backups keep deleted data until the snapshot that holds it ages out, which is up to about twelve months for current snapshots. Snapshots from earlier infrastructure are still retained with no expiry set. Evidence class: C-RET-05 · Code
• Customers can export their data. Organization exports are known to bypass some project-level permissions. Evidence class: C-RET-06 · Partial

Open items and what this paper does not claim

• No independent audit or certification exists. A third-party penetration test and a SOC 2 Type I assessment are planned, with no date set and no provider engaged.
• The items marked unverified or not implemented above are the ones an independent reviewer should examine first.
• This paper will be re-dated and re-versioned whenever a claim changes. It does not describe any control as effective merely because it is configured.