Partager via

Déployer l’intégration de GitHub Advanced Security avec Microsoft Defender pour le cloud

Ce guide vous guide tout au long des étapes de configuration pour vous aider à tirer le meilleur parti de la sécurité des applications natives cloud de Microsoft en intégrant GitHub Advanced Security (GHAS) et Microsoft Defender for Cloud (MDC).

En suivant ce guide, vous devez :

  • Configurer votre dépôt GitHub pour la couverture MDC (Microsoft Defender for Cloud)
  • Créer un facteur de risque d’exécution
  • Tester des cas d’usage réels dans MDC
  • Lier du code aux ressources cloud
  • Démarrer une campagne de sécurité sur GitHub, tirant parti du contexte d’exécution pour hiérarchiser les alertes de sécurité GHAS en fonction du contexte d’exécution
  • Créer des problèmes GitHub à partir de MDC pour démarrer la correction
  • Fermez la boucle entre les équipes d'ingénierie et de sécurité

Prerequisites

Aspect Détails
Exigences environnementales - Compte GitHub avec un connecteur créé dans Microsoft Defender pour Cloud (MDC)
- Licence GitHub Advanced Security (GHAS)
- Defender CSPM activé sur l’abonnement
- GitHub Security Copilot (facultatif pour la correction automatisée)
Rôles et autorisations - Autorisations d’administrateur de sécurité
- Lecteur de sécurité sur l’abonnement Azure (pour afficher les résultats dans MDC)
- Propriétaire de l’organisation GitHub
Environnements cloud - Disponible uniquement dans les clouds commerciaux (pas dans us Gov, China Gov ou d’autres clouds souverains)

Préparer votre environnement

Étape 1 : Configurer le référentiel GitHub et exécuter le flux de travail

Pour tester l’intégration, utilisez vos propres référentiels ou un exemple de référentiel GitHub qui a déjà tout le contenu pour générer une image conteneur vulnérable.

  • Vérifiez que vous définissez un connecteur pour l’organisation GitHub que vous envisagez d’utiliser dans le portail Microsoft Defender pour cloud. Pour la définition du connecteur, suivez les étapes de connexion de vos organisations GitHub.

  • Assurez-vous que l’analyse du code sans agent est configurée pour votre connecteur GitHub. Si ce n’est pas le cas, suivez les étapes suivantes : Configurer l’analyse du code sans agent (aperçu).

Note

Vérifiez que le dépôt que vous utilisez pour l’intégration est privé.

Si vous souhaitez utiliser un exemple de référentiel, clonez le dépôt suivant dans votre organisation GitHub. Ce référentiel a GHAS activé et est intégré à un locataire Azure avec DCSPM activé :build25-woodgrove/mdc-customer-playbook. Ce dépôt est destiné aux clients à tester l’intégration de Microsoft Defender pour cloud et GHAS.

Dans le référentiel, procédez comme suit :

  1. Accédez à Paramètres.
  2. Dans le volet gauche, sélectionnez Secrets et Variables>Actions.
  3. Ajoutez les secrets suivants au niveau du référentiel ou de l’organisation :
Variable Descriptif
ACR_ENDPOINT Serveur de connexion d’Azure Container Registry
ACR_PASSWORD Mot de passe pour Azure Container Registry
ACR_USERNAME Nom d’utilisateur d’Azure Container Registry

Capture d’écran de l’interface GitHub avec le menu « Secrets et variables » sélectionné et le bouton « Nouveau secret du dépôt » visible.

Note

Les noms peuvent être choisis librement et n’ont pas besoin de suivre un modèle spécifique.

Vous trouverez ces informations dans le portail Azure en procédant comme suit :

  1. Sélectionnez l’ACR sur lequel vous souhaitez effectuer le déploiement.

  2. Sélectionnez Clés d’accès sous Paramètres.

    Capture d’écran du portail Azure montrant la page Clés d’accès d’un registre de conteneurs avec les champs serveur de connexion, nom d’utilisateur et mot de passe visibles.

  3. Dans votre référentiel, sélectionnez Actions.

  4. Sélectionnez le flux de travail Générer et envoyer vers ACR, puis exécutez le flux de travail.

    Capture d’écran de la section Actions du référentiel GitHub montrant l’historique et les options du flux de travail pour déclencher manuellement le flux de travail.

  5. Vérifiez que l’image a été déployée sur votre azure Container Registry.

  6. Pour l’exemple de dépôt fourni : l’image doit se trouver dans un registre appelé mdc-mock-0001 avec le tag mdc-ghas-integration.

  7. Déployez la même image sous forme de conteneur en cours d’exécution sur votre cluster. Une façon d’effectuer cette étape consiste à se connecter au cluster et à utiliser la kubectl run commande. Voici un exemple pour AKS :

    1. Définissez l’abonnement au cluster :

      az account set --subscription $subscriptionID

    2. Définissez les identifiants du cluster :

      az aks get-credentials --resource-group $resourceGroupName --name $kubernetesClusterName --overwrite-existing

    3. Déployez l’image :

      kubectl run $containerName --image=$registryName.azurecr.io/mdc-mock-0001:mdc-ghas-integration

Étape 2 : Créer le premier facteur de risque - Règle critique pour l’entreprise

L’un des facteurs de risque détectés par Defender pour Cloud pour cette intégration est la criticité commerciale. Les organisations peuvent créer des règles pour étiqueter différentes ressources comme critiques pour l’entreprise.

  1. Dans le portail Microsoft Defender pour cloud (portail Azure), accédez aux paramètres d’environnement, choisissez Critique des ressources.

  2. Dans le volet droit, sélectionnez le lien pour ouvrir Microsoft Defender.

    Capture d’écran de l’interface Microsoft Defender pour Cloud montrant la vignette Critique des ressources et le lien Ouvrir le portail Microsoft Defender dans le volet droit.

  3. Sélectionnez Créer une nouvelle classification.

    Capture d’écran de la page paramètres XDR de Microsoft Defender avec le lien « Créer une nouvelle classification » mis en surbrillance en rouge.

  4. Entrez un nom et une description.

  5. Choisissez la ressource cloud dans le générateur de requêtes.

  6. Écrivez une requête pour définir le nom de ressource égal au nom du conteneur que vous avez déployé sur votre cluster pour validation, puis sélectionnez Suivant.

    Capture d’écran du générateur de requêtes Microsoft Defender avec nom de ressource égal au filtre « mdc-ghas-container » appliqué sous la ressource cloud.

  7. Dans la page Éléments multimédias en préversion , si Microsoft Defender a déjà détecté votre ressource, le nom du conteneur s’affiche avec le type de ressource K8s-container ou K8s-pod. Même s’il n’est pas encore visible dans la page des ressources d’aperçu, passez à l’étape suivante. Microsoft Defender applique l’étiquette de criticité au conteneur une fois détectée. Ce processus peut prendre jusqu’à 24 heures.

  8. Choisissez un niveau de criticité, puis passez en revue et soumettez votre règle de classification.

Étape 3 : Vérifier que votre environnement est prêt

Note

L’application des étapes précédentes peut prendre jusqu’à 24 heures pour afficher les résultats suivants.

  1. Testez que l’analyse sans agent GitHub récupère le dépôt.

  2. Accédez à Cloud Security Explorer et effectuez la requête. Capture d’écran du générateur de requêtes dans Cloud Security Explorer avec des filtres définis sur des référentiels GitHub et des images conteneur, montrant les résultats de la recherche.

  3. Vérifiez que le MDC (dans ACR) a analysé l’image conteneur et l’a utilisée pour créer un conteneur. Dans votre requête, ajoutez les conditions de votre déploiement spécifique. Capture d’écran de Cloud Security Explorer montrant une requête avec des filtres pour les référentiels GitHub et les images conteneur, affichant les résultats de l’analyse.

  4. Vérifiez que le conteneur est en cours d’exécution et que MDC a analysé le cluster AKS. Capture d’écran du générateur de requêtes Cloud Security Explorer avec des filtres pour les référentiels GitHub et les images conteneur, montrant les résultats avec les vulnérabilités et l’utilisation du conteneur.

  5. Vérifiez que les facteurs de risque sont configurés correctement côté MDC. Recherchez le nom de votre conteneur dans la page d’inventaire MDC et vous devez le voir marqué comme critique.

Étape 4 : Créer une campagne GitHub

Étant donné que le flux de travail déploie une image qui crée un conteneur en cours d’exécution avec l’un des facteurs de risque (critique pour l’entreprise), les développeurs peuvent voir les facteurs de risque dans GitHub.

Note

Après avoir classé votre ressource comme critique, il peut prendre jusqu’à 12 heures pour que MDC envoie les données à GitHub. En savoir plus ici.

  1. Dans GitHub, accédez à l’organisation GitHub que vous avez utilisée pour le test d’installation.

  2. SélectionnezCampagnes>> d’analyse de code.

    Capture d’écran de l’interface GitHub montrant l’onglet Campagnes de sécurité > avec les options permettant de créer une campagne à partir de filtres d’analyse de code ou de secret.

  3. Créez la campagne suivante. Cette campagne affiche des alertes ouvertes avec une gravité moyenne où l’image déployée à partir du référentiel est liée à une ressource critique. Votre référentiel de test doit être détecté avec cette campagne.

    Capture d’écran de l’interface GitHub Campaigns montrant les filtres pour les alertes ouvertes, la gravité définie sur critique et moyenne, et le risque d’exécution en tant que ressource critique.

  4. Sélectionnez Enregistrer , puis Publier en tant que campagne.

  5. Entrez les informations requises, puis publiez la campagne.

Étape 5 : Évaluer le code dans les recommandations cloud

Utilisez l'expérience C2C Recommendation SDLC et l'enrichissement des alertes de sécurité pour obtenir une meilleure compréhension de l'état des problèmes de sécurité. Attribuez ensuite la recommandation de résolution à l'équipe d'ingénierie concernée grâce à la connexion entre les alertes de sécurité de Dependabot et les CVE correspondantes, visibles dans l'onglet Recommandation d'exécution CVE associée.

Afficher les recommandations C2C

  1. Dans le portail MDC, accédez à l’onglet Recommandations .
  2. Recherchez le nom du conteneur que vous avez créé et ouvrez l’une des recommandations qui indiquent **Mettre à jour ***.
  3. Si vous avez utilisé l’exemple de dépôt, recherchez : Mettre à jour la recommandation d'expansion avec accolades.
  4. Accédez à l’onglet Insights de correction et affichez le code dans le diagramme cloud.
  5. Le diagramme mappe votre conteneur en cours d’exécution, à l’image conteneur dans le référentiel de code, au référentiel de code d’origine dans GitHub.

Capture d’écran de l’onglet Insights de correction montrant un diagramme de phases de développement avec des phases Code, Build, Ship et Runtime liées par des lignes en pointillés.

Enrichissement bidirectionnel

  1. Sélectionnez l’onglet CvEs associé . Notez que certaines CVE ont un lien dans la colonne Alertes GitHub associées.

    Capture d’écran de l’onglet CVEs associés montrant CVE-2025-5889 avec le score CVSS 3.1, version corrigée 2.0.2, et un lien Afficher sur GitHub sous les alertes GitHub associées.

  2. Sélectionnez le lien Affichage sur GitHub pour ouvrir l’alerte de sécurité GHAS appropriée.

Mobilisation de l’ingénierie

Pour fermer la boucle entre les équipes de sécurité et d’ingénierie, vous pouvez créer un problème GitHub pour une application conteneurisée hiérarchisant pour l’équipe d’ingénierie les problèmes de sécurité auxquels ils doivent se concentrer. Cette hiérarchisation peut inclure la transmission des résultats que GHAS n’a pas détectés mais que MDC a détectés pour les CVE qui ne font pas partie des dépendances directes (par exemple, les vulnérabilités dans l'image de base, le système d'exploitation ou les logiciels tiers comme NGINX).

Le problème GitHub est généré automatiquement avec tous les CVE identifiés dans le champ de la recommandation, en tenant compte de ceux avec et sans alertes Dependabot, ainsi que d'autres contextes d'exécution dans le dépôt d'origine.

Capture d’écran de la liste des problèmes GitHub montrant trois entrées, notamment « Mettre à jour l’extension avec accolades » et « Mettre à jour openssl » marquées avec des balises de sécurité et de vulnérabilité.

Lorsque vous attribuez le problème, l’état du problème est mis à jour dans le portail MDC.

Capture d’écran d’un problème GitHub intitulé « Mettre à jour lodash » avec des balises de sécurité et de vulnérabilité, montrant des détails tels que des CVE, des facteurs de risque d’exécution et des informations de déploiement.

Correctifs agentiques

Côté GitHub, si vous disposez d’une licence GitHub Copilot, vous pouvez résoudre le problème avec l’aide de GitHub Coding Agent :

  1. Affectez l’agent de codage GitHub au problème.
  2. Passez en revue le correctif généré.
  3. S’il semble raisonnable, appliquez le correctif.
  4. Observez la mise à jour de l’état du problème dans MDC sur Fermé.

Contenu connexe

  • Last updated on