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.
• Optionnel : Secret scanning est activé pour le référentiel.

  Remarque

  Secret scanning est gratuit pour les référentiels publics. Il est proposé dans le cadre de GitHub Secret Protection pour les référentiels privés avec les offres 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, s’agit-il d’un GitHub personal access token (PAT), d’une clé API OpenAI ou d’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 contribuer à l’évaluation du risque lié à une alerte, mais en l’absence d’activation de secret scanning, une analyse des risques reste possible à partir des informations disponibles.

Option numéro 1. Secret scanning est activé

Analysez l’alerte secret scanning liée à l’exposition en examinant les étiquettes de l’alerte ainsi que l’ensemble des métadonnées associées.

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 PAT GitHub, consultez les métadonnées de l’alerte pour obtenir des informations relatives à sa dernière utilisation et à l’étendue de ses autorisations 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 secret scanning n’a pas encore été activé pour le référentiel, procédez à une évaluation des risques en tenant compte 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 afin d’examiner l’ensemble du code, des problèmes et des demandes de tirage contenant le secret.
   • 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 ou des intégrations installées sont susceptibles d’utiliser le secret.

Coordinate

1. Demandez à Copilot de créer des problèmes, ainsi que des sous-problèmes, pour chaque tâche liée à la mise à jour d’un service concerné.
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. À titre d’exemple, les identifiants sensibles peuvent être mis à disposition des actions et des workflows GitHub via le magasin « Secrets et variables » accessible depuis la page des paramètres du référentiel.

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. Analysez les journaux d’activité de GitHub afin d’identifier les événements associés au 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 journaux d’activité de GitHub varie selon votre rôle ; il peut donc être nécessaire de contacter le propriétaire de l’organisation ou l’administrateur de l’entreprise si vous ne disposez pas des autorisations requises.

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 dans le référentiel en sélectionnant Fermer en tant que et en la marquant 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 contre les push, incluse dans GitHub Secret Protection, est activée pour le référentiel, si ce n’est pas déjà le cas. Envisagez la mise en place de contrôles de contournement stricts, afin que seuls des utilisateurs de confiance puissent contourner la protection push. Consultez À propos de la protection lors du 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.
   • Appuyez-vous sur des outils de gestion des secrets, tels que l’espace « Secrets et variables » de GitHub disponible dans les paramètres du référentiel, afin de stocker et gérer les secrets de manière sécurisée.
   • 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, le cours GitHub Advanced Security proposé sur Microsoft Learn.

Lectures complémentaires

•         [AUTOTITLE](/code-security/secret-scanning/introduction/about-secret-scanning)
  

•         [AUTOTITLE](/code-security/secret-scanning/introduction/about-push-protection)
  

•         [AUTOTITLE](/code-security/secret-scanning/introduction/supported-secret-scanning-patterns)
  

•         [AUTOTITLE](/get-started/learning-about-github/about-github-advanced-security)