Spitfire

Security Statement

Last updated: 8 October 2026

This statement explains how Spitfire handles your data, your network and access, for security and procurement reviews. Each point describes how the product behaves today.

1Your data stays in your network

  • The controller, the Postgres database and the runners run on your servers: your own data center, private cloud, or AWS/Azure VPC.
  • Test definitions, data files, connection details and results are never sent to Spitfire or to third parties.
  • The license is verified offline; Spitfire also works in air-gapped environments.
  • The only outbound call the product makes on its own is reading the signed release list on spitfire.tr once a day. SPITFIRE_UPDATE_CHECK=off turns it off.
  • Notifications (Slack, Teams, e-mail, SMS, webhooks, OTLP export) go only to the addresses an admin configures.
  • Mobile notifications (when an admin turns them on) reach the phone through Spitfire's notification server and Google, but each is encrypted on the controller with a key only the receiving phone can open: nothing in between can read it. A notification holds the test name, the result and the status; no measurements, target addresses or data.

2Network: runners dial out

  • Remote runners dial out to the controller: no inbound port is opened on the load-generator servers. The controller's runner port (8471) must be reachable.
  • This connection uses TLS, and the runner verifies the controller's key against a SHA-256 pin. A server in between cannot present that key, which protects against man-in-the-middle attacks.
  • Runners join your installation with a revocable registration token.
  • Runners on the same host or cluster as the controller use a separate internal-only port (8475). In Kubernetes, a NetworkPolicy lets only the installation's own runner pods reach it.

3Production protection

  • SQL and MongoDB writes, dangerous Redis commands and HTTP requests that change data are flagged in a test automatically.
  • A test containing them does not start until the person starting it has seen the list of flagged operations and explicitly confirmed it.
  • The confirmation is asked for again on every run and written to the audit log.

4Database access: query suggestions from the schema

  • Query suggestions from the schema read a database's catalog from your own Spitfire server. Nothing read is sent outside your servers; no external or AI service is used, and Spitfire's maker does not connect to your database.
  • Only installation admins can use it; the server refuses everyone else's requests. Before the first read the admin accepts a consent text: who consented, when, from which IP and browser, for which connection, with which text version and scope and which warnings were shown is stored and written to the audit log. A new consent is needed when the connection's address, user, SSH tunnel or production flag, the scope or the text changes.
  • Only the catalog is read (tables, columns, keys, indexes, row estimates), never table data; EXPLAIN does not run the queries. Real key values are read only with a separate consent, from a bounded sample, and stay on the Spitfire server; the logs and the audit log get only their count, never the values.
  • A dedicated, least-privilege read-only database user is recommended, with a ready script for each database. The connected user's privileges are checked; a superuser/admin account or a connection marked production brings a red warning and an extra confirmation. Using a production database is strongly discouraged.
  • In the SSH tunnel of SQL connections the server's host key is always verified: you confirm its fingerprint, and if a different key shows up later the connection is refused before anything is sent. The SSH password and key are stored encrypted; only installation admins can change the tunnel.

5Failed request samples

  • The run page keeps a few samples of failed requests per step and outcome: the target address, the error, the failed check, a few response headers and the first 2 KB of the body.
  • Query parameters in the address that look like secrets (token, key, password, …) are masked; cookies are never kept.
  • The response body is not masked. For tests whose responses must never be stored, sampling can be turned off entirely.

6Identity, permissions and audit

  • Single sign-on. OpenID Connect (Entra ID, Okta, Google, Keycloak), SAML 2.0 (ADFS, Entra ID, Okta, Keycloak and others) and LDAP / Active Directory. With SAML, sign-in always starts at Spitfire: the response's signature, audience and validity are checked, and responses Spitfire did not ask for are refused. Roles and groups are mapped from the identity provider; password sign-in can be limited to admins. SSO users have no local password; local passwords are stored with argon2id.
  • SCIM 2.0 (Enterprise). Okta, Entra ID and other identity providers create, update and deactivate users and manage group memberships. A deactivated user's sessions, mobile sign-in and API tokens stop working at once; a deleted account stays disabled with its tests and audit trail. The last enabled admin cannot be deactivated; every change is audited.
  • Sessions. Kept with rotating refresh tokens; the absolute lifetime is 24 hours with SSO and 30 days with a password.
  • Permissions. Only admins create and edit tests, connections and users. Users see only their groups' tests; running a test is a separate right per group. Reports can be shared with people without an account through a link that expires in 1–90 days.
  • Append-only audit log. Who did what, when and from where: tests, connections, users, permissions, schedules, integrations, sign-ins, run start/stop, write confirmations and report shares. Entries can only be added: a database trigger refuses updates and deletes. Only the retention period your organization sets (at least 30 days) removes older entries, and that removal is recorded too. It exports as CSV.
  • Streaming to a SIEM (Enterprise). Audit entries go to your SIEM as they are recorded, over syslog (RFC 5424; TLS, TCP or UDP) or a signed webhook (X-Spitfire-Signature): in order and at least once. When the target cannot be reached it retries from where it stopped, and nothing is lost on a controller restart. Every event is hash-chained to the previous one, so the receiver can verify that nothing was left out or changed.
  • Encrypted secrets. Connection passwords, tokens, client-certificate keys, SMTP/LDAP passwords and webhook secrets are encrypted with AES-256-GCM in the database; once saved, the API never shows them again.
  • Signed updates. Releases are signed with Ed25519; runners verify the signature before running a new release.
  • Forgotten passwords. "Forgot password" never tells whether an account exists. With e-mail set up, a one-time link valid for 30 minutes goes out (only its hash is stored); otherwise an admin sets a temporary password the user must change at the first sign-in. Every password change ends all sessions of the account and is written to the audit log.

Regulation and compliance

Spitfire supports the controls your KVKK, BDDK and GDPR processes call for (data not leaving the organization, auditability, access control); assessing compliance is your organization's own process.