FerrVault
FeaturesWhy FerrVaultPricingChangelogDocs
ENFR
Waitlist→

Legal document

Security: FerrVault

Last updated: May 27, 2026

FerrVault inherits the baseline controls of the FerrLabs platform. See ferrlabs.com/security for identity, infrastructure, vulnerability disclosure, and breach notification. The addenda below cover what is specific to a secrets manager: how a secret value flows from your CLI or pod, through TLS, into envelope-encrypted storage, and back out under audit.

Transport

  • TLS 1.2+ only. Mozilla "Modern" profile pinned at the edge: AEAD ciphers only (AES-GCM, ChaCha20-Poly1305), ECDH P-384/P-521, SNI strict. SSL Labs grade A+ at the time of writing.
  • Post-quantum hybrid key exchange. X25519MLKEM768 negotiated with capable clients (Chrome 124+, Firefox 132+, Edge 124+). Defends against "harvest now, decrypt later" attacks where an adversary records ciphertext today and tries to decrypt it with a future quantum computer.
  • HSTS preload on every FerrVault subdomain: max-age=31536000; includeSubDomains; preload, plus a 301 redirect on www.ferrvault.com. Submitted to the Chrome / Firefox / Edge preload lists.
  • DNS CAA pins certificate issuance to Let's Encrypt only.
  • No response compression on reveal endpoints. Removes the theoretical BREACH side channel.
  • HTTP→HTTPS permanent redirect; the HTTP entrypoint serves no real content.

Storage and encryption

  • Envelope encryption. Each secret version is encrypted with a unique 256-bit Data Encryption Key (DEK) generated by a CSPRNG. The DEK is itself wrapped by a per-vault Key Encryption Key (KEK) held outside the application database. We never write a DEK to disk in plaintext, and we never write a KEK at all: only the KMS identifier.
  • AES-256-GCM with a 96-bit random nonce per write. No (key, nonce) pair is ever reused: each rotation mints a new DEK.
  • KMS-backed KEK. Production runs against HashiCorp Vault Transit; LocalKMS is explicitly refused at startup when FERRVAULT_ENVIRONMENT=production.
  • KEK rotation is auditable; rotation events emit a dedicated kek.rotated entry.
  • At-rest disk encryption on the underlying Postgres volume.

Authorization and isolation

  • Three-level hierarchy: Vault → Environment → Secret. A staging operator token literally cannot decrypt production ciphertext. The SAT is bound to one (vault, environment, role) tuple and every SQL query scopes by environment_id.
  • RBAC roles: Viewer (read), Writer (read + rotate), Admin (full + grants).
  • Per-SAT IP allowlist. Each service-account token can declare a list of CIDRs / IP literals (v4 + v6) outside of which it is rejected with 403.
  • Per-SAT + per-IP rate limit. 60 requests / minute on each axis; forged-token floods cannot bypass via random bearer rotation.
  • SAT tokens are hashed with Argon2id at rest; lookup uses an indexed SHA-256 hash so verification stays O(1) under load.
  • JWT auth uses ed25519 signatures issued by the central FerrLabs identity provider.

Audit

  • Every read of a secret value is logged: that is the product, and a failed audit insert blocks the read. The plaintext does not leave the process if the trail cannot be persisted.
  • Every write, version restore, grant change, KEK rotation, and environment lifecycle event is also recorded.
  • Audit rows carry the org, the vault, the secret, the actor (user JWT or SAT id), the action, and structured metadata. Reachable via the API and the web UI under the Audit tab of each vault.
  • Tamper-evident audit (append-only hash chain + immutable export) is on the roadmap.

HTTP security headers

Applied to every api.ferrvault.com, app.ferrvault.com, auth.ferrvault.com, and ferrvault.com response:

  • Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
  • Content-Security-Policy: frame-ancestors 'none' + X-Frame-Options: DENY
  • X-Content-Type-Options: nosniff
  • Referrer-Policy: strict-origin-when-cross-origin
  • Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=()
  • Cross-Origin-Opener-Policy: same-origin
  • X-DNS-Prefetch-Control: off

Operational hardening

  • Hard cap on inbound request bodies (1 MiB): kills OOM attempts via arbitrary-sized POSTs.
  • SQL fully parameterised; no user input ever concatenated into a query string.
  • ON DELETE CASCADE on every vault-scoped foreign key: no dangling references after vault or environment removal.
  • Database errors are mapped to a generic "Database error occurred" body; the full error is logged server-side only.
  • Container images pulled from ghcr.io/ferrlabs/*; pods run non-root with read-only root filesystem.

What we do not claim

  • FerrVault is not yet SOC 2 / ISO 27001 certified. Tracked on the FerrLabs compliance roadmap.
  • No external penetration test has been performed yet. The controls above are the result of internal review.
  • Mutual TLS for operator → API and append-only hash-chained audit are on the roadmap but not shipped today.

Contact

security@ferrlabs.com | FerrLabs platform security →

FerrVault

Secrets management for product teams. EU-hosted, audited.

← Back to ferrlabs.com
Products
  • FerrVault
  • FerrFlow
  • FerrTrack
  • FerrGrowth
  • FerrFleet
  • FerrLens
Resources
  • Changelog
  • Docs
  • RSS
  • GitHub
Legal
  • Legal notice
  • Privacy
  • Terms
  • Cookies
  • DPA
  • Subprocessors
  • Security
© 2026 FerrLabs. FerrVault is a FerrLabs product.Set in Fraunces, hand-built in Lille, FR