Phase 2 : Préparation à l’activation à grande échelle

Préparation à l’activation code scanning

          Code scanning es une fonctionnalité que vous utilisez pour analyser le code dans un dépôt GitHub afin de détecter d’éventuelles vulnérabilités de sécurité et erreurs de codage. Tous les problèmes identifiés par l’analyse sont énumérés dans votre référentiel. Pour plus d’informations, consultez [AUTOTITLE](/code-security/code-scanning/introduction-to-code-scanning/about-code-scanning).

Le déploiement code scanning sur des centaines de référentiels peut être difficile, surtout lorsqu'il est fait de manière inefficace. Le suivi de ces étapes vous permettra de garantir l’efficacité et le succès de votre déploiement.

Préparation des équipes pour code scanning

Tout d’abord, préparez vos équipes à utiliser code scanning. Plus les équipes utilisent code scanning, plus vous aurez de données pour élaborer des plans de correction et surveiller la progression de votre déploiement.

Pour une introduction à code scanning, consultez : * À propos de l’analyse du code * À propos des alertes d’analyse du code * Évaluation des alertes d’analyse du code pour votre référentiel

Votre objectif principal doit être de préparer code scanning autant d’équipes que possible. Vous pouvez également encourager les équipes à remédier de manière appropriée, mais nous vous recommandons de prioriser l’activation et l’utilisation de code scanning au cours de cette phase, plutôt que de vous concentrer sur la résolution des problèmes.

Activation code scanning de votre appliance

Avant de pouvoir lancer des programmes pilotes et déployer code scanning dans votre entreprise, vous devez d’abord activer code scanning sur votre appareil. Pour plus d’informations, consultez « Configuration de l’analyse de code pour votre appliance ».

Préparation à l’activation secret scanning

Si un projet communique avec un service externe, il se peut qu’il utilise un jeton ou une clé privée pour l’authentification. Si vous archivez un secret dans un dépôt, toute personne disposant d’un accès en lecture au dépôt peut l’utiliser pour accéder au service externe avec vos privilèges. Secret scanning analyse l’intégralité de votre historique Git sur toutes les branches présentes dans vos GitHub référentiels pour détecter les secrets et vous avertir ou bloquer l’envoi (push) contenant le secret. Pour plus d’informations, consultez « À propos de l’analyse des secrets ».

Considérations relatives à l’activation secret scanning

L’activation secret scanning au niveau de l’organisation peut être facile, mais en cliquant sur Activer tout au niveau de l’organisation et en sélectionnant l’option Activer automatiquement secret scanning pour chaque nouveau référentiel , vous devez être conscient des effets en aval suivants :

Consommation de licence

L’activation secret scanning de tous les référentiels optimise votre utilisation des GitHub Secret Protection licences. Cela convient si vous disposez d'un nombre suffisant de licences pour tous les contributeurs actuels de ces dépôts. Si le nombre de développeurs actifs est susceptible d’augmenter au cours des prochains mois, vous pouvez dépasser votre limite de licences, puis ne pas pouvoir utiliser secret scanning sur les dépôts nouvellement créés.

Volume initial élevé de secrets détectés

Si vous activez secret scanning dans une grande organisation, préparez-vous à découvrir un grand nombre de secrets. Parfois, cela provoque un choc pour les organisations et l’alarme est déclenchée. Si vous souhaitez activer secret scanning dans tous les référentiels à la fois, préparez-vous à répondre à plusieurs alertes au sein de l’organisation.

          Secret scanning peut être activé pour les dépôts individuels. Pour plus d’informations, consultez « [AUTOTITLE](/code-security/secret-scanning/enabling-secret-scanning-features/enabling-secret-scanning-for-your-repository) ». 
          Secret scanning peut également être activé pour tous les dépôts de votre organisation, comme décrit ci-dessus. Pour plus d’informations sur l’activation pour tous les référentiels, consultez [AUTOTITLE](/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization/managing-security-and-analysis-settings-for-your-organization).

Modèles personnalisés pour secret scanning

          Secret scanning détecte un grand nombre de modèles par défaut, mais peut également être configuré pour détecter des modèles personnalisés, tels que des formats secrets uniques à votre infrastructure ou utilisés par les intégrateurs qui GitHubne secret scanning détectent pas actuellement. Pour plus d’informations sur les secrets pris en charge pour les modèles de partenariat, consultez [AUTOTITLE](/code-security/secret-scanning/introduction/supported-secret-scanning-patterns).

Lorsque vous auditez vos référentiels et parlez aux équipes de sécurité et de développement, créez une liste des types de secrets que vous utiliserez ultérieurement pour configurer des modèles personnalisés pour secret scanning. Pour plus d’informations, consultez « Définition de modèles personnalisés pour l’analyse des secrets ».

Protection par Push pour secret scanning

La protection Push pour les organisations et les référentiels secret scanning indique de vérifier les envois (push) des secrets pris en charge avant que les secrets ne soient validés dans le codebase. Pour plus d’informations sur les secrets pris en charge, consultez Modèles de détection de secrets pris en charge.

Si un secret est détecté dans une opération de push, celle-ci est bloquée. Secret scanning répertorie les secrets détectés afin que l'auteur puisse les passer en revue et les supprimer, ou, si nécessaire, autoriser leur mise en ligne. Secret scanning peut également vérifier les envois (push) pour les modèles personnalisés.

Les développeurs ont la possibilité de contourner la protection push en signalant qu’un secret est un faux positif, qu’il est utilisé dans les tests ou qu’il sera résolu ultérieurement.

Lorsqu’un contributeur contourne un bloc de protection Push, GitHub :

• Crée une alerte sous l’onglet Sécurité du référentiel, de l’organisation et de l’entreprise
• Ajoute l’événement de contournement au journal d’audit
• Envoie une alerte par e-mail aux comptes personnels, aux organisations et aux propriétaires d’entreprise, aux gestionnaires de sécurité et aux administrateurs de référentiel qui surveillent le référentiel, avec un lien vers le secret et la raison pour laquelle il a été autorisé

Avant d’activer la protection push, déterminez si vous devez créer des conseils pour les équipes de développement sur les conditions acceptables pour contourner la protection push. Vous pouvez configurer un lien vers cette ressource dans le message qui s’affiche lorsqu’un développeur tente d’envoyer (push) un secret bloqué.

Ensuite, familiarisez-vous avec les différentes options de gestion et de surveillance des alertes résultant du contournement de la protection push par un contributeur.

Pour plus d’informations, consultez « À propos de la protection lors du push ».

Étapes suivantes

Pour l’article suivant de cette série, consultez Phase 3 : Programmes pilotes.