Détection en temps réel
Nous utilisons Sentry pour la détection d'erreurs en temps réel, configuré pour ne pas collecter de données personnelles par défaut.
Sécurité & confidentialité
Monitoring et transparence
Comment nous surveillons la plateforme, et comment chaque modification est tracée.
Chaque modification passe par un pipeline d'audit de vulnérabilités, d'analyse statique et de contrôle de cohérence avant d'atteindre la production. Sentry surveille les erreurs en temps réel avec les PII retirées avant que les événements ne quittent le serveur. Notre historique Git est public pour les composants open-source et tracé en interne pour les privés — chaque modification est attribuable, et chaque attribution est vérifiable.
CI verrouillée
Notre chaîne CI exécute à chaque modification : audit de vulnérabilités des dépendances (bundler-audit), analyse statique applicative (brakeman), et contrôle de cohérence des filtres de suppression douce.
Historique tracé
Notre historique Git est public pour les composants open-source et tracé en interne pour les composants privés — chaque modification est attribuable.
Audits de dépendances
Chaque pull request est vérifiée contre la base CVE de bundler-audit ; toute version de gem known-vulnerable bloque le merge. Dependabot de GitHub ouvre automatiquement des PR pour les nouvelles mises à jour de sécurité — on n'attend pas d'entendre parler des CVE par la voie lente.
Analyse statique applicative
Brakeman tourne à chaque modification au niveau d'alerte 2. SQL injection, mass assignment, redirects non sûrs, crypto faible — tout est remonté au moment de la review plutôt qu'au runtime.
Garde NULL-safe
Une étape CI custom grep le motif NULL-unsafe where.not(status: "deleted"). C'est comme ça qu'on a attrapé le bug du login-pour-utilisateurs-avec-status-NULL une fois ; ça garde maintenant chaque future PR.
Scan de secrets
Le secret scanning de GitHub surveille le repo pour les clés API, secrets webhook et jetons commités par accident. Les matchs déclenchent un page immédiat, et tout fournisseur que GitHub connaît est également notifié pour révoquer la clé en amont.
Commits signés
Chaque commit de production est revu via une pull request, attribué à un auteur nommé, et taggé contre une release spécifique. Il n'existe pas de chemin anonyme du code à la production.
Plongée technique
Pipeline CI
Chaque pull request déclenche un workflow GitHub Actions qui lance — dans l'ordre :
bundle-audit— scan CVE contre le Gemfile.lockbrakeman— analyse statique applicative (SQL injection, redirects non sûrs, crypto faible, mass assignment, etc.)bin/null-safe-check— un grep custom qui attrape les motifswhere.not(status: "deleted")qui excluraient accidentellement les lignes NULL dans Postgresrubocop --parallel— lints de style et de sécurité
Tout échec bloque le merge. L'ordre compte : les vulnérabilités de dépendances sont remontées en premier parce qu'elles sont les moins chères à corriger et le vecteur le plus courant ; les lints de style en dernier parce qu'ils portent le moins de poids.
Configuration Sentry
Nous fixons explicitement send_default_pii = false. Par-dessus, un filtre before_send parcourt le payload de l'événement et retire tout champ matchant config.filter_parameters avant sérialisation. Les deux garde-fous sont redondants à dessein : si la doc Sentry change le défaut un jour, notre before_send tient la ligne.
Le DSN n'existe qu'en production ; staging et dev utilisent un initialiseur no-op. Une stack trace locale n'envoie jamais d'erreur contenant des données de test synthétiques par accident.
Historique Git comme audit trail
Chaque modification en production mappe une pull request revue et un commit signé. L'onglet security de GitHub est activement surveillé : les alertes Dependabot, les findings de code scanning et les alertes de secret scanning nous pagent par email.
Pour les composants open-source (firmware appareil, app), l'historique Git est public — n'importe qui peut auditer le firmware qui tourne chez lui, vérifier que nos tags de release correspondent à notre source, et signaler toute divergence via le canal de divulgation responsable.
Nous ne déployons pas de features plus vite que nous ne pouvons les auditer. Si une étape CI est flaky et se fait désactiver, c'est une régression de sécurité qui est fixée avant le prochain merge. Une plomberie ennuyeuse et fiable bat un dashboard de lumières rouges.