This page is written for the person who has to sign off on Ligara, not for the person who wants to buy it. It sets out the isolation model, the encryption position, the third parties involved, and a register of outstanding hardening work that we publish rather than hide.
Most of the attack surface a reviewer expects to find isn't there, because most of the processing isn't on a server.
The practical consequence. The place customer data rests is the database. That is where the isolation and encryption guarantees below apply, and it is the thing worth reviewing carefully.
// Client (your browser or the desktop shell) Plate-file parsing // never uploaded to be parsed Curve fitting, statistics // local RDKit chemistry via WASM // local Charting, 3D viewers // local // Your machine (local process, loopback only) ADMET model // structures stay on device // Network — TLS 1.2+ only Auth // sign-in Postgres // your records, under RLS Storage // files you attach // Static code assets from pinned CDNs // (code only — never customer data)
The application makes no plaintext connections to the backend: all traffic to authentication, the database and storage goes over HTTPS. Transport versions and cipher selection are properties of the managed platform rather than controls Ligara implements, and the platform serves TLS 1.2 or above.
Data in the managed database is encrypted at rest with AES-256, applied by the platform to the underlying storage volumes and to automated backups. Storage-encryption keys are held by the platform provider; Ligara does not handle raw keys.
Ligara does not implement zero-knowledge client-side encryption of scientific records, and that is a deliberate design decision rather than an omission. See below.
The product's value depends on the database being able to read structured data. Server-side filtering and multi-tenant queries under Row-Level Security, cross-organisation read-only sharing, and saved analyses that recompute from live data all require it. Zero-knowledge encryption would make those records opaque to the database and break every one of them.
Confidentiality is instead enforced by transport encryption, at-rest encryption and database-level tenant isolation. If your requirement is genuinely that the host cannot read the data, the right answer for you is a self-hosted deployment where you are the host — which is available on enterprise engagements — rather than a claim from us that we cannot read a database we operate.
Isolation is enforced in the database by PostgreSQL Row-Level Security, not by the application. Client-side query scoping exists, but it is defence-in-depth and interface behaviour — it is not the boundary.
The property that matters: a modified or compromised client still cannot read or write another tenant's rows, because every query executes under the caller's authenticated identity against the database's own policies.
| Column | Meaning |
|---|---|
owner_id |
The individual user who created the row. |
org_id |
The organisation, or lab, the row belongs to. |
project_id |
The shared project the row is filed under, where applicable. |
Operations that must not be client-decidable are implemented as privileged database functions rather than as table permissions the client holds. Joining a lab, approving or rejecting a membership, changing someone's role, revealing an invite code, creating or joining a project, resolving a submission to the Master DB and writing the mutation log all run this way.
Membership rows carry no client update or delete permission at all, and the invite code is not readable by ordinary members. Assay runs cannot be hard-deleted by a client at all, and their soft-deleted rows are excluded inside the database policy. On the other soft-deleted tables that exclusion is currently applied by the application rather than by the policy — see the audit trail section, which states the scope precisely.
The tenancy boundary was hardened in a dedicated pass, and the migrations that did it are identifiable in the codebase. We will walk a reviewer through them under NDA.
The one path by which data crosses an organisational boundary, and the controls on it.
A mirror exists only because an administrator at the source organisation approved a specific request. There is no implicit or default sharing.
Mirrored rows cannot be edited or deleted by the receiving organisation. The mirror table itself carries no direct client write permission.
One approval covers the requesting organisation, so access is administered at the organisation level rather than per person.
Mirrored data is labelled with its originating lab everywhere it appears, so nobody mistakes a partner's result for their own.
The source organisation can revoke at any time. Revoked grants are retained as history rather than deleted, so the record of who had access when survives.
Request, approval and revocation are privileged database functions, and the read path is governed by policy. The interface controls are convenience, not the boundary.
Defence-in-depth above the database boundary.
No multi-factor authentication today, and no breached-password screening. Both depend on a backend tier we have not yet moved to. If MFA is a hard requirement for your organisation, Ligara does not meet it at present.
No single sign-on. SAML, OIDC and directory integration are not built.
Log writes are initiated by the application at each mutation point, not by the database. Three consequences, and none of them is hidden in a footnote:
Database triggers that write the log automatically, and policy-level exclusion on the remaining tables, are planned work on the Part 11 track. Until they ship, treat this as a useful operational audit trail and not as a compliance control or a tamper-proof record.
There is also no recovery interface for soft-deleted records yet. The data is recoverable, but recovering it today means us doing it for you.
The complete list, because a short list is the point.
| Party | Purpose | Customer data handled |
|---|---|---|
| Managed database platform | PostgreSQL, authentication, file storage | All hosted customer data |
| Prediction models (ADMET, discovery preview) | Property prediction and candidate generation | None — run locally on your machine |
| Static asset CDNs | Serving pinned, integrity-checked library code | None — code only |
Residency follows the region chosen for the database. On enterprise engagements the database can be a dedicated instance in a region you specify, or deployed into infrastructure you control — in which case the residency question is answered by your own estate rather than by us.
No other third party processes your scientific data. The application sends no usage telemetry, carries no advertising or analytics instrumentation, and does not use your data to train any model.
We maintain this register and publish it. A vendor with a visible list of what it is still fixing is telling you more than a vendor with a page of badges.
| Item | Status | Why it is still open |
|---|---|---|
| Multi-factor authentication and breached-password screening | Planned | Requires moving to a backend tier that offers them |
Remove unsafe-eval from the script policy
|
Planned | Needs the chemistry WebAssembly bundle rebuilt without dynamic execution; the build flag is already committed |
Remove unsafe-inline from the script policy
|
Planned | Tied to migrating the remaining legacy inline event handlers |
| Database-side triggers writing the mutation log automatically | Planned | Part 11 track; today the application initiates each write |
| Per-launch token between the app and its local sidecars | Planned | Origin restriction closes the browser-driven threat today |
| Alerting on error-rate spikes | Planned | Needs a scheduler on a paid tier |
| Cross-organisation compound matching on a stable identifier rather than name | Planned | Correctness hardening on the mirror path |
| Recovery interface for soft-deleted records | Planned | Data is recoverable in the database; there is no self-service route to it |
| Policy-level exclusion of soft-deleted rows on all tables | Planned | Enforced in the policy for assay runs; applied by the application on the other soft-deleted tables |
| Removing the remaining client delete permissions | Planned | Assay runs can no longer be hard-deleted by a client; a record owner can still delete some other record types outright |
| Independent penetration test | Not done | No third-party security assessment has been carried out |
Ligara holds no compliance certification or attestation of any kind. If your procurement process requires one today, we are not a candidate yet. We would rather you learn that here than three weeks into an evaluation.
What exists: an append-only mutation log written through a privileged database function that fixes the acting user server-side, and soft-delete across the scientific tables.
What does not: the electronic-signature workflow, database-enforced immutability, signed-record export and a validation pack. Ligara is not Part 11 compliant and is not validated.
No audit has been performed and no report exists. SOC 2 is substantially process and evidence work rather than a feature, and it has not begun.
We can complete a security questionnaire and describe the controls on this page in writing. That is not the same thing as an attestation, and we will not present it as one.
No SAML, no OIDC, no directory integration, and no multi-factor authentication. Access is email and password with mandatory address verification.
For an organisation that mandates SSO, this is usually the blocking item rather than anything scientific.
On GDPR and similar regimes: Ligara is a tool you would use as a data controller, and nothing on this page is legal advice about your obligations. The data-processing agreement and privacy notice are being drafted with legal advice — see legal for what exists and what does not. There is no scenario in which we tell you Ligara is "GDPR certified", because no such certification exists.
If you have found something, we want to hear about it privately first, and we will not argue with you about whether it counts.
Please report suspected security issues privately rather than in public. Include reproduction steps and your view of the impact. We will acknowledge the report and work a fix on a priority basis, and we will tell you when it ships.
Send reports to info@ligara.org. The machine-readable version of this is at /.well-known/security.txt, per RFC 9116.
There is no bug-bounty programme and no paid reward, which we would rather say up front than leave you to discover.
Send them over. We will answer the ones we can answer and tell you plainly where the answer is "not yet".