Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Cet article répertorie les recommandations que vous pouvez voir dans Microsoft Defender for Cloud si vous connectez un environnement Azure DevOps, GitHub ou GitLab à l’aide de la page paramètres de l’environnement.
Les recommandations qui apparaissent dans votre environnement sont basées sur les ressources que vous protégez et sur votre configuration personnalisée. Vous pouvez voir les recommandations dans le portail qui s’appliquent à vos ressources.
Pour en savoir plus sur les actions que vous pouvez effectuer en réponse à ces recommandations, consultez Correction des recommandations dans Defender pour le cloud.
En savoir plus sur les avantages et fonctionnalités de sécurité DevOps .
Les recommandations DevOps n’affectent pas votre score de sécurisation. Pour déterminer les recommandations à résoudre en premier, examinez la gravité de chaque recommandation et son impact potentiel sur votre score sécurisé.
recommandations Azure DevOps
Azure DevOps référentiels doivent avoir activé GitHub Advanced Security for Azure DevOps (GHAzDO)
Description : La sécurité DevOps dans Defender for Cloud utilise une console centrale pour permettre aux équipes de sécurité de protéger les applications et les ressources du code vers le cloud dans Azure DevOps. Avec l’activation des référentiels GitHub Advanced Security for Azure DevOps (GHAzDO), notamment GitHub Advanced Security for Azure DevOps, vous obtenez des résultats sur les secrets, les dépendances et les vulnérabilités du code dans vos référentiels Azure DevOps exposés dans Microsoft Defender for Cloud.
Gravité : Élevée
Azure DevOps référentiels doivent avoir des résultats d’analyse des secrets résolus
Description : Les secrets ont été trouvés dans les référentiels de code. Corrigez immédiatement pour empêcher une violation de sécurité. Les secrets trouvés dans les référentiels peuvent fuiter ou être découverts par des adversaires, ce qui entraîne la compromission d’une application ou d’un service. L’outil d’analyse des informations d’identification devOps Sécurité Microsoft analyse uniquement les builds sur lesquelles il est configuré pour s’exécuter. Par conséquent, les résultats peuvent ne pas refléter l’état complet des secrets dans vos dépôts.
Gravité : Élevée
Les référentiels Azure DevOps doivent avoir corrigé les problèmes détectés par l’analyse du code
Description : Les vulnérabilités ont été détectées dans les référentiels de code. Pour améliorer la posture de sécurité des dépôts, il est vivement recommandé de corriger ces vulnérabilités.
Gravité : Moyenne
Azure DevOps référentiels doivent avoir des résultats d’analyse des vulnérabilités de dépendance résolus
Description : vulnérabilités de dépendance trouvées dans les référentiels de code. Pour améliorer la posture de sécurité des dépôts, il est vivement recommandé de corriger ces vulnérabilités.
Gravité : Moyenne
Azure DevOps référentiels doivent disposer d’une infrastructure, car les résultats de l’analyse du code ont été résolus
Description : Problèmes de configuration de sécurité de l’infrastructure en tant que code trouvés dans les référentiels. Les problèmes ont été détectés dans les fichiers de modèle. Pour améliorer la posture de sécurité des ressources cloud associées, il est vivement recommandé de corriger ces problèmes.
Gravité : Moyenne
Azure DevOps pipelines ne doivent pas avoir de secrets disponibles pour les builds de fourche
Description : dans les référentiels publics, il est possible que les personnes extérieures à l’organisation créent des duplications et exécutent des builds sur le référentiel dupliqué. Dans ce cas, si ce paramètre est activé, les externes peuvent obtenir l’accès à la génération de secrets de pipeline destinés à être internes.
Gravité : Élevée
Azure DevOps connexions de service ne doivent pas accorder l'accès à tous les pipelines
Description : les connexions de service sont utilisées pour créer des connexions de Azure Pipelines vers des services externes et distants pour l’exécution de tâches dans un travail. Les autorisations de pipeline contrôlent les pipelines autorisés à utiliser la connexion de service. Pour prendre en charge la sécurité des opérations de pipeline, les connexions de service ne doivent pas être autorisées à accéder à tous les pipelines YAML. Cela permet de maintenir le principe du privilège minimum, car une vulnérabilité dans les composants utilisés par un pipeline peut être utilisée par un attaquant pour attaquer d’autres pipelines ayant accès aux ressources critiques.
Gravité : Élevée
Azure DevOps fichiers sécurisés ne doivent pas accorder l'accès à tous les pipelines
Description : Les fichiers sécurisés permettent aux développeurs de stocker des fichiers qui peuvent être partagés entre des pipelines. Ces fichiers sont généralement utilisés pour stocker des secrets tels que des certificats de signature et des clés SSH. Si un fichier sécurisé est autorisé à accéder à tous les pipelines YAML, un utilisateur non autorisé peut voler des informations à partir des fichiers sécurisés en créant un pipeline YAML et en accédant au fichier sécurisé.
Gravité : Élevée
Azure DevOps groupes de variables avec des variables secrètes ne doivent pas accorder l'accès à tous les pipelines
Description : les groupes de variables stockent des valeurs et des secrets que vous souhaiterez peut-être passer dans un pipeline YAML ou rendre disponibles sur plusieurs pipelines. Vous pouvez partager et utiliser des groupes de variables dans plusieurs pipelines dans le même projet. Si un groupe de variables contenant des secrets est marqué comme accessible à tous les pipelines YAML, un attaquant peut exploiter les ressources impliquant les variables secrètes en créant un pipeline.
Gravité : Élevée
Azure DevOps connexions de service de Azure classique ne doivent pas être utilisées pour accéder à un abonnement
Description : Utilisez le type de Azure Resource Manager (ARM) de connexions de service au lieu de Azure connexions de service Classic pour vous connecter à des abonnements Azure. Le modèle ARM offre plusieurs améliorations de sécurité, notamment un contrôle d’accès plus fort, un audit amélioré, un déploiement/une gouvernance BASÉ sur ARM, l’accès aux identités managées et au coffre de clés pour les secrets, l’authentification basée sur Entra, et la prise en charge des étiquettes et des groupes de ressources pour une gestion simplifiée.
Gravité : Moyenne
(Préversion) Azure DevOps référentiels doivent avoir des résultats de test de sécurité d’API résolus
Description : vulnérabilités de sécurité des API trouvées dans les référentiels de code. Pour améliorer la posture de sécurité des dépôts, il est vivement recommandé de corriger ces vulnérabilités.
Gravité : Moyenne
(Préversion) Azure DevOps référentiels doivent exiger une approbation minimale à deux réviseurs pour les envois de code
Description : Pour empêcher les modifications involontaires ou malveillantes d'être validées directement, il est important d'implémenter des stratégies de protection pour la branche par défaut dans Azure DevOps référentiels. Nous vous recommandons d’exiger au moins deux réviseurs de code pour approuver les demandes de tirage avant la fusion du code avec la branche par défaut. En exigeant l’approbation d’un nombre minimal de deux réviseurs, vous pouvez réduire le risque de modifications non autorisées, ce qui peut entraîner une instabilité du système ou des vulnérabilités de sécurité.
Cette recommandation est fournie dans Defender for Cloud posture de sécurité fondamentale, si vous avez connecté Azure DevOps à Defender for Cloud.
Gravité : Élevée
(Préversion) Azure DevOps référentiels ne doivent pas autoriser les demandeurs à approuver leurs propres demandes de tirage
Description : Pour empêcher les modifications involontaires ou malveillantes d'être validées directement, il est important d'implémenter des stratégies de protection pour la branche par défaut dans Azure DevOps référentiels. Nous vous recommandons d’interdire aux créateurs de demandes de tirage d’approuver leurs propres soumissions pour s’assurer que chaque modification subit un examen objectif par quelqu’un d’autre que l’auteur. En procédant ainsi, vous pouvez réduire le risque de modifications non autorisées, ce qui peut entraîner une instabilité du système ou des vulnérabilités de sécurité.
Cette recommandation est fournie dans Defender for Cloud posture de sécurité fondamentale, si vous avez connecté Azure DevOps à Defender for Cloud.
Gravité : Élevée
(Préversion) Azure DevOps projets doivent avoir créé des pipelines classiques désactivés
Description : la désactivation de la création de pipelines de build et de mise en production classiques empêche une préoccupation de sécurité qui provient de YAML et de pipelines classiques partageant les mêmes ressources, par exemple les mêmes connexions de service. Les attaquants potentiels peuvent tirer parti des pipelines classiques pour créer des processus qui évitent les mécanismes de défense classiques configurés autour de pipelines YAML modernes.
Gravité : Élevée
recommandations GitHub
GitHub organisations ne doivent pas rendre les secrets d’action accessibles à tous les référentiels
Description : Pour les secrets utilisés dans GitHub flux de travail Action stockés au niveau de l’organisation GitHub, vous pouvez utiliser des stratégies d’accès pour contrôler les référentiels pouvant utiliser des secrets d’organisation. Les secrets au niveau de l’organisation vous permettent de partager des secrets entre plusieurs référentiels. Cela réduit la nécessité de créer des secrets en double. Toutefois, une fois qu’un secret est rendu accessible à un référentiel, toute personne disposant d’un accès en écriture sur le référentiel peut accéder au secret à partir de n’importe quelle branche d’un flux de travail. Pour réduire la surface d’attaque, assurez-vous que le secret est accessible uniquement à partir de référentiels sélectionnés.
Cette recommandation est fournie dans Defender for Cloud posture de sécurité fondamentale, si vous avez connecté Azure DevOps à Defender for Cloud.
Gravité : Élevée
GitHub référentiels doivent avoir activé l’analyse des secrets
Description : GitHub analyse les référentiels pour les types connus de secrets, afin d’empêcher l’utilisation frauduleuse de secrets qui ont été accidentellement validés dans les référentiels. L’analyse des secrets analyse l’intégralité de l’historique Git sur toutes les branches présentes dans le référentiel GitHub pour les secrets. Les jetons et les clés privées qu’un fournisseur de services peut émettre pour l’authentification sont des exemples de secrets. Si un secret est archivé dans un dépôt, toute personne disposant d’un accès en lecture au dépôt peut utiliser le secret pour accéder au service externe avec ces privilèges. Les secrets doivent être stockés dans un emplacement dédié et sécurisé en dehors du dépôt du projet.
Gravité : Élevée
GitHub référentiels doivent avoir activé l’analyse du code
Description : GitHub utilise l’analyse du code pour analyser le code afin de rechercher des vulnérabilités et des erreurs de sécurité dans le code. L’analyse du code peut être utilisée pour rechercher, trier et hiérarchiser les correctifs pour les problèmes existants dans votre code. L’analyse du code peut également empêcher les développeurs d’introduire de nouveaux problèmes. Des analyses peuvent être planifiées pour des jours et heures spécifiques, ou être déclenchées lorsqu’un événement spécifique se produit dans le dépôt, tel qu’un envoi (push). Si l’analyse du code détecte une vulnérabilité ou une erreur potentielle dans le code, GitHub affiche une alerte dans le référentiel. Une vulnérabilité est un problème dans le code d’un projet qui pourrait être exploité pour endommager la confidentialité, l’intégrité ou la disponibilité du projet.
Gravité : Moyenne
GitHub référentiels doivent avoir activé l’analyse de Dependabot
Description : GitHub envoie des alertes Dependabot lorsqu’elle détecte les vulnérabilités dans les dépendances de code qui affectent les référentiels. Une vulnérabilité est un problème dans le code d’un projet qui pourrait être exploité pour altérer la confidentialité, l’intégrité ou la disponibilité du projet ou d’autres projets qui utilisent son code. Les vulnérabilités varient en fonction du type, de la gravité et de la méthode d’attaque. Quand le code dépend d’un package qui présente une faille de sécurité, cette dépendance vulnérable peut entraîner une série de problèmes.
Gravité : Moyenne
GitHub référentiels doivent avoir des résultats d’analyse des secrets résolus
Description : Secrets trouvés dans les référentiels de code. Cela doit être corrigé immédiatement pour éviter une violation de la sécurité. Les secrets détectés dans les dépôts peuvent être divulgués ou découverts par des adversaires, ce qui peut compromettre une application ou d’un service.
Gravité : Élevée
GitHub référentiels doivent avoir résolu les résultats de l’analyse du code
Description : Vulnérabilités trouvées dans les référentiels de code. Pour améliorer la posture de sécurité des dépôts, il est vivement recommandé de corriger ces vulnérabilités.
Gravité : Moyenne
Les dépôts GitHub doivent voir les résultats de l’analyse des vulnérabilités des dépendances corrigés
Description : GitHub référentiels doivent avoir des résultats d’analyse des vulnérabilités de dépendance résolus.
Gravité : Moyenne
GitHub référentiels doivent disposer d’une infrastructure, car les résultats de l’analyse du code ont été résolus
Description : Les problèmes de configuration de sécurité de l’infrastructure en tant que code ont été détectés dans les référentiels. Les problèmes ont été détectés dans les fichiers de modèle. Pour améliorer la posture de sécurité des ressources cloud associées, il est vivement recommandé de corriger ces problèmes.
Gravité : Moyenne
GitHub référentiels doivent avoir des stratégies de protection pour la branche par défaut activée
Description : La branche par défaut du référentiel doit être protégée par le biais de stratégies de protection de branche pour empêcher les modifications involontaires/malveillantes d’être directement validées dans le référentiel.
Gravité : Élevée
GitHub référentiels doivent avoir forcé l’envoi (push) à la branche par défaut désactivée
Description : étant donné que la branche par défaut est généralement utilisée pour le déploiement et d’autres activités privilégiées, toutes les modifications apportées à celle-ci doivent être abordées avec prudence. L’activation des envois de force peut introduire des modifications involontaires ou malveillantes dans la branche par défaut.
Gravité : Moyenne
GitHub organisations doivent avoir activé la protection push d’analyse des secrets
Description : La protection Push bloque les validations qui contiennent des secrets, ce qui empêche l’exposition accidentelle des secrets. Pour éviter le risque d’exposition des informations d’identification, la protection Push doit être automatiquement activée pour chaque référentiel activé pour l’analyse des secrets.
Gravité : Élevée
GitHub référentiels ne doivent pas utiliser les exécuteurs auto-hébergés
Description : Self-Hosted exécuteurs sur GitHub manque de garanties d’opération dans des machines virtuelles propres éphémères et peuvent être compromis de manière persistante par du code non approuvé dans un flux de travail. Par conséquent, Self-Hosted exécuteurs ne doivent pas être utilisés pour les flux de travail d’action.
Gravité : Élevée
GitHub organisations doivent disposer d’autorisations de flux de travail d’actions définies en lecture seule
Description : Par défaut, les flux de travail Action doivent disposer d’autorisations en lecture seule pour empêcher les utilisateurs malveillants d’exploiter des flux de travail sur-autorisés pour accéder aux ressources et les falsifier.
Gravité : Élevée
GitHub organisations doivent disposer de plusieurs personnes disposant d’autorisations d’administrateur
Description : Avoir au moins deux administrateurs réduit le risque de perdre l’accès administrateur. Cela est utile dans le cas de scénarios de compte d’arrêt.
Gravité : Élevée
GitHub organisations doivent disposer d’autorisations de base définies sur aucune autorisation ni lecture
Description : Les autorisations de base doivent être définies sur aucune ou lue pour qu’une organisation suive le principe du privilège minimum et empêche l’accès inutile.
Gravité : Élevée
(Préversion) GitHub référentiels doivent avoir des résultats de test de sécurité d’API résolus
Description : Les vulnérabilités de sécurité des API ont été détectées dans les référentiels de code. Pour améliorer la posture de sécurité des dépôts, il est vivement recommandé de corriger ces vulnérabilités.
Gravité : Moyenne
(Préversion) GitHub organisations ne doivent pas rendre les secrets d’action accessibles à tous les référentiels
Description : Pour les secrets utilisés dans GitHub flux de travail Action stockés au niveau de l’organisation GitHub, vous pouvez utiliser des stratégies d’accès pour contrôler les référentiels pouvant utiliser les secrets de l’organisation. Les secrets au niveau de l’organisation vous permettent de partager des secrets entre plusieurs référentiels, ce qui réduit la nécessité de créer des secrets en double. Toutefois, lorsqu’un secret est rendu accessible à un référentiel, toute personne disposant d’un accès en écriture sur le référentiel peut accéder au secret à partir de n’importe quelle branche d’un flux de travail. Pour réduire la surface d’attaque, assurez-vous que le secret est accessible uniquement à partir de référentiels sélectionnés.
Gravité : Élevée
(Préversion) GitHub organisations doivent bloquer les Suggestions de Copilot qui correspondent au code public
Description : L'activation du filtre de GitHub Copilot pour bloquer les suggestions de code correspondant au code public sur GitHub améliore la sécurité et la conformité légale. Elle empêche l’incorporation involontaire de code public ou open source, réduisant le risque de problèmes juridiques et garantissant l’adhésion aux conditions de licence. En outre, il permet d’éviter d’introduire des vulnérabilités potentielles du code public dans les projets de l’organisation, ce qui permet de maintenir une qualité et une sécurité de code plus élevées. Lorsque le filtre est activé, GitHub Copilot vérifie les suggestions de code avec leur code environnant d’environ 150 caractères par rapport au code public sur GitHub. S’il existe une correspondance ou une correspondance proche, la suggestion n’est pas affichée.
Gravité : Élevée
(Préversion) GitHub organisations doivent appliquer l’authentification multifacteur pour les collaborateurs externes
Description : l'application de l'authentification multifacteur pour les collaborateurs externes dans une organisation GitHub est une mesure de sécurité qui oblige les collaborateurs à utiliser une forme supplémentaire d'identification en plus de leur mot de passe pour accéder aux référentiels et ressources de l'organisation. Cela améliore la sécurité en protégeant contre l’accès non autorisé, même si un mot de passe est compromis et contribue à garantir la conformité aux normes du secteur. Il implique d’informer les collaborateurs sur l’exigence et de fournir un support pour la transition, réduisant finalement le risque de violations de données.
Gravité : Élevée
(Préversion) GitHub référentiels doivent exiger une approbation minimale à deux réviseurs pour les envois de code
Description : Pour empêcher les modifications involontaires ou malveillantes d'être validées directement, il est important d'implémenter des stratégies de protection pour la branche par défaut dans GitHub référentiels. Nous vous recommandons d’exiger au moins deux réviseurs de code pour approuver les demandes de tirage avant la fusion du code avec la branche par défaut. En exigeant l’approbation d’un nombre minimal de deux réviseurs, vous pouvez réduire le risque de modifications non autorisées, ce qui peut entraîner une instabilité du système ou des vulnérabilités de sécurité.
Gravité : Élevée
Recommandations GitLab
Les projets GitLab doivent avoir des résultats d’analyse des secrets résolus
Description : Les secrets ont été trouvés dans les référentiels de code. Cela doit être corrigé immédiatement pour éviter une violation de la sécurité. Les secrets détectés dans les dépôts peuvent être divulgués ou découverts par des adversaires, ce qui peut compromettre une application ou d’un service.
Gravité : Élevée
Les projets GitLab doivent avoir des résultats d’analyse du code résolus
Description : Les vulnérabilités ont été détectées dans les référentiels de code. Pour améliorer la posture de sécurité des dépôts, il est vivement recommandé de corriger ces vulnérabilités.
Gravité : Moyenne
Les projets GitLab doivent avoir des résultats d’analyse des vulnérabilités de dépendance résolus
Description : GitHub référentiels doivent avoir des résultats d’analyse des vulnérabilités de dépendance résolus.
Gravité : Moyenne
Les projets GitLab doivent avoir une infrastructure en tant que résultats d’analyse du code résolus
Description : Les problèmes de configuration de sécurité de l’infrastructure en tant que code ont été détectés dans les référentiels. Les problèmes indiqués ont été détectés dans les fichiers de modèle. Pour améliorer la posture de sécurité des ressources cloud associées, il est vivement recommandé de corriger ces problèmes.
Gravité : Moyenne
Recommandations de sécurité DevOps dépréciées
Les dépôts de code doivent avoir les résultats de l’analyse du code résolus
Description : La sécurité DevOps dans Defender for Cloud a détecté des vulnérabilités dans les référentiels de code. Pour améliorer la posture de sécurité des dépôts, il est vivement recommandé de corriger ces vulnérabilités. (Aucune stratégie associée)
Gravité : Moyenne
Les dépôts de code doivent avoir les résultats de l’analyse des secrets résolus
Description : La sécurité DevOps dans Defender for Cloud a trouvé un secret dans les référentiels de code. Cela doit être corrigé immédiatement pour éviter une violation de la sécurité. Les secrets détectés dans les dépôts peuvent être divulgués ou découverts par des adversaires, ce qui peut compromettre une application ou d’un service. Pour Azure DevOps, l’outil Sécurité Microsoft DevOps CredScan analyse uniquement les builds sur lesquelles il a été configuré pour s’exécuter. Par conséquent, les résultats peuvent ne pas refléter l’état complet des secrets dans vos dépôts. (Aucune stratégie associée)
Gravité : Élevée
Les dépôts de code doivent avoir les résultats de l’analyse Dependabot résolus
Description : La sécurité DevOps dans Defender for Cloud a détecté des vulnérabilités dans les référentiels de code. Pour améliorer la posture de sécurité des dépôts, il est vivement recommandé de corriger ces vulnérabilités. (Aucune stratégie associée)
Gravité : Moyenne
Les dépôts de code doivent avoir les résultats de l’analyse de l’infrastructure en tant que code résolus
Description : La sécurité DevOps dans Defender for Cloud a trouvé l’infrastructure en tant que problèmes de configuration de sécurité du code dans les référentiels. Les problèmes indiqués ont été détectés dans les fichiers de modèle. Pour améliorer la posture de sécurité des ressources cloud associées, il est vivement recommandé de corriger ces problèmes. (Aucune stratégie associée)
Gravité : Moyenne
GitHub référentiels doivent avoir activé l’analyse du code
Description : GitHub utilise l’analyse du code pour analyser le code afin de rechercher des vulnérabilités et des erreurs de sécurité dans le code. L’analyse du code peut être utilisée pour rechercher, trier et hiérarchiser les correctifs pour les problèmes existants dans votre code. L’analyse du code peut également empêcher les développeurs d’introduire de nouveaux problèmes. Des analyses peuvent être planifiées pour des jours et heures spécifiques, ou être déclenchées lorsqu’un événement spécifique se produit dans le dépôt, tel qu’un envoi (push). Si l’analyse du code détecte une vulnérabilité ou une erreur potentielle dans le code, GitHub affiche une alerte dans le référentiel. Une vulnérabilité est un problème dans le code d’un projet qui pourrait être exploité pour endommager la confidentialité, l’intégrité ou la disponibilité du projet. (Aucune stratégie associée)
Gravité : Moyenne
GitHub référentiels doivent avoir activé l’analyse des secrets
Description : GitHub analyse les référentiels pour les types connus de secrets, afin d’empêcher l’utilisation frauduleuse de secrets qui ont été accidentellement validés dans les référentiels. L’analyse des secrets analyse l’intégralité de l’historique Git sur toutes les branches présentes dans le référentiel GitHub pour les secrets. Les jetons et les clés privées qu’un fournisseur de services peut émettre pour l’authentification sont des exemples de secrets. Si un secret est archivé dans un dépôt, toute personne disposant d’un accès en lecture au dépôt peut utiliser le secret pour accéder au service externe avec ces privilèges. Les secrets doivent être stockés dans un emplacement dédié et sécurisé en dehors du dépôt du projet. (Aucune stratégie associée)
Gravité : Élevée
GitHub référentiels doivent avoir activé l’analyse de Dependabot
Description : GitHub envoie des alertes Dependabot lorsqu’elle détecte les vulnérabilités dans les dépendances de code qui affectent les référentiels. Une vulnérabilité est un problème dans le code d’un projet qui pourrait être exploité pour altérer la confidentialité, l’intégrité ou la disponibilité du projet ou d’autres projets qui utilisent son code. Les vulnérabilités varient en fonction du type, de la gravité et de la méthode d’attaque. Quand le code dépend d’un package qui présente une faille de sécurité, cette dépendance vulnérable peut entraîner une série de problèmes. (Aucune stratégie associée)
Gravité : Moyenne