Ce guide part du principe que vous avez planifié et démarré une version d’évaluation de GitHub Advanced Security pour un compte d’entreprise, qu'il soit existant ou d'essai GitHub. Consultez Planification d’un essai de GitHub Advanced Security.
Présentation
GitHub Secret Protection les fonctionnalités 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 les fonctionnalités supplémentaires 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 pour la protection push et Alertes de détection de secrets.
- Activez les vérifications de validité pour les jetons exposés.
- Créez des campagnes de sécurité où les spécialistes de la sécurité et les développeurs peuvent collaborer pour réduire efficacement la dette technique.
Pour savoir comment exécuter une évaluation gratuite des risques de secret, consultez Génération d’une évaluation initiale des risques secrets dans la GitHub Enterprise Cloud documentation.
Si vous avez déjà analysé le code de votre organisation pour rechercher des secrets divulgués à l’aide de l’évaluation gratuite des risques secrets, vous souhaiterez également explorer ces données de manière plus complète à l’aide des vues supplémentaires sous l’onglet Security and quality de l’organisation.
Pour plus d’informations sur les fonctionnalités disponibles, consultez GitHub Secret Protection.
Configuration de sécurité pour Secret Protection
La plupart des entreprises choisissent d’activer Secret Protection la protection push sur 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 contrôlés pour les jetons d’accès qui ont déjà été ajoutés à GitHub, et de signaler lorsque les utilisateurs sont sur le point de divulguer des 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 l’accès pour afficher les résultats de secret scanning
Par défaut, seul l’administrateur du référentiel et le propriétaire de l’organisation peuvent afficher toutes les secret scanning alertes dans leur zone. 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 dans l'essai. 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’évaluation dans l’onglet Security and quality Entreprise. Il existe également des vues distinctes pour chaque type d'alerte de sécurité. Consultez Affichage des aperçus 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 schémas personnalisés, secret scanning et la protection push incluent automatiquement les nouveaux schémas dans tous les scans. 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 d'IA, la fonctionnalité secret scanning et la protection par push commencent toutes deux automatiquement à utiliser la détection d'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 push bloque une transmission (push) vers le référentiel public GitHub en l'absence de GitHub Secret Protection, l’utilisateur dispose de deux options simples : ignorer le contrôle ou supprimer le contenu mis en surbrillance de la branche ainsi que de son historique. S’ils ont choisi de contourner la protection push, une secret scanning alerte 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 pour contourner la protection contre le push, ce qui réduit le risque d'une fuite accidentelle d'un jeton encore actif. Vous pouvez également créer un groupe de réviseurs afin d'approuver les demandes pour rejeter Alertes de détection 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 Activer les vérifications de validité pour votre référentiel dans la GitHub Enterprise Cloud documentation.
Impliquer les développeurs dans la remédiation de la sécurité
Les campagnes de sécurité permettent aux équipes de sécurité de s'engager auprès des développeurs pour remédier à la dette technique en matière de sécurité. Ils constituent également un moyen pratique de combiner une formation sur le stockage secret avec des exemples de secrets exposés que vos développeurs peuvent corriger. Pour plus d’informations, consultez À propos des campagnes de sécurité et Exécution d’une campagne de sécurité pour corriger les alertes à grande échelle dans la GitHub Enterprise Cloud documentation.
É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 plus loin. Vous pouvez également être prêt à examiner les options disponibles avec GitHub Code Security.
-
[AUTOTITLE](/code-security/trialing-github-advanced-security/explore-trial-code-scanning) -
[Appliquer GitHub Advanced Security à grande échelle](https://wellarchitected.github.com/library/application-security/recommendations/enforce-ghas-at-scale/)