Recommandations de sécurité pour les ressources DevOps
Cet article répertorie les recommandations que vous pouvez voir dans Microsoft Defender pour le 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.
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 les fonctionnalités de la 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
GitHub Advanced Security pour Azure DevOps (GHAzDO) doit être activé dans les dépôts Azure DevOps
Description : La sécurité DevOps dans Defender pour le 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 de dépôts GitHub Advanced Security pour Azure DevOps (GHAzDO), notamment GitHub Advanced Security pour Azure DevOps, vous obtenez des résultats sur les secrets, les dépendances et les vulnérabilités de code dans vos référentiels Azure DevOps exposés dans Microsoft Defender pour le cloud.
Gravité : élevée
Les découvertes de l’analyse des secrets doivent être résolues pour les dépôts Azure DevOps
Description : Les secrets ont été trouvés dans les référentiels de code. Corrigez cela immédiatement pour éviter une violation de la 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 Microsoft Security DevOps 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 découvertes de l’analyse du code doivent être résolues pour les dépôts Azure DevOps
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 découvertes de l’analyse des vulnérabilités des dépendances doivent être résolues pour les dépôts Azure DevOps
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
Les découvertes de l’analyse de l’infrastructure en tant que code doivent être résolues pour les dépôts Azure DevOps
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
Les pipelines Azure DevOps 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 un tel cas, si ce paramètre est activé, des tiers peuvent accéder à la création de secrets de pipeline de build censés être internes.
Gravité : élevée
Les connexions du service Azure DevOps ne doivent pas accorder l'accès à tous les pipelines
Description : les connexions de service sont utilisées pour créer des connexions à partir d’Azure Pipelines vers des services externes et distants pour l’exécution de tâches dans un travail. Les autorisations de pipeline contrôlent quels pipelines sont autorisés à utiliser la connexion de service. Pour prendre en charge la sécurité des opérations du pipeline, les connexions de service ne doivent pas avoir accès à 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
Les fichiers sécurisés Azure DevOps 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 la signature de certificats et de clés SSH. Si un fichier sécurisé a accès à tous les pipelines YAML, un utilisateur non autorisé peut voler des informations dans les fichiers sécurisés en créant un pipeline YAML et en accédant au fichier sécurisé.
Gravité : élevée
Les groupes de variables Azure DevOps avec des variables de secret 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 entre plusieurs pipelines dans le même projet. Si un groupe de variables contenant des secrets est marqué comme accessible à tous les pipelines YAML, alors un attaquant peut exploiter les actifs impliquant les variables secrètes en créant un nouveau pipeline.
Gravité : élevée
Les connexions du service classique Azure DevOps ne doivent pas être utilisées pour accéder à un abonnement
Description : Utilisez le type de connexions de service Azure Resource Manager (ARM) au lieu des connexions de service Azure Classic pour vous connecter à des abonnements Azure. Le modèle ARM offre de multiples améliorations de sécurité, notamment un contrôle d'accès plus fort, un audit amélioré, un déploiement/gouvernance basé sur ARM, l'accès aux identités gérées et au coffre-fort de clés pour les secrets, l'authentification basée sur les autorisations Entra et la prise en charge des balises et des groupes de ressources pour une gestion rationalisée.
Gravité : moyenne
(Préversion) Les dépôts Azure DevOps 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) Les référentiels Azure DevOps 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 les branche par défaut dans les référentiels Azure DevOps. Nous vous recommandons d’exiger au moins deux réviseurs de code pour approuver les demandes de tirage avant la fusion du code avec le 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 pour le cloud posture de sécurité fondamentale, si vous avez connecté Azure DevOps à Defender pour le cloud.
Gravité : élevée
(Préversion) Les référentiels Azure DevOps 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 les branche par défaut dans les référentiels Azure DevOps. 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 pour le cloud posture de sécurité fondamentale, si vous avez connecté Azure DevOps à Defender pour le cloud.
Gravité : élevée
(Préversion) Les projets Azure DevOps 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
Les organisations GitHub ne doivent pas rendre les secrets d’action accessibles à tous les référentiels
Description : Pour les secrets utilisés dans les flux de travail GitHub Action stockés au niveau de l’organisation GitHub, vous pouvez utiliser des stratégies d’accès pour contrôler les dépôts qui peuvent 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 pour le cloud posture de sécurité fondamentale, si vous avez connecté Azure DevOps à Defender pour le cloud.
Gravité : élevée
L’analyse des secrets doit être activée dans les référentiels GitHub
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 dépôt GitHub à la recherche de 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
L’analyse du code doit être activée dans les référentiels GitHub
Description : GitHub utilise l’analyse du code pour analyser le code afin de rechercher des vulnérabilités de sécurité et des erreurs 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 dépôt. 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
L’analyse Dependabot doit être activée dans les dépôts GitHub
Description : GitHub envoie des alertes Dependabot lorsqu’il détecte les vulnérabilités dans les dépendances de code qui affectent les dépôts. 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
Les découvertes de l’analyse des secrets doivent être résolues pour les dépôts GitHub
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
Les découvertes de l’analyse du code doivent être résolues pour les dépôts GitHub
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écouvertes de l’analyse des vulnérabilités des dépendances doivent être résolues pour les dépôts GitHub
Description : Les dépôts GitHub doivent avoir des résultats d’analyse des vulnérabilités de dépendance résolus.
Gravité : moyenne
Les découvertes de l’analyse de l’infrastructure en tant que code doivent être résolues pour les dépôts GitHub
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
Les stratégies de protection pour la branche par défaut doivent être activées pour les dépôts GitHub
Description : la branche par défaut du référentiel doit être protégée via des 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
Les envois (push) forcés à la branche par défaut doivent être désactivés pour les dépôts GitHub
Description : étant donné que le branche par défaut est généralement utilisé 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 poussées forcées peut introduire des modifications involontaires ou malveillantes dans la branche par défaut.
Gravité : moyenne
La protection des envois (push) de l’analyse des secrets doit être activée pour les organisations GitHub
Description : La protection Push bloque les validations qui contiennent des secrets, ce qui empêche l’exposition accidentelle des secrets. Pour éviter tout risque d'exposition des informations d'identification, la protection Push doit être automatiquement activée pour chaque référentiel activé pour l'analyse secrète.
Gravité : élevée
Les dépôts GitHub ne doivent pas utiliser d’exécuteurs auto-hébergés
Description : Les exécuteurs auto-hébergés sur GitHub ne garantissent pas l’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. En tant que tels, les coureurs auto-hébergés ne doivent pas être utilisés pour les flux de travail d'action.
Gravité : élevée
Les organisations GitHub doivent avoir des autorisations de workflow 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
Les organisations GitHub doivent avoir plus d'une personne disposant d'autorisations d'administrateur
Description : Avoir au moins deux administrateurs réduit le risque de perdre l’accès administrateur. Ceci est utile en cas de scénarios de compte brisé.
Gravité : élevée
Les organisations GitHub doivent avoir des autorisations de base définies sur aucune autorisation ou en 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
Les découvertes des tests de sécurité des API doivent être résolues pour les dépôts GitHub
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) Les organisations GitHub ne doivent pas rendre les secrets d’action accessibles à tous les référentiels
Description : Pour les secrets utilisés dans les flux de travail GitHub Action stockés au niveau de l’organisation GitHub, vous pouvez utiliser des stratégies d’accès pour contrôler les dépôts qui peuvent 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) Les organisations GitHub doivent bloquer les suggestions 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 exacte ou quasi exacte, la suggestion n’est pas montrée.
Gravité : élevée
(Préversion) Les organisations GitHub doivent appliquer l’authentification multifacteur pour les collaborateur externe
Description : l’application de l’authentification multifacteur pour les collaborateur externe d’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) Les référentiels GitHub doivent nécessiter 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 les branche par défaut dans les référentiels GitHub. Nous vous recommandons d’exiger au moins deux réviseurs de code pour approuver les demandes de tirage avant la fusion du code avec le 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 découvertes de l’analyse des secrets doivent être résolues pour les projets GitLab
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 découvertes de l’analyse du code doivent être résolues pour les projets GitLab
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 découvertes de l’analyse des vulnérabilités des dépendances doivent être résolues pour les projets GitLab
Description : Les dépôts GitHub doivent avoir des résultats d’analyse des vulnérabilités de dépendance résolus.
Gravité : moyenne
Les découvertes de l’analyse de l’infrastructure en tant que code doivent être résolues pour les projets GitLab
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 pour le 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 pour le 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 Microsoft Security 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 pour le 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 pour le 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
L’analyse du code doit être activée dans les référentiels GitHub
Description : GitHub utilise l’analyse du code pour analyser le code afin de rechercher des vulnérabilités de sécurité et des erreurs 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 dépôt. 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
L’analyse des secrets doit être activée dans les référentiels GitHub
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 dépôt GitHub à la recherche de 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
L’analyse Dependabot doit être activée dans les dépôts GitHub
Description : GitHub envoie des alertes Dependabot lorsqu’il détecte les vulnérabilités dans les dépendances de code qui affectent les dépôts. 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