Rustine

Sécurité

Mis à jour le

Rustine voit les failles de tes sites et peut lire ton code : on doit le protéger au moins aussi bien qu'on te demande de protéger le tien. Voici ce qui est fait concrètement, et comment nous signaler une faille dans Rustine.

Signaler une faille

Écris à security@rustine.io, en français ou en anglais. Les règles sont plus bas, dans Politique de divulgation. Aussi dans notre security.txt.

Où sont tes données

  • L'app, l'API, la base de données et le cache tournent sur un serveur dédié chez Hetzner, à Helsinki (Finlande). La base et le cache ne sont joignables que par le réseau privé du serveur, jamais depuis Internet.
  • Le serveur n'accepte que les connexions web (HTTPS, et HTTP redirigé vers HTTPS) et SSH par clé, sans mot de passe.
  • Les prestataires qui touchent tes données, et où ils sont, sont listés dans la politique de confidentialité.

Les scans, dans des conteneurs isolés

  • Chaque scan tourne dans son propre conteneur sur Google Cloud Run, à Paris, détruit à la fin du scan. Aucun disque n'est partagé entre deux scans.
  • Le conteneur ne reçoit qu'un jeton valable pour son seul scan, pendant 17 minutes au plus. Il ne parle pas à la base : il renvoie son rapport à l'API, qui le vérifie avant de l'enregistrer.
  • Son réseau ne sort que vers les ports 80 et 443 d'adresses publiques ; les réseaux privés lui sont fermés et rien ne peut le joindre de l'extérieur. Il sort par une adresse fixe, publiée sur la page Le scanner.

Les secrets qu'on trouve

Quand un scan trouve une clé ou un mot de passe qui traîne, il le masque avant de nous l'envoyer : on ne garde que son type, ses 4 derniers caractères (s'il en a au moins 16) et une empreinte courte, de quoi le reconnaître sans pouvoir s'en servir. Il n'existe donc nulle part en clair chez nous, ni en base, ni dans les rapports PDF. Le même masquage s'applique aux extraits de code d'un dépôt, et à ce qu'on envoie au modèle d'IA qui rédige un Correctif.

Ton code GitHub

  • Rustine se connecte par une GitHub App en lecture seule (contenu et métadonnées des dépôts) : elle ne peut rien écrire dans tes dépôts.
  • Chaque analyse demande à GitHub un jeton limité à un seul dépôt, en lecture seule, qui expire au bout d'une heure au plus, et le révoque dès l'analyse finie. Ce jeton n'est jamais enregistré.
  • Avant chaque analyse, Rustine vérifie que la personne qui a ajouté le dépôt y a toujours accès sur GitHub (pour les dépôts ajoutés depuis le 15 octobre 2026) : quelqu'un qui quitte ton organisation ne reçoit plus rien de ton code.
  • La copie du dépôt est effacée à la fin de l'analyse : on ne garde pas ton code, seulement les problèmes trouvés, avec des extraits masqués.

Ton compte

  • Pas de mot de passe chez Rustine : on se connecte par un code envoyé par e-mail (6 chiffres, valable 10 minutes, 5 essais), ou avec Google ou GitHub.
  • La double authentification est obligatoire pour tout le monde avant la première action sensible (prouver un site, connecter GitHub, payer, créer une clé d'API, connecter un agent), puis à chaque connexion : une app d'authentification ou une passkey, et dix codes de secours.
  • Le cookie de session n'est pas lisible par les scripts de la page, ne circule qu'en HTTPS et expire au bout de 7 jours. Les formulaires sont protégés contre les requêtes forgées (CSRF), et les tentatives de connexion sont limitées.
  • Chaque connexion est inscrite dans un journal de sécurité (méthode, date, empreinte du réseau, jamais l'adresse IP en clair), gardé un an.

Ce qui est chiffré ou haché

  • Chiffrés (AES-256-GCM) : le secret de ton app d'authentification, les jetons de connexion à Supabase et les jetons de vérification de tes sites.
  • Hachés, jamais gardés en clair : les clés d'API, les jetons des agents connectés (OAuth), les codes de secours et les codes de connexion. Une clé d'API n'est montrée qu'une fois, à sa création.
  • Le paiement passe par Stripe : ton numéro de carte n'arrive jamais chez nous (on garde seulement la marque et les 4 derniers chiffres, pour te les afficher).

Nos propres accès

  • Le back-office demande un compte administrateur et la double authentification.
  • Chaque action d'administration (offrir des crédits, changer une offre, réinitialiser une double authentification, supprimer un compte, arrêter un scan…) est inscrite dans un journal, avec son auteur et sa raison. La base de données refuse toute modification de ce journal, et toute suppression avant 5 ans.
  • Les rapports d'erreurs de l'app et de l'API partent vers notre propre outil de suivi, hébergé en Allemagne, sans cookie, sans en-tête de requête ni identité de l'utilisateur.

Sauvegardes

La base est copiée chaque nuit dans un stockage Cloudflare R2 situé dans l'Union européenne, réservé à Rustine, accessible par une clé limitée à ce seul espace. Les 14 dernières copies sont gardées. Une restauration complète a été testée le 13 octobre 2026.

Le cadre légal des scans

  • Aucun test actif sans preuve que le site t'appartient : un enregistrement DNS, un fichier ou une balise sur le site. La preuve est revérifiée avant chaque audit ; sans elle, seul le scan rapide, passif, est possible.
  • Le scanner lit sans rien modifier : requêtes GET, HEAD et OPTIONS seulement, aucun formulaire envoyé, aucune charge d'exploitation. Une faille connue est repérée par son numéro de version, jamais en la déclenchant.
  • Chaque scan a un budget de requêtes et de temps. Son identifiant et son adresse sont publiés sur la page Le scanner.
  • Un site peut demander à ne plus être scanné : abuse@rustine.io.

Politique de divulgation

Tu as trouvé une faille dans Rustine (rustine.io, app.rustine.io, api.rustine.io, mcp.rustine.io, docs.rustine.io, ou le scanner lui-même, par exemple un moyen de lui faire scanner un site sans preuve) ? Merci de nous l'écrire à security@rustine.io : ce qui est touché, comment le reproduire, et ce qu'un attaquant pourrait en faire.

Ce qu'on s'engage à faire

  • Accuser réception sous 72 heures, puis te tenir au courant jusqu'au correctif.
  • Corriger selon la gravité : une faille critique sous 7 jours, élevée sous 30 jours, moyenne sous 90 jours ; une faille faible avec une prochaine mise à jour.
  • Te citer, si tu le souhaites, une fois la faille corrigée.
  • Ne pas porter plainte ni engager de poursuites contre une recherche de bonne foi qui respecte les règles ci-dessous.

Les règles

  • Teste uniquement avec ton propre compte, sur des sites que tu as le droit de scanner.
  • Ne consulte, ne modifie et n'emporte pas les données d'un autre utilisateur. Si tu tombes dessus, arrête-toi là et dis-le nous.
  • Pas de déni de service, pas de test de charge, pas de spam, pas d'ingénierie sociale ni d'hameçonnage de notre équipe.
  • Ne teste pas nos prestataires (Stripe, GitHub, Google, Cloudflare, Hetzner…) : leurs failles se signalent chez eux.
  • Garde la faille pour toi jusqu'à sa correction, ou 90 jours après ton signalement si on n'a pas tenu nos délais.

Pas de prime en argent pour l'instant. En France, tu peux aussi signaler une faille de bonne foi à l'ANSSI, qui garde ton identité confidentielle (article L2321-4 du Code de la défense).

État des services

Le site, l'app, l'API, le serveur MCP et la documentation répondent-ils ? Voir la page État des services.