Sécurité et conformité

Cette page s'adresse aux RSSI, DSI et acheteurs sécurité qui évaluent un déploiement Gilbert en B2B. Si vous êtes développeur intégrateur, lisez plutôt JWT SSO et Webhooks. Pour le détail du modèle d'isolation côté produit, voir la section Isolation et sécurité de la page Workspaces.

Le ton de cette page est volontairement factuel. Tous les chiffres cités sont vérifiables dans le dépôt (workflows CI, migrations Supabase, evidence package CASA) et peuvent être audités sur demande.

CASA (Cloud Application Security Assessment) est le programme d'audit de sécurité de l'App Defense Alliance, requis par Google pour toute application qui demande des scopes OAuth sensibles ou restreints sur le cycle de re-vérification annuel. Tier 2 est le niveau auto-assessment : l'éditeur démontre la conformité ASVS L2 d'OWASP via un evidence package, soumis ensuite à un laboratoire accrédité.

Le 28 mai 2026, le package Gilbert est complet (Sprints 1 à 3). Verdict actuel :

• 64 / 86 contrôles ASVS L2 validés, 0 échec, 22 non applicables (justifiés) ou hors périmètre Tier 2.
• Sprint 4 = soumission via appdefensealliance.dev/casa. C'est la dernière étape avant attestation publique.
• Objectif : maintenir le scope OAuth gmail.modify nécessaire au forward-to-Gilbert et à la rédaction automatique de drafts. Cycle de re-vérification Google : 12 mois.

Le package (ASVS self-assessment, threat model STRIDE, data flow PII, justification des scopes OAuth) est disponible sur demande sous NDA pour les acheteurs en cours d'évaluation.

Tout commit sur Gilbert passe par un pipeline d'analyse statique automatique. Les chiffres ci-dessous sont l'état au 28 mai 2026, reproductibles depuis les workflows GitHub Actions du dépôt.

• CodeQL : queries security-extended + security-and-quality sur chaque push et chaque PR.
• Semgrep : rulesets OWASP Top 10, Node.js, React, JWT, secrets, injection. Les 8 findings ouverts en début de Sprint 3 ont tous été clos (3 JSON-LD dangerouslySetInnerHTML justifiés avec nosemgrep, 3 ajouts d'authTagLength: 16 sur des paires GCM, 1 wildcard postMessage Stripe/reCAPTCHA, 1 token Telegram redacté dans les TODOs).
• Dependabot : npm + GitHub Actions, avec SHA-pin des Actions tierces.
• gitleakssur 968 commits / 221 Mo d'historique : 0 leak.
• npm audit : 0 critical, 0 high. La CI échoue sur le gate --audit-level=high dès qu'une vuln high est introduite.
• SSRF safeFetch : hardening complet pendant le Sprint 3. 1 finding HIGH (TOCTOU DNS-rebinding, fenêtre d'exploit côté Vercel Lambda : vol de credentials IAM via 169.254.169.254, CVSS 7.5) fixé via safeDispatcher (Agent undici singleton qui valide la résolution DNS au moment du connect). 3 LOWs fixés en parallèle (trailing-dot bypass, cap URL à 2 Ko, pas de fuite d'IP dans les erreurs).

Audit exhaustif des 121 routes serveur Gilbert au 28 mai 2026. Aucune route MISSING : chaque endpoint a un mode d'authentification documenté et testé.

La frontière d'isolation est le workspace. Tokens OAuth, historique de chat, intégrations, routines, clés LLM ne traversent jamais cette frontière, même pour un utilisateur membre de plusieurs workspaces. Détail complet dans Workspaces — Isolation et sécurité.

• Schéma Postgres dédié. Toutes les tables Gilbert vivent dans le schéma gilbert, séparé du schéma publicdes produits Solve. Aucun JOIN cross-schéma autorisé : la communication avec les autres apps Solve se fait via webhooks HMAC signés.
• RLS Postgres activé sur chaque table. Policies par workspace_members, et policies per-user sur les tables sensibles (forward_runs, user_style_profile, user_phone_settings). Invariant strict : les données per-user ne sont jamais lisibles workspace-wide, même par un admin.
• Frontière workspace = frontière OAuth. Un token Google connecté dans le workspace A ne peut être utilisé depuis le workspace B : la lookup se fait par workspace_idet la signature JWT d'un agent embed du workspace A est rejetée par les endpoints du workspace B.

Tout secret persistant est chiffré AES-256-GCMavec une clé dédiée stockée uniquement en variable d'environnement côté serveur. Les colonnes chiffrées ne sont jamais lisibles en clair, même par les admins de la base.

En transit : TLS 1.3 sur toutes les façades (Vercel, Supabase, Anthropic, Google APIs). Les webhooks sortants Gilbert sont signés HMAC-SHA256 avec un secret par workspace.

Gilbert fonctionne en BYOLLM (Bring Your Own LLM) : chaque workspace branche ses propres clés API Anthropic, Google Gemini ou OpenAI. Tous les appels modèles du workspace passent par cette clé. Conséquence directe :

• Facturation directechez le provider. Aucun markup Solve, pas d'intermédiaire financier. Vos coûts d'inférence apparaissent sur votre console Anthropic / Google Cloud / OpenAI.
• Vos prompts et réponses sont gouvernés par le contrat data processingque vous avez signé avec le provider, pas par un avenant Solve. Si vous avez un contrat entreprise avec opt-out training Anthropic, il s'applique naturellement.
• Mode privacy strict. Le toggle allow_central_fallback = false empêche tout fallback sur la clé Anthropic centrale Gilbert si la clé workspace est mal configurée ou hors quota. L'appel échoue en clair (fail-fast) plutôt que de transiter par notre infrastructure. Recommandé dès qu'une clé workspace est en place.

Côté implémentation : voir ModelTier pour l'abstraction tier fast /  smart / premium, et la section Workspaces — BYOLLM pour le détail produit.

Gilbert est déployé sur deux fournisseurs principaux, complétés par les providers LLM choisis par le workspace.

• Vercel : fonctions serverless et edge, hébergement Next.js, build CI. Sous-traitant indiqué dans nos DPA.
• Supabase : Postgres managé, Auth, Storage. Projet de production référence zqzcmacfvutqwgosoxyp, région UE. RLS activé sur toutes les tables.
• Analytics produit : PostHog Cloud EU.
• Providers LLM(Anthropic, Google Cloud, OpenAI) : contractés directement par le clientvia BYOLLM. Ils n'apparaissent pas comme sous-traitants Solve : le client choisit la région et la juridiction avec son provider.

Chaque clé externe (OAuth, webhook signature, clé crypto data at-rest) a une checklist de rotation documentéeinterne. Une rotation Google OAuth touche par exemple cinq endroits : .env.local, Vercel prod, Supabase Auth Dashboard (deux projets DEV et PROD), puis redeploy. Les rotations Vapi, Postmark, Telegram et les clés PHONE_ENC_KEY / TRANSCRIPT_ENC_KEY / FORWARD_ENC_KEY ont chacune leur procédure écrite.

Les clés de chiffrement de données déjà persistées (téléphone, transcripts, forward-runs) nécessitent une procédure de re-key DB (déchiffrer ancienne clé, re-chiffrer nouvelle clé, swap) pour éviter de rendre des lignes illisibles. Cette procédure est listée dans le dépôt comme prérequis avant rotation.

Pour une demande de revue, un signalement de vulnérabilité, ou la récupération du package CASA sous NDA : passez par votre interlocuteur Solve habituel. Si vous découvrez une faille, merci de la signaler de manière privée avant toute divulgation publique.

Les findings récents et leurs résolutions sont listés dans le changelog.