Security and data

What purchasing and security reviews ask, answered from how Spitfire works.

Does test data reach us?

No. The controller, runners, database and results run on your servers; target addresses, responses, connection details and reports are not sent out. The only request Spitfire makes outside is a daily look at the signed release list on spitfire.tr, turned off with SPITFIRE_UPDATE_CHECK=off.

How is the license checked?

Offline. The key is signed with Ed25519 and carries its limits; the installation verifies the signature itself and asks no server. It works in air-gapped environments too.

How are secrets stored?

Connection passwords, tokens, client certificate keys, SMTP/LDAP passwords and webhook secrets are encrypted in the database with AES-256-GCM and never shown by the API again; if the server address changes, the secret is asked for again. Secrets never go into test definitions, and a password inside a URL is refused. User passwords are stored with argon2id.

Who signs in, and what can they do?

Single sign-on (OpenID Connect + PKCE; Entra ID, Okta, Google, Keycloak) or LDAP / Active Directory; the admin role and groups map from the identity provider, and password sign-in can be left to admins only. Sessions use rotating refresh tokens (reuse drops the whole session) and have an absolute lifetime: 24 hours with SSO, 30 days with a password. Users see only their groups' tests; running is a separate permission. CI uses API tokens tied to a user.

Audit log

Changes to tests, connections, users, permissions, schedules and integrations, sign-ins, run starts and stops, data-write approvals and report shares are recorded with who, when and from where. The log is append-only: a database trigger refuses updates and deletes; only the retention period you set removes entries older than 30 days, and that removal is recorded too. It exports as CSV.

Keeping production data safe

SQL and MongoDB writes, dangerous Redis commands and HTTP requests that change data are flagged; no run starts until each step is approved, and the approval is audited and asked for again on every run.

Runners and the network

Remote runners dial out to the controller: no inbound ports. The connection is TLS with the controller's key pinned; runners join with a registration key that can be revoked. Updates are signed: a runner does not run a new release before verifying its Ed25519 signature, and the installer bundle is checked with SHA-256.

Stored data and retention

You set how long per-second results, run logs, error samples, runs and the audit log are kept. Error samples mask tokens in the address, never keep cookies and hold only the first 2 KB of a body; for tests whose responses must never be stored they are turned off entirely.