ferrlabs

Legal document

Security — FerrLabs

Last updated: May 1, 2026

This page is a living summary of the security controls in place across FerrLabs SaaS products. It complements the DPA (legal commitments) and the subprocessors page (third-party providers).

Identity and authentication

  • Passwords hashed with argon2id (OWASP-recommended parameters: memory ≥ 64 MiB, time ≥ 3 iterations, parallelism = 4).
  • Session JWTs are HMAC-signed, short-lived, transported as HTTP-only SameSite=Lax cookies in browsers and as Bearer tokens in the FerrFlow CLI.
  • Two-factor authentication (TOTP) [TBD — available / planned].
  • OAuth client model: each app (FerrVault, FerrTrack, FerrGrowth, FerrFleet admin, …) authenticates against the central IdP at auth.ferrlabs.com with its own client_id and registered redirect URIs.
  • Failed login rate-limiting: 5 failures → 60 s, 10 → 5 min, 20 → 1 h.

Data protection

  • In transit: TLS 1.3 only, modern cipher suites, HSTS enabled with preload.
  • At rest: storage-layer encryption on every persistent volume.
  • FerrVault secrets: additionally encrypted with per-vault AES-256-GCM keys derived from a server master key held outside the application database ([TBD — KMS / Vault]).
  • IP addresses persisted in application databases are HMAC-SHA256 hashed with a server-side salt; never plaintext.
  • Backups: daily Postgres snapshots, retained 30 days, encrypted, restore drills [TBD — quarterly].

Network and infrastructure

  • Production runs on a Kubernetes cluster operated by FerrLabs in the EU (see legal notice).
  • Public ingress through Traefik with strict per-host routing; no service is exposed by default.
  • Pods run as non-root, with read-only root filesystems and dropped capabilities.
  • Container images are pulled from ghcr.io/ferrlabs/* and signed for integrity verification [TBD — sigstore / cosign].
  • Secrets in the cluster are managed by FerrVault (operator pulling from FerrVault into native Kubernetes Secrets) — eating our own dog food.

Application security

  • Strict Content-Security-Policy on every web surface: default-src 'self', no third-party script, no inline iframes.
  • Defence-in-depth security headers: HSTS, X-Frame-Options DENY, X-Content-Type-Options nosniff, Referrer-Policy strict-origin-when-cross-origin.
  • Anti-CSRF tokens on every state-changing request from the apps.
  • Multi-tenant isolation enforced at the API layer (every query scoped by tenant ID; integration tests verify cross-tenant access is denied).
  • Dependency monitoring: Dependabot on every repository, Cargo audit and pnpm audit in CI.

Logging and monitoring

  • Application logs centralised in [TBD — Loki / OpenObserve / …], retention 30 days, restricted access.
  • Administrative actions audited (who did what, when) — visible to Controllers in product audit logs (FerrVault audit, FerrTrack activity, …).
  • Live status: status.ferrlabs.com.

Coordinated vulnerability disclosure

If you believe you have found a security vulnerability in any FerrLabs service, please contact security@ferrlabs.com. PGP key: [TBD — fingerprint or link to security.txt].

We commit to:

  • Acknowledge receipt within 48 hours;
  • Assess and triage the report within 7 days;
  • Provide a status update at least every 14 days until resolution;
  • Credit the reporter in our public disclosure (with their consent).

Please do not publicly disclose before we have had a reasonable opportunity to remediate (90 days by default; shorter for critical issues actively being exploited).

Personal data breach notification

In the event of a personal data breach, FerrLabs notifies the CNIL within 72 hours (Article 33 GDPR) and the affected Controllers without undue delay, with the information required by Article 34 GDPR.

Compliance roadmap

  • SOC 2 Type II:[TBD — planned for …]
  • ISO/IEC 27001:[TBD]
  • HDS (French health-data hosting): not in scope.

French version: Sécurité.