Skip to main content

Exploration de votre essai d'entreprise de GitHub Secret Protection

Introduction aux fonctionnalités disponibles avec GitHub Secret Protection dans GitHub Enterprise Cloud afin que vous puissiez évaluer leur adéquation avec les besoins de votre entreprise.

Ce guide suppose que vous avez planifié et démarré un essai de GitHub Advanced Security pour un compte d’entreprise GitHub existant ou en cours d'essai. Consultez Planification d’un essai de GitHub Advanced Security.

Introduction

Les fonctionnalités de GitHub Secret Protection fonctionnent de la même façon dans les référentiels privés et internes que dans tous les référentiels publics. Cet article se concentre sur la fonctionnalité supplémentaire que vous pouvez utiliser pour protéger votre entreprise contre les fuites de sécurité lorsque vous utilisez GitHub Secret Protection, c'est-à-dire :

  • Identifiez les jetons d’accès supplémentaires que vous utilisez en définissant des modèles personnalisés.
  • Détecter les mots de passe potentiels grâce à l'IA.
  • Contrôlez et auditez le processus de contournement de la protection d’envoi (push) et Alertes d’analyse de secrets.
  • Activer les contrôles de validité pour les jetons exposés.

Si vous avez déjà analysé le code de votre organisation à la recherche de fuites de secrets à l’aide de l’évaluation gratuite des risques liés aux secrets, vous voudrez peut-être explorer ces données plus en détail en utilisant les vues supplémentaires de l’onglet Sécurité de l’organisation.

Pour plus d’informations sur les fonctionnalités disponibles, consultez GitHub Secret Protection.

Configuration de la sécurité pour Secret Protection

La plupart des entreprises choisissent d’activer Secret Protection avec la protection d’envoi (push) dans tous leurs référentiels en appliquant des configurations de sécurité avec ces fonctionnalités activées. Cela garantit que les référentiels sont vérifiés pour les jetons d'accès qui ont déjà été ajoutés à GitHub, en plus de signaler lorsque les utilisateurs sont sur le point de fuir les jetons dans GitHub. Pour plus d'informations sur la création d'une configuration de sécurité au niveau de l'entreprise et son application à vos référentiels de test, voir Activation des fonctions de sécurité dans votre entreprise pilote.

Fournir un accès pour visualiser les résultats de secret scanning

Par défaut, seuls l'administrateur du référentiel et le propriétaire de l'organisation peuvent voir toutes les secret scanning alertes dans leur domaine. Vous devez attribuer le rôle prédéfini de responsable de la sécurité à toutes les équipes de l'organisation et à tous les utilisateurs qui doivent avoir accès aux alertes trouvées pendant l'essai. Vous pouvez également attribuer ce rôle au propriétaire du compte d'entreprise pour chaque organisation de la procédure d'évaluation. Pour plus d’informations, consultez « Gestion des gestionnaires de sécurité dans votre organisation ».

Vous pouvez voir un résumé des résultats trouvés dans les organisations de votre entreprise d'essai dans l’onglet Sécurité de l’entreprise. Il existe également des vues distinctes pour chaque type d'alerte de sécurité. Consultez Affichage des insights de sécurité.

Identifier les jetons d'accès supplémentaires

Vous pouvez créer des modèles personnalisés pour identifier des jetons d'accès supplémentaires au niveau du référentiel, de l'organisation et de l'entreprise. Dans la plupart des cas, il est préférable de définir des modèles personnalisés au niveau de l'entreprise, car cela permet de s'assurer que les modèles sont utilisés dans l'ensemble de l'entreprise. Cela facilitera également leur maintenance si vous devez mettre à jour un modèle lorsque le format d'un jeton change.

Une fois que vous avez créé et publié des modèles personnalisés, secret scanning et la protection push incluent automatiquement les nouveaux modèles dans toutes les analyses. Pour plus d'informations sur la création de modèles personnalisés, voir Définition de modèles personnalisés pour l’analyse des secrets.

Utiliser l'IA pour détecter les mots de passe potentiels

Au niveau de l'entreprise, vous pouvez décider d'autoriser ou non l'utilisation de l'IA pour détecter les secrets qui ne peuvent pas être identifiés à l'aide d'expressions régulières (également connus sous le nom de secrets génériques ou de motifs non liés au fournisseur).

  • Activer ou désactiver la fonction pour l'ensemble de l'entreprise.
  • Définir une politique pour bloquer le contrôle de la fonctionnalité au niveau de l'organisation et du référentiel.
  • Définissez une stratégie permettant aux propriétaires de l'organisation ou aux administrateurs du référentiel de contrôler la fonctionnalité.

Comme pour les modèles personnalisés, si vous activez la détection de l'IA, secret scanning et la protection push commencent automatiquement à utiliser la détection de l'IA dans toutes les analyses. Pour plus d'informations sur le contrôle au niveau de l'entreprise, voir Configuration des paramètres d’analyse de secrets supplémentaires pour votre entreprise et Application de stratégies de sécurité et d’analyse du code pour votre entreprise.

Contrôler et auditer le processus de contournement

Lorsque la protection d’envoi (push) bloque un envoi vers GitHub dans un référentiel public sans GitHub Secret Protection, l’utilisateur a deux options simples : contourner le contrôle ou supprimer le contenu mis en évidence de la branche et de son historique. S'ils choisissent de contourner la protection push, une alerte secret scanning est automatiquement créée. Cela permet aux développeurs de débloquer rapidement leur travail tout en fournissant une piste d'audit pour le contenu identifié par secret scanning.

Les grandes équipes souhaitent généralement exercer un contrôle plus strict sur la publication éventuelle de jetons d'accès et d'autres secrets. Avec GitHub Secret Protection, vous pouvez définir un groupe de réviseurs pour approuver les demandes de contournement de la protection d’envoi (push), réduisant ainsi le risque qu'un développeur divulgue accidentellement un jeton encore actif. Vous pouvez également définir un groupe de réviseurs pour approuver les demandes de rejet Alertes d’analyse de secrets.

Les réviseurs sont définis dans une configuration de sécurité au niveau de l'organisation ou dans les paramètres d'un référentiel. Pour plus d’informations, consultez « À propos du contournement délégué pour la protection Push ».

Activer les vérifications de validité

Vous pouvez activer des contrôles de validité pour vérifier si les jetons détectés sont toujours actifs au niveau du référentiel, de l'organisation et de l'entreprise. En général, il vaut la peine d'activer cette fonction dans l'ensemble de l'entreprise en utilisant des configurations de sécurité au niveau de l'entreprise ou de l'organisation. Pour plus d’informations, consultez « Activation des vérifications de validité pour votre référentiel ».

Étapes suivantes

Lorsque vous avez activé les contrôles supplémentaires pour Secret Protection, vous êtes prêt à les tester en fonction des besoins de votre entreprise et à explorer davantage. Vous pouvez également envisager d’explorer les options disponibles avec GitHub Code Security.