GitHub détecte les clés Supabase et Lovable : ce que cela change pour les outils créés avec l’IA

ParKelvin Carretero-Corrales

Les outils assistés par IA permettent de monter un prototype, une petite application ou une automatisation beaucoup plus vite qu’avant. Le piège, c’est que la vitesse ne fait pas disparaître les règles de sécurité. Une clé d’API copiée dans un fichier, envoyée dans un dépôt Git ou glissée dans un exemple de configuration reste une vraie clé, avec de vrais accès derrière.

Le 5 octobre 2026, GitHub a annoncé l’ajout de nouveaux détecteurs pour plusieurs secrets utilisés dans des outils modernes : Lovable, Supabase, Pydantic Logfire et Pydantic AI Gateway. C’est une amélioration discrète, mais très concrète pour les personnes qui construisent des applications ou des automatisations avec l’aide de l’IA.

Quels nouveaux secrets GitHub sait-il repérer ?

GitHub indique que son système de détection reconnaît désormais les types de secrets suivants :

  • lovable_api_key pour Lovable ;
  • logfire_token pour Pydantic Logfire ;
  • pydantic_ai_gateway_api_key pour Pydantic AI Gateway ;
  • supabase_oauth_access_token pour Supabase ;
  • supabase_scoped_personal_access_token pour Supabase.

Lovable rejoint également le programme partenaire de GitHub. Lorsqu’une clé Lovable est découverte dans un dépôt public, GitHub peut la transmettre à son émetteur afin qu’elle soit révoquée ou renouvelée avant d’être exploitée. Cela réduit le délai entre la fuite et la réaction, mais ne garantit pas que la clé n’a jamais été copiée.

Pourquoi cette actualité concerne aussi les petites structures

Supabase et Lovable sont justement utilisés pour créer rapidement des applications, parfois par des personnes qui ne travaillent pas quotidiennement avec Git. Une IA peut générer un fichier de configuration fonctionnel contenant une clé, puis proposer une commande qui ajoute tout le dossier au dépôt. Techniquement, le projet démarre. Côté sécurité, la clé vient peut-être de devenir publique.

Le même risque existe dans une automatisation : jeton d’accès à un service, identifiants de base de données, clé d’un fournisseur d’IA ou URL de webhook sensible. Un secret peut finir dans le code, mais aussi dans un exemple, un commentaire, un journal d’exécution ou une capture copiée dans un ticket.

Ce que le secret scanning analyse réellement

D’après la documentation GitHub, l’analyse ne se limite pas à la dernière version des fichiers. Elle parcourt l’historique Git, les branches et plusieurs espaces de collaboration : problèmes, demandes de fusion, discussions, wikis et gists secrets. GitHub indique aussi relancer périodiquement l’analyse lorsque de nouveaux formats de secrets sont ajoutés.

C’est un point important : une clé commise il y a plusieurs semaines peut être détectée aujourd’hui parce que GitHub vient d’apprendre à reconnaître son format. L’absence d’alerte hier ne prouvait donc pas que le dépôt était propre.

Pour les dépôts publics, le secret scanning fonctionne automatiquement et gratuitement. Pour les dépôts privés ou internes appartenant à une organisation, la disponibilité dépend notamment de GitHub Secret Protection et de l’offre utilisée. Il faut donc vérifier la configuration réelle du dépôt au lieu de supposer que la protection est active.

Une détection n’est pas un coffre-fort

Le scanner intervient après qu’un secret a été placé quelque part où il ne devait pas se trouver. Même lorsqu’une protection bloque un envoi, ce contrôle reste une barrière supplémentaire, pas la méthode principale de stockage.

La base reste simple :

  • conserver les secrets dans des variables d’environnement ou un gestionnaire prévu pour cela ;
  • exclure les fichiers locaux comme .env du suivi Git, sans oublier qu’un fichier déjà commis reste dans l’historique ;
  • utiliser des jetons limités au strict nécessaire, avec une durée de vie courte lorsque le fournisseur le permet ;
  • séparer les accès de développement, de test et de production ;
  • éviter les vraies clés dans les exemples, les journaux et les captures d’écran ;
  • activer les alertes et la protection à l’envoi disponibles sur le dépôt.

Une clé a été exposée : dans quel ordre agir ?

Premier réflexe : révoquer ou faire tourner la clé immédiatement. Supprimer le fichier ou rendre le dépôt privé ne suffit pas. Le secret a pu être lu, copié ou indexé avant la correction.

  1. Révoquer la clé compromise depuis le service concerné.
  2. Créer une nouvelle clé avec les droits minimaux nécessaires.
  3. Mettre à jour l’application ou l’automatisation via son système de secrets.
  4. Contrôler les journaux du fournisseur pour repérer une utilisation anormale.
  5. Nettoyer le code et, si nécessaire, l’historique Git sans retarder la révocation.
  6. Vérifier où la même clé avait été réutilisée.

GitHub recommande lui aussi de renouveler immédiatement l’identifiant concerné. Réécrire l’historique peut être utile pour retirer la valeur des anciennes versions, mais cette opération demande des précautions et ne rend pas secrète une clé déjà publiée. La rotation reste l’action prioritaire.

Le lien concret avec les prestations FuretSplick

Pour une automatisation n8n ou un petit outil métier, la sécurité des accès doit être pensée dès le départ : où vivent les identifiants, qui peut les lire, quels droits ils donnent, comment les renouveler et comment être alerté si quelque chose fuit. Cette vérification fait partie d’une livraison exploitable, au même titre que les tests et la gestion des erreurs.

La page Automatisations et petits outils métier de FuretSplick présente cette approche : connecter les outils sans créer une boîte noire impossible à reprendre ou à dépanner.

À retenir

L’ajout de ces détecteurs est une bonne nouvelle, surtout avec la multiplication des applications créées rapidement grâce à l’IA. Mais le bon message n’est pas « GitHub retrouvera mes erreurs ». C’est plutôt : un secret ne doit jamais entrer dans le dépôt, et sa détection doit déclencher une rotation immédiate.

Sources

Publications similaires