Security

What the server does, and what it does not.

This page describes the current build, including its limits.

Access

Sign-in

GitHub and Google sign-in use PKCE (S256) and a single-use state value bound to a browser cookie. Only a verified email is accepted. A returning member is matched by their provider account. By default a new sign-in admits only an invited email; an operator can instead admit listed email domains to one workspace as viewers, or open sign-up so each new email gets a workspace of its own.

With no provider configured, sign-in by email alone is a local convenience, not authentication. The server refuses to listen beyond loopback in that mode unless explicitly told to.

Sessions

A session ends after 2 hours unused and 12 hours after sign-in, by default; both are configurable. Session tokens and ingest keys are stored only as SHA-256 digests, and a key's secret is shown once.

Every form is protected by a double-submit CSRF token and SameSite=Lax cookies. Members can end their own sessions everywhere; admins can end a member's.

Roles

Viewer, analyst and admin, per workspace. Exporting evidence needs analyst; viewers cannot export. Managing members, keys, workspace export and deletion needs admin. Any route not listed in the role table requires admin.

Workspace isolation

Every page resolves its data from the signed-in member's workspace. An ID that belongs to another workspace answers “not found”, the same as an ID that does not exist.

Evidence integrity

Original captures

New imports keep the exact original bytes alongside the parsed data, scoped to the workspace, with their digests recorded in provenance.

When an investigation is marked verified, and whenever a verified investigation is shown or exported, the server rereads the retained source bytes, checks their SHA-256 and derives the comparison again. A missing, changed or synthetic source leaves the investigation inconclusive. This check is part of investigation verification only; comparisons and campaigns record provenance without it.

Bundles

An exported bundle carries a SHA-256 checksum over its canonical JSON, the stored digests of its recipe and results, and source provenance. Export refuses evidence whose stored recipe or results no longer match their digests.

graphsignal-server evidence verify rechecks a bundle offline: its checksum, and that the embedded data matches its digests and any verdict it states. A valid bundle is an internally consistent export. That alone does not mean its investigation was verified or that performance improved, and the check does not read the source captures.

Records and data handling

Audit log

Changes and exports made through the workspace are recorded with time, actor, action and detail. If an export’s record cannot be written, the export is not sent; a change whose record fails still stands, but the request reports failure and the server logs it for the operator to reconcile. Only admins read their workspace's log. Audit records are kept for 180 days by default.

Export and deletion

Admins can export the workspace as one JSON-lines file; key, session and invite digests are left out. Deleting a workspace suspends it at once and removes it after a grace period, 7 days by default, during which the operator can reinstate it.

Backups

The server can snapshot its database on a schedule to a directory or a Cloud Storage bucket. On restore, a snapshot is used only if its bytes match the SHA-256 in its manifest and it passes SQLite’s integrity check.

Browser protections

Pages are served with a Content Security Policy that runs scripts only from the server itself and forbids framing, plus nosniff, X-Frame-Options: DENY and Referrer-Policy: no-referrer. HSTS is sent when the server is configured for HTTPS: with secure cookies or an https external URL.

Current limits

Bundles are not signed. The offline check detects a changed bundle. It does not prove who made it, and a writer with database access could replace both the bytes and the digests.
No encryption at rest by the server. Data is stored in SQLite; use encrypted storage underneath it.
No built-in TLS. Run the server behind a TLS-terminating proxy, or on loopback.
No SAML or enterprise SSO. GitHub and Google are the supported providers.
No compliance certifications. Kernelwake makes no SOC 2, ISO 27001 or similar claim.
Single writer. One server instance writes at a time; there is no multi-region deployment.
Not yet production ready. An independent review and hosted qualification are still pending.