Remédier à une fuite sur GitHub public

Si vous êtes arrivé sur cette page, il est probable que vous ayez reçu une alerte de notre service d'alerte pro bono. Ne vous inquiétez pas, les fuites arrivent parfois... même aux meilleurs d'entre nous...

Cette section fournit un guide étape par étape sur la façon de remédier à une fuite survenue sur GitHub public.

Pour des conseils complets de remédiation couvrant à la fois les incidents publics et internes, consultez notre Vue d'ensemble de la remédiation Public Monitoring.

⚠️ Ce que vous ne devez PAS faire :

• Committer par-dessus la version actuelle du code source n'est pas une solution. Gardez à l'esprit que git conserve un historique, le secret sera toujours visible dans les commits précédents.
• Supprimer uniquement le dépôt concerné n'est pas une solution correcte. Les identifiants ayant fuité resteront exposés dans les forks du dépôt, et des attaquants pourraient toujours y accéder dans des versions miroir de GitHub.

✅ Guide étape par étape pour remédier à la fuite

• Étape 1 : Évaluez l'impact et révoquez le secret exposé.
• Étape 2 : Nettoyez l'historique git (facultatif, voir les avertissements ci-dessous).
• Étape 3 : Inspectez les logs et vérifiez la sécurité.

🔒 Étape 1 : Évaluer l'impact et révoquer le secret (~ 5-10 min)

Tout d'abord, évaluez rapidement la situation :

• Confirmez que ce secret appartient réellement à votre organisation
• Comprenez à quelles ressources ce secret peut accéder
• Déterminez le niveau de privilège et l'impact potentiel

Ensuite, révoquez le secret - c'est la seule façon de garantir qu'aucun attaquant n'accédera au service concerné.

Comment révoquer :

• Ayant été alerté par GitGuardian, vous pouvez naviguer vers la documentation du détecteur GitGuardian correspondant, toutes les informations sur la révocation sont disponibles dans la section Revoke the secret du détecteur sélectionné.
• Si vous avez découvert la fuite sans GitGuardian et qu'il ne s'agit pas d'un type de secret pris en charge par l'un de nos détecteurs, consultez la documentation du fournisseur concerné. Vous pouvez généralement révoquer vos identifiants dans la même section où vous les avez émis.
• Si vous avez fait fuiter des identifiants d'entreprise ou des identifiants que vous ne pouvez pas révoquer vous-même, nous vous recommandons vivement de contacter immédiatement votre équipe de sécurité. Il est normal de faire des erreurs, les cacher est souvent un problème plus important.

Que vous ayez réussi à révoquer les identifiants ou non, passez à l'étape 2 pour atténuer la fuite et en supprimer les traces.

🧹 Étape 2 : Nettoyage du dépôt (~ 10 min) - FACULTATIF

⚠️ Important : Une fois que vous avez révoqué le secret, vous devriez généralement vous arrêter ici. Le secret est désormais inutile pour les attaquants, et votre incident de sécurité est résolu.

Réduction d'urgence de la visibilité (si la révocation a échoué) : Si pour une raison quelconque vous n'avez pas pu révoquer les identifiants ayant fuité, l'action la plus rapide pour retirer les identifiants de la vue de la plupart des attaquants est de rendre le dépôt privé. Bien que vos identifiants soient probablement mis en miroir à un autre endroit sur internet, c'est déjà un bon moyen de gagner un peu de temps.

Comment rendre un dépôt privé : Allez dans la section settings de votre projet GitHub et choisissez le bouton change visibility en bas.

Réécriture de l'historique git (procédez avec une extrême prudence) :

attention

La réécriture de l'historique git n'est généralement pas recommandée car elle peut perturber les flux de travail des équipes et laisse souvent des références aux commits ayant fuité. Ce n'est pas une action triviale à mener et elle peut casser le flux de travail des développeurs contributeurs et supprimer accidentellement des données légitimes. Pour des questions d'image de marque, vous pourriez vouloir nettoyer l'historique git afin de supprimer toute trace de la fuite, mais gardez à l'esprit que cette action n'est pas suffisante car le secret peut toujours être visible pour les attaquants, soit dans les forks du dépôt concerné, soit dans des versions miroir de GitHub.

Si vous décidez tout de même de réécrire l'historique :

• Vous pouvez utiliser des outils comme git-filter-repo pour réécrire l'historique d'un projet. Vous pouvez vous référer à cet article de blog GitGuardian pour des instructions détaillées.
• Une fois que vous avez corrigé votre historique git et que vous l'avez poussé vers le serveur distant. Sachez que cela peut entraîner la persistance d'un commit orphelin contenant la fuite sur GitHub. Vous pouvez contacter le support GitHub pour supprimer définitivement ces données.

🔎 Étape 3 : Surveiller et vérifier la sécurité (~ 5-10 min)

Inspecter vos logs vous donnera une idée rapide de savoir si les identifiants compromis ont été utilisés par un attaquant ou non, et de ce qui s'est exactement passé.

Comment vérifier les accès non autorisés :

• Si le fournisseur concerné est pris en charge par le moteur de détection de GitGuardian, vous pouvez consulter la section Check for suspicious activity de la documentation du détecteur concerné.
• Sinon, le fournisseur d'API donne généralement des informations sur la dernière utilisation des identifiants dans la page des paramètres. Si les identifiants compromis sont des identifiants de base de données ou des clés privées, vous pourriez vouloir consulter les logs du serveur concerné.

Ce qu'il faut rechercher :

• Des schémas d'accès ou des horaires inhabituels
• Des accès depuis des adresses IP ou des localisations inconnues
• Des appels d'API ou des accès aux données inattendus
• Toute activité après le moment supposé de l'exposition

Si vous trouvez des preuves d'accès non autorisé :

• Documentez toute activité suspecte
• Considérez cela comme une violation de sécurité confirmée
• Suivez les procédures de réponse aux incidents de votre organisation
• Envisagez de faire appel à des professionnels de la cybersécurité si nécessaire

🏁 Enfin

Félicitations, vous devriez maintenant être couvert. Comme vous le savez, des erreurs peuvent arriver et GitGuardian est là pour vous. Il vous suffit de vous inscrire gratuitement et de bénéficier de l'alerte en temps réel de GitGuardian pour être protégé à l'avenir. Vous pouvez également scanner votre historique pour vérifier que vous n'avez pas d'autres secrets enfouis dans votre code.

Si vous êtes plutôt du genre CLI, vous pouvez consulter GitGuardian CLI. Cette application CLI peut s'exécuter dans votre environnement local, ou dans un environnement CI pour détecter plus de 600 types de secrets.