Skip to main content

Phase 3 : Programmes pilotes

Il peut être judicieux de commencer avec quelques projets et équipes à impact élevé, avec lesquels piloter un déploiement initial. Cela permettra à un groupe initial au sein de l’entreprise de se familiariser avec GHAS, d’apprendre à activer et à configurer GHAS et de créer une base solide sur GHAS avant de procéder à un déploiement dans le reste de l’entreprise.

Cet article fait partie d’une série sur l’adoption de GitHub Advanced Security à grande échelle. Pour l’article précédent de cette série, consultez « Phase 2 : Préparation à l’activation à grande échelle ».

À propos des programmes pilotes

Nous vous recommandons d’identifier quelques projets ou équipes à impact élevé convenant à un déploiement pilote de GHAS. Cela permet à un groupe initial au sein de l’entreprise de se familiariser avec GHAS, et de créer une base solide pour GHAS avant de procéder à son déploiement dans le reste de l’entreprise.

Les étapes de cette phase vous aideront à activer GHAS dans votre entreprise, à commencer à utiliser ses fonctionnalités et à analyser les résultats. Si vous utilisez GitHub Professional Services, vous pouvez bénéficier d’une assistance supplémentaire via ce processus avec des sessions d’intégration, des ateliers GHAS et la résolution des problèmes, selon les besoins.

Avant de lancer vos projets pilotes, nous vous recommandons de planifier des réunions pour vos équipes, par exemple une réunion initiale, une analyse à mi-chemin et une session de clôture à la fin du pilote. Ces réunions vous aideront à apporter tous les ajustements nécessaires et à vous assurer que vos équipes sont préparées et en mesure de mener à bien le pilote.

Piloter toutes les fonctionnalités de GitHub Advanced Security

Vous pouvez rapidement activer les fonctionnalités de sécurité à grande échelle avec the 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 ».

Pilotage de l’code scanning

Vous pouvez configurer rapidement la configuration par défaut pour code scanning sur plusieurs référentiels d’une organisation à l’aide d’une vue d’ensemble de la sécurité. Pour plus d’informations, consultez « Définition de la configuration par défaut pour l’analyse du code à grande échelle ».

Vous pouvez également choisir d’activer code scanning pour tous les référentiels d’une organisation, mais nous vous recommandons de configurer code scanning sur un sous-ensemble de référentiels à impact élevé pour votre programme pilote.

Pour certains langages ou systèmes de génération, vous devrez peut-être utiliser une configuration avancée pour code scanning pour obtenir une couverture complète de votre codebase. Toutefois, la configuration avancée nécessite beaucoup plus d’efforts pour la configuration, la personnalisation et la gestion. Nous vous recommandons donc d’activer d’abord la configuration par défaut.

Si votre société souhaite utiliser d’autres outils d’analyse de code tiers avec GitHub code scanning, vous pouvez utiliser des actions pour exécuter ces outils dans GitHub. Vous pouvez aussi charger les résultats générés par des outils tiers sous forme de fichiers SARIF pour code scanning. Pour plus d’informations, consultez « Intégration à l’analyse du code ».

Pilotage de l’secret scanning

GitHub analyse les types de secrets connus dans les référentiels pour éviter une utilisation frauduleuse des secrets validés accidentellement.

Vous devez activer secret scanning et la protection push pour chaque projet pilote. Vous pouvez faire ceci avec la GitHub-recommended security configuration, ou vous pouvez créer une custom security configuration. Pour plus d’informations, consultez « Application de la configuration de sécurité recommandée par GitHub dans votre organisation » et « Création d’une configuration de sécurité personnalisée ».

Si vous envisagez de configurer un lien vers une ressource dans le message qui s’affiche lorsqu’un développeur tente d’envoyer un secret bloqué, il serait judicieux de tester et de commencer à affiner les conseils que vous prévoyez de mettre à disposition.

Commencez à examiner l’activité à l’aide de la page des métriques de protection push dans la vue d’ensemble de la sécurité. Pour plus d’informations, consultez « Affichage des mesures pour la protection par poussée de l'analyse secrète ».

Si vous avez rassemblé des modèles personnalisés propres à votre entreprise, en particulier des modèles liés aux projets pilotant l’secret scanning, vous pouvez les configurer. Pour plus d’informations, consultez « Définition de modèles personnalisés pour l’analyse des secrets ».

Pour savoir comment consulter et fermer les alertes pour les secrets archivés dans votre dépôt, consultez « Gestion des alertes à partir de l’analyse des secrets ».

Pour l’article suivant de cette série, consultez « Phase 4 : Créer une documentation interne ».