Protection contre les menaces de sécurité

Quelles mesures dois-je prendre maintenant, dans un avenir proche, et sur une base continue pour réduire l’exposition aux menaces de sécurité au sein de mes organisations GitHub?

Dans cet article

Présentation

La prévention des incidents de sécurité est moins coûteuse et moins perturbatrice que la réponse à ces incidents. En améliorant de manière proactive votre environnement GitHub, vous réduisez votre exposition aux menaces telles que les informations d’identification exploitées, l’accès non autorisé et les attaques de chaîne logistique.

Ce guide se concentre principalement sur les mesures de protection que vous pouvez appliquer dans des organisations qui font partie d'une entreprise sur GitHub Enterprise Cloud. Pour la version d’évaluation GitHub Enterprise Cloud, consultez Configuration d’une version d’évaluation de GitHub Enterprise Cloud.

De nombreuses fonctionnalités de sécurité mentionnées ici, telles que les configurations de sécurité, les ensembles de règles de branche et les contrôles d’accès, peuvent être configurées au niveau de GitHubl’organisation ou au niveau de l’entreprise.

Actions immédiates

Il s’agit d’actions à fort impact que vous pouvez effectuer pour établir une base de référence de sécurité au sein d’une organisation.

Établir une couverture de sécurité

Assurez-vous que les outils de GitHub sont actifs GitHub Advanced Security dans tous les référentiels. Au lieu d’activer les outils un par un, vous pouvez créer et appliquer une configuration de sécurité, qui est une collection de paramètres de sécurité qui peuvent être appliqués aux référentiels au sein de votre organisation ou de votre entreprise en une seule action.

Une configuration forte peut inclure :

          Secret scanning
          ** et la **protection contre le push** pour détecter les secrets qui ont déjà été validés dans votre référentiel de code et empêcher les nouveaux secrets d’être poussés. Les informations d’identification divulguées sont l’une des causes les plus courantes des violations de sécurité.

          Code scanning
          ** pour identifier les vulnérabilités et les erreurs de codage dans votre code source avant qu’elles atteignent la production.

          Dependabot alerts
          ** et **Dependabot security updates** pour vous avertir des vulnérabilités connues et des programmes malveillants dans vos dépendances et ouvrir automatiquement des demandes de tirage pour mettre à jour les dépendances vulnérables.

Reportez-vous à Création d’une configuration de sécurité personnalisée (organisations) et Création d’une configuration de sécurité personnalisée pour votre entreprise (entreprises).

Renforcer les contrôles

          GitHub vous offre une gamme de contrôles qui régissent ce qui peut se produire dans vos référentiels et votre organisation. S’assurer que ces contrôles sont configurés de manière appropriée est essentiel pour réduire les risques.

Protéger les branches critiques avec des ensembles de règles

Les ensembles de règles vous permettent de définir des règles de protection pour les branches et les étiquettes dans un ou plusieurs référentiels. Utilisez-les pour appliquer des exigences telles que les révisions de pull request et les contrôles de statut, comme des analyses de sécurité automatisées. Cela peut empêcher les modifications non autorisées d’atteindre le code de production, y compris les modifications des comptes compromis.

Reportez-vous à Création d'ensembles de règles pour les dépôts de votre organisation (organisations) et Application de la gouvernance du code dans votre entreprise avec des ensembles de règles (entreprises).

Contrôler qui peut contourner la protection push

Lorsque vous activez la protection Push, les contributeurs qui tentent d’envoyer (push) un secret détecté sont bloqués, mais, par défaut, ils ont la possibilité de contourner le bloc. Le contournement délégué nécessite que les demandes de contournement passent par un cycle d’examen et d’approbation, afin qu’aucune déviation ne puisse se produire sans décision explicite et auditée.

Consultez « Activation du contournement délégué pour la protection d’envoi ».

Appliquer la révision des dépendances sur les demandes de tirage

L'action de révision des dépendances vous permet de repérer les dépendances vulnérables avant leur fusion, en affichant les vulnérabilités connues dans les changements de dépendances d'un pull request. Comme la protection push pour les secrets, elle sert de barrière plutôt qu'une alerte après coup. Vous pouvez appliquer la révision des dépendances aux pull requests au sein de votre organisation.

Consultez À propos de la vérification des dépendances et Application de la révision des dépendances dans une organisation.

Examiner et restreindre l’accès

L’accès approprié lorsqu’il a été accordé peut ne plus être nécessaire. Examiner régulièrement qui et ce qui a accès à une organisation réduit le risque d’actions non autorisées.

Auditer l’accès aux membres et suivre le principe du privilège minimum

Assurez-vous que les membres des organisations ont uniquement l’accès dont ils ont besoin. Supprimez les membres qui n’ont plus besoin d’accès, rétrogradent les rôles où les autorisations plus larges ne sont pas justifiées et passez en revue l’accès externe aux collaborateurs. L’accès trop permissif augmente le rayon d’explosion d’un compte compromis.

Si les rôles par défaut sont plus permissifs qu’une organisation nécessite, vous pouvez créer des rôles personnalisés qui accordent uniquement les autorisations spécifiques dont chaque équipe a besoin. Cela est particulièrement utile pour les organisations adoptant un modèle de sécurité confiance zéro.

Consultez « Identification des rôles requis par votre entreprise ».

Examiner les applications autorisées

          OAuth apps et GitHub Apps qui sont installés dans une organisation peuvent accéder aux données. Passez en revue la liste des applications autorisées et supprimez celles qui ne sont plus nécessaires ou ne sont plus approuvées. Les intégrations périmées représentent une surface d’attaque souvent négligée.

Consultez Révision et modification des applications GitHub installées et À propos des restrictions d’accès des applications OAuth.

Restreindre l’accès réseau avec des listes d’autorisation IP

Pour les organisations sur GitHub Enterprise Cloud, si votre organisation fonctionne à partir de plages réseau connues, configurez une liste d’autorisations IP pour restreindre l’accès aux GitHub ressources de ces plages uniquement. Cela ajoute une couche de défense contre les informations d’identification compromises utilisées à partir d’emplacements inattendus.

Consultez Gestion des adresses IP autorisées pour votre organisation et Restriction du trafic réseau vers votre entreprise avec une liste d’adresses IP autorisées.

Actions à court terme

Ces actions sont également importantes pour votre posture de sécurité, mais peuvent nécessiter plus de préparation et de coordination avant de pouvoir les déployer.

Renforcer l’authentification

L’authentification faible ou compromise est l’une des causes les plus courantes de la compromission de compte. La nécessité d’une authentification forte au sein de votre organisation réduit considérablement ce risque.

Exiger une authentification à deux facteurs (2FA) pour tous les membres, ce qui garantit qu’un mot de passe compromis seul n’est pas suffisant pour accéder à un compte. Avant d’appliquer la condition requise, communiquez avec votre organisation afin que les membres aient le temps de configurer 2FA.

Les organisations sur GitHub Enterprise Cloud peuvent aller plus loin en appliquant l’authentification unique (SSO), qui centralise l’authentification par l'intermédiaire de votre fournisseur d'identité.

Consultez Exiger l’authentification à deux facteurs dans votre organisation et À propos de la gestion des identités et des accès avec l’authentification unique SAML.

Renforcer vos GitHub Actions flux de travail

          GitHub Actions Les flux de travail ont souvent accès aux secrets, aux informations d’identification de déploiement et aux autorisations d’écriture dans votre référentiel. Sans configuration minutieuse, une action compromise ou malveillante peut exfiltrer des données ou injecter du code malveillant.

Déclarer explicitement des autorisations de flux de travail

Par défaut, les flux de travail peuvent recevoir des autorisations étendues via le GITHUB_TOKEN. Déclarez explicitement les autorisations minimales dont chaque flux de travail a besoin à l’aide de la permissions clé dans vos fichiers de flux de travail. Cela limite les dommages qu’une étape de flux de travail compromise peut entraîner.

Épingler des actions tierces pour valider des contrats SHA

Lorsque vous référencez une action tierce par balise (par exemple, v1), la balise peut être déplacée pour pointer vers un code différent. L’épinglage d’actions vers une sha de validation complète garantit que vous exécutez toujours le code exact que vous avez examiné et approuvé. Cela protège contre les attaques de chaîne d’approvisionnement où une étiquette est détournée.

Restreindre les actions pouvant s’exécuter

Configurez des stratégies au niveau de l’organisation ou de l’entreprise pour contrôler les actions autorisées à s’exécuter. Vous pouvez limiter les actions à celles créées par GitHub, les actions des créateurs vérifiés ou une liste d'autorisation spécifique.

Pour plus d’informations sur toutes ces pratiques, ainsi que sur les pratiques d’utilisation sécurisée supplémentaires pour GitHub Actions plus précisément, consultez Informations de référence sur l’utilisation sécurisée.

Pratiques de sécurité en cours

Ces pratiques doivent faire partie de votre rythme opérationnel régulier.

Surveiller votre posture de sécurité avec une vue d’ensemble de la sécurité

La vue d’ensemble de la sécurité vous donne une vue centralisée du paysage de sécurité d’une organisation et de l’entreprise. Utilisez-le pour suivre les référentiels sur lesquels les fonctionnalités de sécurité sont activées et identifier les référentiels avec des alertes ouvertes, afin que les risques émergents ne passent pas inaperçus.

Consultez « À propos de la vue d’ensemble de la sécurité ».

Exécuter des campagnes de sécurité régulières pour réduire la dette de sécurité

Au fil du temps, les alertes de sécurité peuvent s’accumuler. Les campagnes de sécurité vous permettent d’organiser et de hiérarchiser les efforts de correction, d’affecter des groupes d’alertes aux développeurs (avec l’aide de Copilotcorrectifs générés) ou d’affecter des alertes directement à Copilot.

Les campagnes de sécurité sont disponibles pour les organisations sur GitHub Team ou GitHub Enterprise Cloud avec GitHub Advanced Security activé. Consultez « Création et gestion de campagnes de sécurité ».

Continuer à auditer l’accès et les autorisations

À mesure que les personnes rejoignent et quittent une organisation et que les projets évoluent, les exigences d’accès changent. Planifiez des révisions périodiques des éléments suivants :

  • Appartenance et rôles de l’organisation.
  • Accès externe aux collaborateurs.
  • Autorisations au niveau du dépôt et assignations d’équipe.
  • Autorisé OAuth et GitHub Apps.

Cela garantit que l’accès reste aligné sur le principe des privilèges minimum, même lorsque votre organisation change.

Maintenir les dépendances à jour

Les dépendances vulnérables sont un point d’entrée courant pour les attaquants. Dependabot peut ouvrir automatiquement des requêtes de tirage pour mettre à jour les dépendances avec des vulnérabilités connues, mais ces requêtes de tirage doivent toujours être examinées et fusionnées rapidement.

Établissez un processus de triage et de fusion des pull requests Dependabot afin que les mises à jour de sécurité ne ralentissent pas.

Consultez À propos des règles de triage automatique de Dependabot et Gestion des demandes de tirage (pull request) pour les mises à jour des dépendances.

Effectuer la rotation des secrets et imposer une date d'expiration

Plus longtemps un identifiant existe, plus il y a de risques qu'il soit exposé ou volé. Dans la cas où cela est possible :

  • Définissez les dates d’expiration sur personal access tokens.
  • Changer les secrets selon une planification régulière.

Pour plus d’informations sur la gestion des jetons, consultez Gestion de vos jetons d’accès personnels et Expiration et révocation des jetons.

Étapes suivantes

  • Même avec des contrôles préventifs forts en place, les incidents de sécurité peuvent toujours se produire. Il existe plusieurs outils critiques et processus de réponse que vous devez configurer à l’avance. Consultez « Préparation d’un incident de sécurité ».