Trust

Security

Last reviewed 26 October 2026

A security product has one job: to be worth trusting with the list of what you are running. This page states what we do, in enough detail that you can check it, and what we do not do, so you are not surprised later.

What the agent sends

Package names and versions from your lockfile, runtime and framework versions, and the application token that identifies the workspace. That is the whole payload.

Never sent: source code, environment variables, secrets, database contents, host credentials, customer data. If you read the agent, you can verify this — it is Apache-2.0 and small enough to read in one sitting.

How credentials are handled

• Passwords: scrypt with a per-user random salt and a work factor tuned to about 100 ms; never logged, never emailed.
• Agent tokens: 32 bytes of entropy, stored only as SHA-256 hashes, displayed once at creation, revocable per application.
• Sessions: server-side records with revocation on sign-out; cookies are scoped to the console path, HttpOnly, Secure and SameSite.
• Two principals that can never be swapped: a browser session and a device token. Integration tests assert that a token cannot reach console routes and a session cannot reach agent ingest.

Tenant isolation

Every row in the control plane carries a tenant identifier and Postgres row-level security enforces it, so a bug in one query cannot leak another workspace’s findings. The application role cannot bypass those policies. Tests cover cross-tenant reads for rules, events and projects.

Transport and infrastructure

• TLS 1.2+ with HSTS; no plaintext listener except an ACME redirect.
• Content-Security-Policy on every page with no inline scripts. The console allows `script-src 'self'` only; the public marketing pages additionally allow one analytics origin (Sabilytics), which is never loaded inside the product.
• Rate limits on authentication and agent ingest at the edge.
• Nightly logical backups with an automatic check that the dump contains every row the live database has; 14-day retention.
• Deploys are gated on a health check, and CI runs the full test suite on three Python versions before anything can merge.

What we do not do

• We do not read your source code, and the agent cannot.
• We do not run your code, execute your builds, or hold your deploy keys.
• We do not sell data, and there are no advertising cookies or third-party analytics on the console.
• We are not SOC 2 certified or ISO 27001 certified. If you need either, say so — it changes what we can sell you, and we would rather tell you now.

Reporting a vulnerability

Mail [email protected] with the details and a way to reproduce it. We acknowledge within two working days, keep you updated, and will credit you if you want. Please do not test against other customers’ workspaces, run destructive payloads, or open a public issue before we have had a chance to fix it.

There is no paid bounty programme yet. When there is one, it will be on this page first.

If something goes wrong

We publish platform state at /status. If we become aware of a breach affecting your data we contact workspace owners directly, without undue delay, and within 48 hours at the latest. Our obligations to you as a processor are set out in the DPA.