Phase 6 : Déployer et mettre à l’échelle l’analyse des secrets

Vous pouvez activer l’analyse des secrets pour des référentiels individuels ou pour tous les référentiels d’une organisation ou d’une entreprise. Pour plus d’informations, consultez « Gestion des paramètres de sécurité et d’analyse pour votre dépôt », « Gestion des paramètres de sécurité et d'analyse pour votre organisation » ou « Gestion des fonctionnalités GitHub Advanced Security pour votre entreprise ».

Vous pouvez rapidement activer des fonctionnalités de sécurité à grande échelle avec la GitHub-recommended security configuration, une collection de paramètres d’activation de sécurité que vous pouvez appliquer aux référentiels d’une organisation. Vous pouvez ensuite personnaliser davantage les fonctionnalités de GitHub Advanced Security au niveau de l’organisation avec les global settings. Consultez « À propos de l'activation des fonctionnalités de sécurité à grande échelle ».

Cet article décrit un processus de haut niveau axé sur l’activation de l’secret scanning pour tous les dépôts d’une organisation. Les principes décrits dans cet article peuvent toujours être appliqués même si vous utilisez une approche plus échelonnée de l’activation de l’secret scanning pour des dépôts individuels.

1. Se concentrer sur les secrets nouvellement commités

Lorsque vous activez l’secret scanning, vous devez vous concentrer sur la correction des informations d’identification nouvellement commitées détectées par l’analyse des secrets. Si vous vous concentrez sur le nettoyage des informations d’identification commitées, les développeurs pourraient continuer à pousser accidentellement de nouvelles informations d’identification, ce qui signifie que votre quantité totale de secrets resterait autour du même niveau, et ne diminuerait pas comme prévu. C’est pourquoi il est essentiel d’empêcher la fuite des nouvelles informations d’identification avant de se concentrer sur la révocation des secrets actuels.

Il existe quelques approches pour traiter les informations d’identification nouvellement commitées. Voici un exemple de l’une de ces approches :

1. Notifier : utilisez des webhooks pour veiller à ce que les nouvelles alertes de secret soient vues par les bonnes équipes le plus rapidement possible. Un webhook se déclenche lorsqu’une alerte de secret est créée, résolue ou rouverte. Vous pouvez ensuite analyser la charge utile de webhook, et l’intégrer aux outils que votre équipe et vous-même utilisez, par exemple Slack, Teams, Splunk ou e-mail. Pour plus d’informations, consultez « À propos des webhooks » et « Événements et charges utiles du webhook ».

2. Suivi : Créez un processus général de correction qui fonctionne pour tous les types de secrets. Par exemple, vous pourriez contacter le développeur qui a commité le secret et son responsable technique sur ce projet, en mettant en évidence les dangers liés au commit des secrets sur GitHub, et en leur demandant de révoquer et de mettre à jour le secret détecté.

   Remarque : Vous pouvez automatiser cette étape. Pour les grandes entreprises et les organisations ayant des centaines de dépôts, le suivi manuel n’est pas réalisable. Vous pourriez incorporer l’automatisation dans le processus de webhook défini à la première étape. La charge utile de webhook contient des informations sur le dépôt et l’organisation concernant le secret fuité. À l’aide de ces informations, vous pouvez contacter les chargés de maintenance actuels sur le dépôt, et créer un e-mail/message destiné aux personnes responsables ou signaler un problème.

3. Éduquer : créez un document de formation interne affecté au développeur qui a commité le secret. Dans ce document de formation, vous pouvez expliquer les risques créés par le commit des secrets, et diriger le développeur vers vos bonnes pratiques en matière d’utilisation sécurisée des secrets lors du développement. Si un développeur n’apprend pas de cette expérience et continue à valider des secrets, vous pourriez créer un processus d’escalade, mais l’éducation fonctionne généralement bien.

Répétez les deux dernières étapes pour toute nouvelle fuite de secrets. Ce processus encourage les développeurs à assumer la responsabilité de la gestion des secrets utilisés dans leur code de manière sécurisée, et vous permet de mesurer la réduction des secrets nouvellement commités.

2. Activer la protection push

Une fois que vous avez activé secret scanning, vous devez également activer la protection push. Avec la protection push, secret scanning vérifier les envois (push) pour les secrets pris en charge et bloque les envois (push) vers GitHub avant que les secrets ne soient exposés à d’autres utilisateurs. Pour plus d’informations sur l’activation de la protection push, consultez « Activation de la protection push pour votre référentiel ».

Une fois activée, vous pouvez effectuer les opérations suivantes :

1. Fournir des conseils : configurez un lien personnalisé dans le message que les contributeurs verront si leur push est bloqué par secret scanning. La ressource liée peut fournir des conseils pour les contributeur sur la résolution du push bloqué. Pour plus d’informations, consultez « Activation de la protection push pour votre référentiel ».

2. Notification : définissez un webhook qui suit spécifiquement un Alertes d’analyse de secrets créé lorsque quelqu’un contourne la protection push à l’aide de la propriété d’alerte "push_protection_bypassed": true. Vous pouvez également utiliser l’API pour obtenir des mises à jour sur les Alertes d’analyse de secrets qui ont fait l’objet d’un contournement de la protection push en filtrant la liste des résultats pour "push_protection_bypassed": true. Pour plus d’informations, consultez « Audit des alertes de sécurité ».

3. Surveiller : utilisez la vue d’ensemble de la sécurité pour afficher les métriques sur la façon dont la protection push s’effectue dans les référentiels de votre organisation, afin de pouvoir identifier rapidement les référentiels où vous devrez peut-être prendre des mesures. Pour plus d’informations, consultez « Affichage des mesures pour la protection par poussée de l'analyse secrète ».

3. Corriger les secrets précédemment commités, en commençant par le plus critique

Une fois que vous avez établi un processus pour réduire l’ajout de secrets à vos codebases, vous êtes prêt à commencer à corriger les secrets qui ont été validés avant d’introduire GitHub Advanced Security.

La façon dont vous définissez vos secrets les plus critiques dépend des processus et des intégrations de votre organisation. Par exemple, une entreprise ne se souciera probablement pas d’un secret relatif à un webhook entrant Slack si elle n’utilise pas Slack. Vous trouverez peut-être utile de commencer par vous concentrer sur les cinq principaux types d’informations d’identification critiques pour votre organisation.

Une fois que vous avez choisi les types de secrets, vous pouvez effectuer les opérations suivantes :

1. Définissez un processus pour corriger chaque type de secret. La procédure réelle pour chaque type de secret est souvent radicalement différente. Notez le processus pour chaque type de secret dans un document ou une base de connaissances interne.

   Remarque : Lorsque vous créez le processus de révocation de secrets, essayez d’attribuer la responsabilité de la révocation des secrets à l’équipe qui tient à jour le dépôt plutôt qu’à une équipe centrale. L’un des principes de GHAS est que les développeurs doivent assumer la possession de la sécurité et la responsabilité de la résolution des problèmes de sécurité, en particulier s’ils les ont créés.

2. Une fois que vous avez créé le processus que les équipes suivront pour révoquer les informations d’identification, vous pouvez collecter des informations sur les types de secrets et d’autres métadonnées associées aux secrets fuités afin de pouvoir identifier à qui communiquer le nouveau processus.

   Vous pouvez utiliser Vue d’ensemble de la sécurité pour collecter ces informations. Pour plus d’informations sur l’utilisation de la vue d’ensemble de la sécurité, consultez « Filtrage des alertes dans la vue d’ensemble de la sécurité ».

   Voici quelques informations que vous souhaiterez peut-être collecter :

   • Organisation
   • Référentiel
   • Type de secret
   • Valeur du secret
   • Chargés de maintenance sur le dépôt à contacter

   Remarque : Utilisez l’interface utilisateur si vous avez peu de secrets fuités de ce type. Si vous avez des centaines de secrets fuités, utilisez l’API pour collecter des informations. Pour plus d’informations, consultez « Points de terminaison d’API REST pour l’analyse de secrets ».

3. Après avoir collecté des informations sur les secrets fuités, créez un plan de communication ciblé pour les utilisateurs qui tiennent à jour les dépôts affectés par chaque type de secret. Vous pouvez utiliser l’e-mail, la messagerie, ou même créer des problèmes GitHub dans les dépôts affectés. Si vous pouvez utiliser des API fournies par ces outils pour envoyer les communications de manière automatisée, cela vous simplifiera la mise à l’échelle entre plusieurs types de secrets.

4. Étendre le programme afin d’inclure davantage de types de secrets et de modèles personnalisés

Vous pouvez maintenant aller au-delà des cinq types de secrets les plus critiques afin de créer une liste plus exhaustive, avec un focus supplémentaire sur l’éducation. Vous pouvez répéter l’étape précédente, en corrigeant les secrets précédemment commités, pour les différents types de secrets ciblés.

Vous pouvez également inclure davantage de modèles personnalisés compilés lors des phases antérieures, et inviter les équipes de sécurité et les équipes de développement à soumettre davantage de modèles, en établissant un processus de soumission de nouveaux modèles à mesure que de nouveaux types de secrets sont créés. Pour plus d’informations, consultez « Définition de modèles personnalisés pour l’analyse des secrets ».

À mesure que vous continuez à créer vos processus de correction pour d’autres types de secrets, commencez à créer du matériel de formation proactif qui peut être partagé avec tous les développeurs de GitHub dans votre organisation. Jusqu’à ce stade, une grande partie du focus a porté sur la réactivité. Ce serait maintenant une excellente idée de mettre l’accent sur l’aspect proactif, et d’encourager les développeurs à ne pas du tout pousser d’informations d’identification vers GitHub. Cela peut être réalisé de plusieurs façons, mais la création d’un court document expliquant les risques et les raisons serait un excellent point de départ.