Déployer l’intégration de GitHub Advanced Security

Ce guide fournit des étapes de configuration et d’autres actions pour vous aider à intégrer GitHub Advanced Security (GHAS) et Microsoft Defender for Cloud, puis valider la fin de l’intégration. L'intégration permet d'optimiser la sécurité des applications natives cloud de Microsoft en mettant en corrélation les risques d'exécution et le contexte avec le code d'origine pour accélérer la correction basée sur l'IA.

En suivant ce guide, vous devez :

Configurez votre dépôt GitHub pour la couverture de Defender pour le Cloud.
Créez un facteur de risque d’exécution.
Testez les cas d’usage réels dans Defender pour Cloud.
Lier du code aux ressources d’exécution.
Démarrez une campagne de sécurité sur GitHub. Cette campagne utilise le contexte d’exécution pour hiérarchiser les alertes de sécurité GHAS.
Créez des issues GitHub à partir de Defender for Cloud pour démarrer la remédiation.
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 Defender pour le Cloud - licence GitHub Advanced Security (GHAS) sur les référentiels connectés - Defender plan DCSPM (Cloud Security Posture Management) activé sur l’abonnement - Microsoft Security Copilot (facultatif pour la correction automatisée basée sur l’IA)
Rôles et autorisations	- Autorisations d’administrateur de sécurité - Administrateur sécurité sur l’abonnement Azure pour consulter les résultats dans Defender for Cloud - Propriétaire d’organisation GitHub pour la connexion des dépôts et la configuration des campagnes de sécurité
Environnements cloud	- Disponible uniquement dans les clouds commerciaux (pas dans Azure Government, Azure géré par 21Vianet ou d’autres clouds souverains)

Préparer votre environnement

Suivez les étapes suivantes pour configurer votre dépôt GitHub et les paramètres Defender for Cloud avant de valider l’intégration.

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

Pour tester l’intégration, utilisez vos propres dépôts ou un exemple de projet bac à sable. Le projet bac à sable fournit un dépôt GitHub de test avec tout ce dont vous avez besoin pour construire une image conteneur vulnérable.

Connectez-vous au portail Azure.
Accédez à Microsoft Defender for Cloud>DevOps security.
Saisissez le nom de votre dépôt de code dans la barre de recherche, par exemple zava-webshop.
Vérifiez qu’elle appartient à l’organisation que vous surveillez, par exemple, l’organisation zava-corporation .
Vérifiez la présence de résultats pour le référentiel.
Vérifiez que l’état de sécurité avancé est activé. Ce paramètre indique que GitHub Advanced Security est activé sur le dépôt surveillé.
Si votre dépôt n'est pas trouvé, consultez le démarrage rapide du connecteur GitHub pour des conseils de dépannage et de configuration.
Vérifiez que l’analyse sans agent est activée pour votre connecteur GitHub.

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

Cette validation d’environnement confirme que votre dépôt et vos ressources cloud sont correctement configurés. Il vérifie que Defender peut afficher les recommandations « code-to-runtime » et produire des résultats utiles. Lors de l’étape de validation de l’environnement, Defender vérifie que :

Microsoft Defender for Cloud surveille en permanence les référentiels de code source pour les vulnérabilités de sécurité.
Les artefacts de build, comme les images de conteneur, sont analysés dans les Container Registers avant leur déploiement.
Les charges de travail d’exécution déployées sur des clusters Kubernetes sont surveillées pour détecter les risques de sécurité.
Defender for Cloud met en corrélation et trace chaque artefact à partir du code, via la génération et le déploiement, jusqu’au runtime et au retour.

Note

Il peut falloir jusqu’à 24 heures après l’application des étapes précédentes pour voir les résultats.

Validez une visibilité complète, du code à l’exécution

Testez que l’analyse sans agent GitHub récupère le référentiel.

Accédez à Microsoft Defender for Cloud>Cloud Security Explorer et effectuez la requête. Les requêtes de validation testent si Defender peut identifier les artefacts générés par vos pipelines et charges de travail. Si les requêtes retournent des résultats, cela indique que l’analyse et la corrélation fonctionnent comme prévu.

Note

Si aucun résultat n’est retourné, il peut indiquer que les artefacts ne sont pas encore générés, que l’analyse n’est pas configurée ou que les autorisations sont manquantes. Pour plus d’informations, consultez rôles d’utilisateur et autorisations .

Dans Azure Container Registry, validez que Defender for Cloud a scanné l’image du conteneur et l’a utilisée pour créer un conteneur.
Dans votre requête, ajoutez les conditions de votre déploiement spécifique.
Vérifiez que le conteneur est en cours d’exécution et que Defender pour Cloud a analysé le cluster AKS.
Vérifiez que les facteurs de risque sont configurés correctement côté Defender pour cloud. Recherchez le nom de votre conteneur sur la page d’inventaire de Defender for Cloud. Vous devriez le voir indiqué comme critique.

Note

Cette étape est requise uniquement si les facteurs de risque ne sont pas déjà configurés dans votre environnement. Si vous utilisez déjà les facteurs de risque, vous pouvez vérifier leur configuration sous Paramètres>Criticité des ressources.

La validation réussie garantit que les étapes suivantes, telles que les recommandations, les campagnes et GitHub génération de problèmes, produisent des résultats significatifs.

Note

Une fois que vous avez classé votre ressource comme critique, il peut prendre jusqu’à 12 heures pour que Defender for Cloud envoie les données à GitHub. Pour plus d’informations, voir Priorisation du Dependabot et alertes de balayage de code.

Étape 3 : Créer une campagne de GitHub

Pour créer une campagne d’analyse, travaillez au niveau de l’organisation GitHub. Cette expérience n’est pas disponible au niveau du référentiel individuel.

Dans GitHub, accédez à l’organisation GitHub que vous avez utilisée pour le test d’installation.
SélectionnezCampagnes>>> d’analyse de code.

La campagne de risque à l’exécution aide à prioriser les résultats de GitHub Advanced Security (GHAS) qui appartiennent au code réellement déployé et en cours d’exécution.
Sélectionnez les filtres Runtime Risks pour la campagne.

Screenshot de la boîte de dialogue des filtres avancés lors de la création de campagne GitHub avec le Filtre de risque d'exécution et le menu des facteurs de risque sélectionnables ouvert.
Sélectionnez Enregistrer>Publier en tant que campagne. Entrez les informations requises, puis publiez la campagne.
Suivre l’avancement des campagnes.

Étape 4 : Agir sur les recommandations

Utilisez la fonctionnalité « code-to-runtime » des recommandations Containers VA ainsi que la corrélation des CVE identifiées avec les alertes de sécurité Dependabot afin de comprendre l’état des problèmes de sécurité. Vous pouvez ensuite attribuer la recommandation de remédiation à l’équipe d’ingénierie concernée selon le mappage « code-to-runtime ».

Dans le portail Defender pour cloud, accédez à l’onglet Recommandations .
Recherchez le nom du conteneur que vous avez créé à partir de votre dépôt de code.
Ouvre l’une des recommandations de logiciels de mise à jour. Le nom de la recommandation commence par Update.
Sélectionnez les CVE associés.

Les alertes de sécurité apparaissent dans le cadre du flux d’évaluation des recommandations. Ces alertes fournissent des indications sur les résultats de GitHub Advanced Security déjà connus pour l’ingénierie. Certains identifiants CVE comportent un lien « Voir sur GitHub » dans la colonne Alertes GitHub associées.

Sélectionnez le lien pour ouvrir l’alerte de sécurité GHAS appropriée. Pour consulter le contenu d’alerte GHAS sur GitHub, vous devez avoir des autorisations d’accès au dépôt GitHub concerné. Si vous n'avez pas de permissions d'accès, vous pouvez toujours copier le lien pour la prochaine utilisation ou contacter votre administrateur GitHub.

Si la colonne Alertes GitHub associées montre une alerte Dependabot correspondante, la vulnérabilité est déjà connue de l’ingénierie. Si le statut d’alerte est Actif, personne ne l’a encore corrigé, et le problème doit être priorisé pour une correction.

Si aucune alerte GitHub correspondante n’apparaît dans la colonne, le CVE représente un risque d’exécution inconnu de l’ingénierie qui doit être priorisé pour une correction.

Créer un problème GitHub

Pour fermer la boucle entre les équipes de sécurité et d’ingénierie, vous pouvez créer un problème GitHub qui hiérarchise les problèmes de sécurité auxquels l’équipe d’ingénierie doit se concentrer. Cette hiérarchisation peut inclure la transmission de résultats que GHAS n’a pas récupéré, mais que Defender pour Cloud a détecté pour les ID CVE qui ne font pas partie des dépendances directes. Ces résultats peuvent inclure des vulnérabilités dans l’image de base, le système d’exploitation ou les logiciels tels que NGINX.

L’issue GitHub est générée automatiquement dans le référentiel du code source avec tous les identifiants CVE trouvés dans le périmètre de la recommandation, y compris d’autres contextes liés au runtime, au conteneur et au cycle de vie du développement logiciel (SDLC), qui peuvent aider à corriger le problème et à effectuer les tests.

Dans l’affichage des recommandations, vous pouvez générer explicitement un problème de GitHub pour suivre le travail de correction.

Allez dans Remediation Insights et consultez le diagramme code-runtime. Le diagramme mappe votre conteneur en cours d’exécution à l’image conteneur dans le référentiel de code et au référentiel de code d’origine dans GitHub.
1. Sous l’onglet Insights de correction , passez en revue la zone Runtime affectée.
2. Validate si un problème de GitHub existe déjà. Si un problème de GitHub existe déjà, une icône de GitHub s’affiche dans la zone. Pointez sur l’icône pour afficher les détails du problème.
3. Si aucun problème n’existe et que vous disposez des autorisations requises, vous pouvez générer un nouveau problème de GitHub. Sélectionnez Effectuer une action.
4. Sélectionnez l’option Générer GitHub problème dans la fenêtre contextuelle.
5. Si le problème a été créé avec succès, vous voyez une notification pop-up avec un lien vers le problème. Le problème est créé dans le référentiel de code d’origine.
Note

Si l'option Générer un problème sur GitHub n'est pas disponible, il se peut que vous manquez de permissions GitHub ou du dépôt. Contactez votre administrateur de GitHub ou de référentiel pour demander l’accès.
1. Suivez la propriété et les mises à jour de statut. Les changements concernant le statut de publication ou l’affectation effectués dans GitHub sont pris en compte dans Microsoft Defender for Cloud. Ce fait vous permet de suivre l’avancement de la propriété et de la remédiation depuis la vue des recommandations .