Corriger une exposition de secret dans votre référentiel

Présentation

Les secrets, comme les clés API, les jetons ou les informations d’identification, peuvent constituer des risques de sécurité majeurs pour votre équipe et votre organisation lorsqu’ils sont exposés par erreur dans votre base de code ou conservés de façon inadéquate.

Tout secret révélé doit être considéré comme compromis sans délai, et il est impératif de mettre en œuvre les mesures correctives nécessaires, notamment la révocation du secret concerné. Supprimer le secret du code source, pousser un nouveau commit ou supprimer puis recréer le référentiel ne suffit pas à empêcher son exploitation.

Ce didacticiel décrit la procédure à suivre lorsque vous avez accidentellement validé un secret dans votre référentiel ou que vous avez été averti d’une exposition de secret dans celui-ci.

Prerequisites

• Vous devez disposer au minimum 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 dépôts publics. Il est disponible dans GitHub Secret Protection pour les dépôts privés avec les forfaits GitHub Team et GitHub Enterprise Cloud.

Étape 1. Identifier le secret et rassembler les informations contextuelles

Collectez autant d’éléments que possible concernant le secret exposé. Ces informations vous permettront d’évaluer le niveau de risque et de définir la stratégie de correction la plus appropriée.

1. Identifiez la nature du secret ainsi que son fournisseur.
   • Par exemple, le secret est-il un GitHubpersonal access token (PAT), une clé API OpenAI, une clé privée SSH ?
2. Repérez le référentiel, le fichier et la ligne où figure le secret exposé.
3. Déterminez le propriétaire du secret. Il s’agit de la personne ou de l’équipe à l’origine du secret ou responsable de son utilisation.
   • Consultez le fichier CODEOWNERS du référentiel afin d’identifier l’équipe en charge.
   • Utilisez git log -S pour analyser l’historique des commits du référentiel et identifier l’auteur de l’ajout du secret.

Étape 2. Évaluation des risques

La méthode de correction dépendra des facteurs de risque associés à l’exposition du secret.

Secret scanning peut vous aider à évaluer le risque associé à une alerte, mais si vous n’avez secret scanning pas encore activé, vous pouvez toujours effectuer une évaluation des risques en fonction des informations disponibles.

Option numéro 1.

Secret scanning est activé

Passez en revue l’alerte secret scanning associée à la fuite, en vérifiant les étiquettes d’alerte et les métadonnées disponibles :

1. Vérifiez l’état de validité du secret afin de déterminer s’il est toujours actif. L’alerte comportera un état indiquant si le secret est actif, inactif ou si son statut de validité ne peut pas être déterminé.

   Remarque

   • Les contrôles de validité ne sont proposés que pour certaines catégories de secrets. Afin de savoir si votre type de secret est pris en charge, consultez Modèles de détection de secrets pris en charge.
   • Le fournisseur du secret demeure la référence la plus fiable pour établir la validité d’un secret.
2. Examinez l’étiquette public exposure afin de déterminer si le secret a été divulgué dans un dépôt public.
3. Analysez l’étiquette multiple leaks afin d’identifier si le secret est exposé à plusieurs emplacements.
4. Si le secret est un GitHub PAT, vérifiez les métadonnées de l’alerte pour obtenir des informations sur la dernière utilisation du secret et sa portée d’accès.
5. Analysez les services ou applications dépendant du secret et prenez en compte le risque d’indisponibilité ou de perturbation en cas de révocation immédiate.

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 sur la base des éléments suivants :

1. Vérifiez le niveau de visibilité du référentiel. Le référentiel est-il accessible publiquement ?
2. Recherchez des indices indiquant une utilisation récente du secret. Existe-t-il des commits ou des pull requests récents faisant référence au secret ? Existe-t-il des journaux d’activité ou des pistes d’audit attestant de l’utilisation du secret ?
3. Analysez le fichier contenant le secret ainsi que son contexte. Le secret est-il utilisé dans un script de déploiement en production (risque plus élevé) ou dans un fichier de test (risque plus faible) ? Le secret est-il lié à des identifiants de base de données ou à une clé d’administration (risque plus élevé) ?
4. Analysez les services ou applications dépendant du secret et prenez en compte le risque d’indisponibilité ou de perturbation en cas de révocation immédiate.

Étape 3. Définissez une stratégie de remédiation

L’étape suivante dépend directement de l’évaluation des risques réalisée précédemment.

Intervenez rapidement pour les secrets à risque élevé

Les outils de scan automatisés peuvent détecter des secrets exposés publiquement en l’espace de quelques minutes. Ces secrets peuvent être exploités par des acteurs malveillants en quelques heures. Plus un secret actif reste exposé longtemps, plus le risque de compromissions graves augmente.

Si le secret présente un niveau de risque élevé (c’est-à-dire s’il est toujours actif, exposé dans un référentiel public ou s’il correspond à un identifiant de production), il est recommandé de :

1. Prioriser la révocation immédiate du secret. Voir l’Étape 4.

   Remarque

   En cas de crainte d’interruption de service, il est possible de générer au préalable un nouveau secret disposant des mêmes autorisations, de configurer l’application pour utiliser ce nouveau jeton, puis de révoquer l’ancien secret.

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

Planifier la gestion des secrets à risque faible ou modéré

Si le secret présente un risque faible à modéré (c’est-à-dire qu’il n’est plus actif, qu’il est exposé dans un référentiel privé ou qu’il correspond à un identifiant de test ou de développement), la stratégie de remédiation peut être planifiée en conséquence :

1. À partir des informations collectées à l’étape 1, identifiez l’équipe responsable du secret et informez-la de la fuite.
2. Décrivez précisément la nature des informations divulguées ainsi que le moment auquel la divulgation s’est produite. Précisez que le secret devra être révoqué, qu’un nouveau secret devra être généré et que les services concernés devront être mis à jour en conséquence.
3. Avertissez les administrateurs du référentiel ainsi que les responsables de la sécurité de la fuite, en détaillant les mesures correctives nécessaires ou déjà mises en œuvre.
4. Fixez, en concertation avec l’équipe appropriée, une date de révocation et de rotation afin d’assurer une transition coordonnée et sans interruption.

Il est essentiel de traiter également les secrets présentant un risque moyen ou faible, car leur exposition prolongée peut toujours engendrer des risques en matière de sécurité et de conformité.

Étape 4. Révoquez le secret

Le simple retrait du secret de la base de code est insuffisant. L’action corrective prioritaire consiste à révoquer le secret auprès de son fournisseur. La révocation du secret permet de réduire de manière significative le risque d’exploitation.

1. À partir des informations collectées à l’étape 1, identifiez le site web ou la documentation du fournisseur du secret.

2. Appliquez les instructions fournies par le fournisseur afin de procéder à la révocation du secret. Cette démarche nécessite généralement une connexion au portail du fournisseur et l’accès à la section dédiée à la gestion des secrets.

   En l’absence d’accès au portail du fournisseur, contactez le propriétaire du secret ou l’administrateur du référentiel concerné afin d’obtenir l’assistance nécessaire à la révocation.

3. Si requis, générez un nouveau secret destiné à remplacer celui qui a été révoqué. Cette étape est souvent indispensable pour rétablir le fonctionnement des services dépendant du secret initial.

Étape 5 : Identifiez et mettez à jour les services concernés

Vous devez ensuite coordonner la mise à jour de l’ensemble des services affectés utilisant le secret divulgué et les configurer avec le nouveau secret.

Identify

1. Utilisez la fonctionnalité de recherche de code de GitHub pour rechercher le secret dans l’ensemble du code, des tickets et des pull requests.
   • Effectuez une recherche à l’échelle de votre organisation à l’aide de org:YOUR-ORG "SECRET-STRING"
   • Effectuez une recherche au sein de votre référentiel à l’aide de repo:YOUR-REPO "SECRET-STRING".
2. Examinez les clés de déploiement, les secrets et les variables enregistrés dans le référentiel.
   • Sélectionnez « Paramètres », puis, dans la section « Sécurité », cliquez sur Secrets et variables ou Clés de déploiement.
3. Vérifiez si des GitHub Apps installés et des intégrations peuvent utiliser le secret.

Coordinate

1. Demandez Copilot à créer des problèmes (et des sous-problèmes) pour chaque tâche impliquée dans la mise à jour d’un service affecté. Voir Utilisation de GitHub Copilot pour créer ou mettre à jour des problèmes.
2. Lorsque plusieurs parties prenantes sont impliquées, mettez en place un tableau de projet associé aux problèmes afin de suivre l’avancement et de faciliter la communication.

Mettre à jour et vérifier

1. Mettez à jour votre application avec le nouveau secret en veillant à ce que les nouvelles informations d’identification soient correctement utilisées.

   Conseil

   L’utilisation d’un coffre-fort constitue une méthode sécurisée pour fournir des identifiants sensibles à votre application. Par exemple, vous pouvez mettre des identifiants sensibles à la disposition des GitHub actions et workflows dans la section « Secrets and variables » de la page Paramètres de votre dépôt.

2. Testez l’ensemble des services concernés afin de confirmer leur bon fonctionnement avec le nouveau secret.

Étape 6. Assurez-vous qu’aucun accès non autorisé n’est observé

Une fois les services rétablis, il est indispensable de vérifier si des accès non autorisés ont pu avoir lieu pendant la période où le secret était exposé.

1. Passez en revue les journaux d’audit de GitHub pour les événements concernant le secret et son utilisation.

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

   Pour les journaux d’activité au niveau de l’organisation et de l’entreprise, il est possible de cibler spécifiquement les événements associés à un jeton d’accès. Reportez-vous à 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 GitHubjournaux d’audit dépend de votre rôle. Vous devrez peut-être contacter un propriétaire de l’organisation ou un administrateur d’entreprise si vous n’avez pas les autorisations nécessaires.

2. Contrôlez les journaux d’activité du fournisseur de secrets.

   • Par exemple, pour les secrets Amazon Web Services (AWS), vous pouvez examiner les journaux CloudTrail afin d’identifier toute tentative d’accès non autorisée utilisant le secret compromis. Consultez la section « Qu’est-ce qu’AWS CloudTrail ? » dans la documentation AWS CloudTrail.

Étape 7. Nettoyez le référentiel

Même si le secret a désormais été révoqué et remplacé dans votre base de code, il peut encore être présent dans l’historique des commits de votre référentiel. Dans l’idéal, vous devriez rechercher et supprimer toutes les occurrences du secret dans le référentiel.

Toutefois, le nettoyage de l’historique Git peut constituer un processus destructeur et perturbant, car il peut nécessiter une poussée forcée des modifications vers le référentiel.

En collaboration avec les responsables de la sécurité du référentiel, évaluez attentivement les conséquences du nettoyage de l’historique sur vos exigences de conformité ou de sécurité. Consultez Suppression de données sensibles dans un dépôt.

Étape 8 : Résolvez l’alerte

1. Fermez l’alerte secret scanning du dépôt en sélectionnant Marquer comme fermée et en marquant l’alerte comme « Révoquée ».
2. Consignez l’incident dans la base de connaissances ou le système de gestion des incidents de votre équipe, en détaillant les actions menées pour corriger la fuite ainsi que les enseignements tirés.

Étape 9. Prévenez de nouvelles fuites

La gestion des fuites de secrets s’avère souvent perturbante, complexe et chronophage. La gestion des secrets doit systématiquement viser à prévenir toute fuite :

1. Vérifiez que la protection push (partie de GitHub Secret Protection) est activée pour le référentiel, si ce n’est pas déjà fait. Envisagez la mise en place de contrôles de contournement stricts, afin que seuls des utilisateurs de confiance puissent contourner la protection push. Consultez Protection contre les notifications push.
2. Assurez-vous que la fonctionnalité « Protection push pour les utilisateurs » est activée sur votre compte personnel, ce qui vous protège contre l’envoi accidentel de secrets pris en charge vers tout référentiel public.
3. Encouragez ou mettez en œuvre les meilleures pratiques de gestion des secrets au sein de votre équipe ou de votre organisation :
   • Utilisez des variables d’environnement pour stocker les secrets plutôt que de les intégrer en dur dans la base de code.
   • Utilisez des outils de gestion des secrets tels que GitHuble magasin « Secrets et variables » sous la page des paramètres de votre référentiel pour stocker et gérer les secrets en toute sécurité.
   • Faites régulièrement tourner les secrets afin de réduire l’impact potentiel de toute fuite.
4. Consignez les incidents et les mesures correctives pour permettre à votre équipe de tirer parti des erreurs passées et d’améliorer les pratiques à venir.
5. Encouragez et organisez régulièrement des actions de formation et de sensibilisation à la sécurité. Consultez, par exemple, GitHub Advanced Security cours de Microsoft Learn.