Correction d’une fuite de secret dans votre référentiel

Introduction

Les secrets, tels que les clés API, les jetons et les identifiants, peuvent présenter des risques de sécurité importants pour votre équipe et votre organisation s'ils sont exposés par inadvertance dans votre base de code ou stockés de manière inappropriée.

Vous devez considérer que tout secret divulgué est immédiatement compromis et qu’il est essentiel d’effectuer les étapes de correction appropriées, telles que la révocation du secret. La simple suppression du secret de la base de code, l’envoi (push) d’une nouvelle validation ou la suppression et la recréation du référentiel n’empêchent pas l’exploitation du secret.

Ce guide pratique vous guide tout au long de ce qu’il convient de faire si vous avez accidentellement validé un secret dans votre référentiel ou si vous avez été alerté d’une fuite de secret dans votre référentiel.

Prérequis

• Vous disposez au moins d'un accès en écriture au référentiel.
• Facultatif : Secret scanning est activé pour le référentiel.

  Remarque

  Secret scanning est gratuit pour les référentiels publics. Il est disponible dans le cadre de GitHub Advanced Security pour les référentiels privés sur les plans GitHub Team et GitHub Enterprise Cloud.

Étape 1. Identifier le secret et rassembler le contexte

Collectez autant d’informations que possible sur le secret divulgué. Cela vous aidera à évaluer le risque et à déterminer le meilleur plan d’action pour la correction.

1. Déterminez le type de secret et son fournisseur.
   • Par exemple, le secret est-il { % data variables.product.github %} { % data variables.product.pat_generic %} (PAT), une clé API OpenAI, une clé privée SSH ?
2. Recherchez le référentiel, le fichier et la ligne qui contient le secret divulgué.
3. Identifiez le propriétaire du secret. Il s’agit de la personne ou de l’équipe qui a créé ou est responsable du secret.
   • Vérifiez le fichier CODEOWNERS du référentiel pour déterminer l’équipe responsable.
   • Utilisez git log -S pour rechercher dans l’historique de validation de votre référentiel afin d’identifier qui a validé le secret.

Étape 2. Évaluation des risques

La façon dont vous approchez la correction sera déterminée par les facteurs de risque associés à la fuite de secret.

Secret scanning peut vous aider à évaluer le risque associé à une alerte, mais si vous n'avez pas encore activé secret scanning, vous pouvez tout de même effectuer une évaluation des risques en vous basant sur les informations dont vous disposez.

Option 1. Secret scanning est activé

Examinez l'alerte secret scanning associée à la fuite, en vérifiant les étiquettes d'alerte et toutes les métadonnées disponibles :

1. Vérifiez l’état de validité du secret pour déterminer si le secret est toujours actif. L'alerte inclura un statut indiquant si le secret est actif, inactif ou si sa validité est inconnue.

   Remarque

   • Les vérifications de validité sont uniquement disponibles pour certains types de secrets. Pour vérifier si votre type de secret est pris en charge, consultez Modèles d’analyse de secrets pris en charge.
   • Le fournisseur de secrets est toujours la source de vérité la plus fiable pour déterminer la validité d’un secret.
2. Recherchez l’étiquette public exposure pour déterminer si le secret a été divulgué dans un référentiel public.
3. Recherchez l’étiquette multiple leaks pour déterminer si le secret est exposé à plusieurs emplacements.
4. Si le secret est un pat { % data variables.product.github %}, vérifiez les **métadonnées d’alerte ** pour obtenir des informations sur le moment où le secret a été utilisé pour la dernière fois et son étendue d’accès.
5. Évaluez les services ou applications qui dépendent du secret et tenez compte du risque de temps d’arrêt ou d’interruption si vous deviez révoquer immédiatement le secret.

Option 2. Secret scanning n'est pas activé

Si vous n'avez pas encore activé secret scanning pour le référentiel, effectuez une évaluation des risques en vous basant sur les éléments suivants :

1. Vérifiez la visibilité du référentiel. Le référentiel est-il public ?
2. Recherchez des indications indiquant que le secret a été utilisé récemment. Existe-t-il des validations récentes ou des demandes de tirage qui font référence au secret ? Existe-t-il des journaux d’activité ou des pistes d’audit qui indiquent le secret utilisé ?
3. Évaluez le fichier contenant le secret et le contexte environnant. Le secret est-il utilisé dans un script de déploiement de production (risque plus élevé) ou un fichier de test (risque inférieur) ? Le secret est-il associé à des informations d’identification de base de données ou à une clé d’administration (risque plus élevé) ?
4. Évaluez les services ou applications qui dépendent du secret et tenez compte du risque de temps d’arrêt ou d’interruption si vous deviez révoquer immédiatement le secret.

Étape 3. Mise en place de la mise à jour de la stratégie

L’étape suivante dépend de l’évaluation des risques que vous avez effectuée à l’étape précédente.

Agir rapidement pour les secrets à haut risque

Les scanneurs automatisés peuvent localiser les secrets exposés publiquement en quelques minutes. Ils peuvent être exploités par des acteurs malveillants en quelques heures. Plus un secret actif est exposé, plus le risque de violations graves est élevé.

Si le secret présente un risque élevé (autrement dit, si le secret est toujours actif, s’il est exposé dans un référentiel public ou s’il s’agit d’informations d’identification de production), nous vous recommandons de :

1. Hiérarchiser la révocation immédiate du secret. Consultez l’étape 4.

   Remarque

   Si vous vous inquiétez des temps d’arrêt des services, vous souhaiterez peut-être d’abord générer un nouveau secret avec les mêmes autorisations, faire en sorte que l’application commence à utiliser le nouveau jeton, puis révoquer l’ancien secret.

2. Communiquez avec le propriétaire du secret (identifié à l’étape 1), les administrateurs de référentiel et les prospects de sécurité pendant ou après révocation.

Planifier des secrets à risque moyen à faible

Si le secret présente un risque moyen à faible (autrement dit, si le secret n’est plus actif, s’il est exposé dans un référentiel privé ou s’il s’agit d’informations d’identification de test ou de développement), vous pouvez planifier la stratégie de correction en conséquence :

1. À l’aide des informations collectées à l’étape 1, recherchez l’équipe responsable du secret et avertissez-la de la fuite du secret.
2. Expliquer ce qui a été divulgué et quand. Expliquez que vous devez révoquer le secret, générer un nouveau secret et que les services concernés nécessiteront une mise à jour.
3. Informez les administrateurs du référentiel et les responsables de la sécurité de la fuite, en expliquant les actions de correction nécessaires ou déjà effectuées.
4. Planifiez une période de révocation et de rotation avec l’équipe appropriée pour coordonner une transition en douceur.

Il est important de corriger même les secrets à risque moyen à faible, car ils peuvent toujours présenter un risque pour la sécurité et la conformité s’ils restent exposés.

Étape 4. Révoquer le partage

Il ne suffit pas de supprimer simplement le secret de votre code base. L’étape de correction la plus importante consiste à révoquer le secret avec le fournisseur du secret. En révoquant le secret, vous réduisez considérablement le risque d’exploitation du secret.

1. À l’aide des informations collectées à l’étape 1, recherchez le site web ou la documentation du fournisseur de secrets.

2. Suivez les instructions du fournisseur pour révoquer le secret. Cela implique généralement de se connecter au portail du fournisseur et d’accéder à la section où le secret est géré.

   Si vous n’avez pas accès au portail du fournisseur, contactez le propriétaire du secret ou l’administrateur du référentiel approprié pour obtenir de l’aide sur la révocation du secret.

3. Générez un nouveau secret, si nécessaire, pour remplacer le secret révoqué. Cela est souvent nécessaire pour restaurer les fonctionnalités des services qui s’appuyaient sur le secret d’origine.

Étape  5 : Identifier et mettre à jour les services affectés

Ensuite, vous devez coordonner les mises à jour de tous les services concernés à l’aide du secret divulgué et les mettre à jour avec le nouveau secret.

Identifier

1. Utilisez la recherche de code de GitHub pour vérifier tout le code, les problèmes et les demandes d'extraction pour le secret.
   • Effectuez une recherche dans toute votre organisation à l'aide de org:YOUR-ORG "SECRET-STRING".
   • Effectuez une recherche dans votre référentiel à l’aide de repo:YOUR-REPO "SECRET-STRING".
2. Vérifiez les clés de déploiement stockées du référentiel, ainsi que les secrets et les variables.
   • Cliquez sur « Paramètres », puis sous « Sécurité », cliquez sur secrets et variables ou Déployer des clés.
3. Vérifiez si des GitHub Apps et des intégrations susceptibles d'utiliser le secret sont installées.

Coordonnée

1. Demandez à Copilot de créer des tickets (et des sous-tickets) pour chaque tâche impliquée dans la mise à jour d'un service concerné.
2. Si plusieurs parties prenantes sont impliquées, créez un tableau de projet pour les problèmes afin de suivre la progression et de faciliter la communication.

Mettre à jour et vérifier

1. Mettez à jour votre application avec le nouveau secret, en veillant à ce que votre application utilise correctement les nouvelles informations d’identification.

   Conseil

   Un coffre constitue un moyen sûr de fournir des informations d’identification sensibles à votre application. Par exemple, vous pouvez rendre les informations d'identification sensibles disponibles pour les actions et les flux de travail GitHub via le magasin « Secrets et variables » dans la page des paramètres de votre référentiel.

2. Testez les services affectés pour vous assurer qu’ils fonctionnent correctement avec le nouveau secret.

Étape 6. Vérifier s'il y a eu un accès non autorisé

Une fois que les services sont de nouveau opérationnels, il est important de rechercher tout accès non autorisé qui a pu se produire pendant l’exposition du secret.

1. Consultez les journaux d'audit de GitHub pour les événements liés au secret et à son utilisation.

   • Journal de sécurité pour votre compte personnel. Consultez Examen de votre journal de sécurité.
   • Journal d'audit pour votre organisation. Consultez Examen du journal d’audit de votre organisation.
   • Journal d'audit pour votre entreprise. Consultez Événements du journal d’audit pour votre entreprise.

   Pour les journaux d’audit au niveau de l’organisation et de l’entreprise, vous pouvez rechercher spécifiquement des événements liés à un jeton d’accès. Consultez Identification des événements du journal d’audit effectués par un jeton d’accès (organisations) et Identification des événements du journal d’audit effectués par un jeton d’accès (entreprises).

   L'accès aux journaux d'audit de GitHub dépend de votre rôle. Si vous ne disposez pas des autorisations nécessaires, vous devrez peut-être contacter le propriétaire de l'organisation ou l'administrateur de l'entreprise.

2. Passez en revue les journaux d’audit du fournisseur de secrets.

   • Par exemple, pour les secrets Amazon Web Services (AWS), vous pouvez vérifier dans les journaux CloudTrail les tentatives d’accès non autorisées à l’aide du secret divulgué. Voir Qu’est-ce qu’AWS CloudTrail ? dans la documentation AWS CloudTrail.

Étape 7. Nettoyer le référentiel

Bien que vous ayez maintenant révoqué et mis à jour le secret dans votre code base, il se peut que le secret existe toujours dans l’historique de validation de votre référentiel. Dans l’idéal, vous devez rechercher et supprimer toutes les instances du secret de votre référentiel.

Toutefois, le nettoyage de l’historique Git peut être un processus destructeur et perturbateur, car il peut impliquer l’envoi forcé de modifications au référentiel.

En plus des prospects de sécurité de votre référentiel, tenez compte des effets du nettoyage de l’historique du référentiel par rapport à vos obligations de conformité ou de sécurité. Consultez Suppression de données sensibles dans un dépôt.

Étape 8 : Résoudre l'alerte

1. Fermez l’alerte { % data variables.product.prodname_secret_scanning %} dans le référentiel en sélectionnant Fermer comme et en marquant l’alerte comme « Révoqué ».
2. Documentez l’incident dans la base de connaissances ou le système de gestion des incidents de votre équipe, y compris les étapes prises pour corriger la fuite et les leçons apprises.

Étape 9. Empêcher d'autres fuites

La gestion des fuites de secrets est souvent perturbatrice, compliquée et fastidieuse. La gestion des secrets doit toujours se concentrer sur empêcher les fuites à tout prix :

1. Assurez-vous que la protection push (qui fait partie de GitHub Advanced Security) est activée pour le référentiel, si ce n'est déjà fait. Explorez l’implémentation de contrôles de contournement stricts afin que seuls les utilisateurs approuvés puissent contourner la protection push. Consultez À propos de la protection push.
2. Assurez-vous que la « protection push pour les utilisateurs » est activée sur votre compte personnel, ce qui vous empêche d’envoyer accidentellement des secrets pris en charge à n’importe quel référentiel public.
3. Recommandez ou implémentez les meilleures pratiques pour la gestion des secrets au sein de votre équipe ou organisation :
   • Utilisez des variables d’environnement pour stocker des secrets au lieu de les coder en dur dans la base de code.
   • Utilisez des outils de gestion des secrets tels que le magasin « Secrets et variables » de GitHub dans la page des paramètres de votre référentiel pour stocker et gérer vos secrets en toute sécurité.
   • Effectuez régulièrement une rotation des secrets pour réduire l’impact des fuites potentielles.
4. Documentez les incidents et les étapes de correction pour aider votre équipe à apprendre des erreurs passées et à améliorer les pratiques futures.
5. Recommandez et effectuez des formations régulières sur la sécurité et l’apprentissage. Voir, par exemple, GitHub Cours sur la sécurité avancée proposé par Microsoft Learn.

Pour aller plus loin

• À propos de l’analyse des secrets
• À propos de la protection push
• Modèles d’analyse de secrets pris en charge
• À propos de GitHub Advanced Security